Departamento de Computación Arquitectura para un sistema ...

CENTRO DE INVESTIGACIÓN Y DE ESTUDIOS

AVANZADOS DEL INSTITUTO POLITÉCNICO NACIONAL

UNIDAD ZACATENCO

Departamento de Computación

“Arquitectura para un sistema de denuncias basado en Blockchain y

tecnologías en la nube”

T E S I S

Que presenta

ÁNGEL ISAAC RODRÍGUEZ COSME

Para obtener el grado de

MAESTRO EN CIENCIAS EN COMPUTACIÓN

Directores de tesis:

DRA. SONIA G. MENDOZA CHAPA

DR. CUAUHTÉMOC MANCILLAS LÓPEZ

CIUDAD DE MÉXICO NOVIEMBRE, 2020

AGRADECIMIENTOS

A mis padres, Digna y José, por su amor, su confianza y su apoyo siempre incondicionales. Les agradezco infinitamente que me acompañen en cada una de mis ocurrencias a lo largo de la vida y más aún, les agradezco por enseñarme a tomar decisiones sin miedo y con determinación.

A mis hermanos, Uriel y Alberto, por inspirarme siempre a ser alguien digno de su respeto, por escuchar siempre mis frustraciones, por las noches en que me acompañaron mientras hacía mis tareas, por ser mis amigos además de mis hermanos y por ayudarme a no ser más raro de lo que ya soy. A mi esposa Fernanda, por acompañarme desde que estudiar un posgrado en el CINVESTAV no era más que un plan derivado de un sueño. Le agradezco por su apoyo y toda la motivación que me dio, por creer en mí más de lo que a veces yo creía en mí mismo. A mis directores de tesis, la Dra. Sonia y el Dr. Cuauhtémoc, agradezco por confiar en mí y dirigir mi tesis, por sus enseñanzas, por la cercanía, sencillez y calidez con la que nos trataron a mí y a mis compañeros y sobre todo, les agradezco por su paciencia.

A Sofy Reza, por su trato siempre tan amable y alegre, por escucharnos y consolarnos en momentos de crisis y por darle al Departamento de Computación, una buena parte del toque humano que puede tener. A mis amigos del CINVESTAV, especialmente a María Fernanda y a Michel Torres, por compartir conmigo momentos alegres y por apoyarme durante nuestra estancia en el posgrado. Al CONACyT, por el apoyo económico brindado sin el cual no hubiera podido culminar mis estudios de maestría. Al CINVESTAV, por proporcionarme los recursos para adquirir los conocimientos

técnicos y científicos necesarios que me permitieron desarrollándome profesionalmente

en mayor medida.

Resumen

Los sistemas computacionales de la actualidad están evolucionando al desarrollo basado en

arquitecturas en la nube, además de que muchos buscan tener enfoques descentralizados. Esta

evolución ha dado lugar al desarrollo de nuevas herramientas y tecnologías que hacen posible el

diseño de soluciones informáticas, capaces de satisfacer las necesidades de los ciudadanos en

muchos de los ámbitos de la vida cotidiana.

Para el desarrollo de esta tesis, tomamos como referencia inicial un problema de interés social en

México, que es el de la inseguridad y nos planteamos el cuestionamiento de cómo podríamos

contribuir a mitigar su impacto con nuestro trabajo y de una forma novedosa.

Sabemos que, en materia legal, la centralización de la información y las decisiones, son un factor

importante para que existan abusos e impunidad, lo cual tiene un impacto directo en la disposición

de los ciudadanos por denunciar. Si consiguiéramos implementar un mecanismo que nos permitiera

agregar un nivel de descentralización en el proceso de denuncias, estaríamos contribuyendo a que

el problema disminuya. Esta idea nos llevó a proponer una arquitectura viable para el desarrollo de

un sistema de denuncias de actos delictivos e ilícitos para uso de la ciudadanía, tomando como base

las tendencias actuales en el desarrollo de sistemas computacionales.

A este respecto, existe una tecnología en tendencia, referida como Blockchain, que ofrece algunas

características que pueden resultar valiosas para sistemas que tengan cierto grado de

descentralización, confidencialidad, integridad e incluso anonimato.

Experimentamos con diversas arquitecturas tomando ésta tecnología como base y buscando ofrecer

descentralización como la característica más importante en el sistema, sin embargo, durante el

análisis y las pruebas de las arquitecturas que se plantearon, encontramos que un sistema

completamente descentralizado no daría solución a los problemas de diseño que identificamos. Fue

así como refinamos nuestra propuesta de arquitectura, dando nuevos enfoques para solucionar los

problemas que se presentaban al experimentar con nuevas tecnologías y plataformas.

Así, las principales aportaciones de esta tesis son: La propuesta de una solución genérica que puede

ser aprovechada como referencia para el desarrollo de sistemas en ámbitos similares. Una

arquitectura que incorpora tecnologías emergentes. El desarrollo y el estudio de prototipos que

pueden tomarse como base conceptual para nuevos proyectos. Mostramos que es posible diseñar e

implementar sistemas computacionales que usan Blockchain, sin acoplar su funcionalidad

exclusivamente al enfoque de esta tecnología, lo que puede convertir a este trabajo en una nueva

referencia en cuanto a la incorporación de Blockchain en sistemas computacionales. Exploramos la

posibilidad de interactuar directamente con una Blockchain usando una aplicación móvil y

mostramos que se puede hacer uso del enfoque sin servidores para agilizar el desarrollo de los

servicios de un sistema, además de conseguir la escalabilidad de los servicios administrados sin

invertir en una infraestructura y herramientas de administración.

Abstract

Today's computing systems are evolving to development based on cloud architectures, and many

are looking to have decentralized approaches. This evolution has led to the development of new

tools and technologies that make possible the design of IT solutions, capable of meeting the needs

of citizens in many areas of daily life. For the development of this thesis, we took as an initial

reference a problem of social interest in Mexico, which is that of insecurity, and we asked ourselves

how we could contribute to mitigating its impact with our work and in a novel way.

We know that in legal matters, the centralization of information and decisions is an essential factor

for the existence of abuses and impunity, which has a direct impact on the willingness of citizens to

report. If we were able to implement a mechanism that would allow us to add a level of

decentralization to the complaints process, we would be helping to reduce the problem. This idea

led us to propose a viable architecture for the development of a system for reporting criminal and

illicit acts for the use of the public, based on current trends in the development of computer systems.

In this regard, there is a trending technology, referred to as Blockchain, that offers some features that

can be valuable for systems that have a certain degree of decentralization, confidentiality, integrity,

and even anonymity.

We experimented with various architectures taking this technology as a basis and seeking to offer

decentralization as an essential feature in the system, however, during the analysis and testing of

the architectures that were raised, we found that a completely decentralized system would not solve

the problems. Design that we identify. This is how we refined our architecture proposal, giving new

approaches to solve the problems that arose when experimenting with new technologies and

platforms.

Thus, the main contributions of this thesis are The proposal of a generic solution that can be used as

a reference for the development of systems in similar fields. An architecture that incorporates

emerging technologies. The development and study of prototypes that can be taken as a conceptual

basis for new projects. We show that it is possible to design and implement computer systems that

use Blockchain, without coupling its functionality exclusively to the approach of this technology,

which can make this work a new reference in terms of the incorporation of Blockchain in computer

systems.

We explore the possibility of interacting directly with a Blockchain using a mobile application and

show that the serverless approach can be used to speed up the development of system services, in

addition to achieving the scalability of managed services without investing in an infrastructure and

administration tools.

Índice general

1 Introducción 13

1.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . 15

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4 Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5 Organización de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Marco teórico 19

2.1 Sistemas distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.2 Transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2.1 Transacciones en Blockchain . . . . . . . . . . . . . . . . . . . 26

2.2.2 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.3 Contratos inteligentes . . . . . . . . . . . . . . . . . . . . . . 30

2.2.4 Multichain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2.5 Sistema de Archivos Interplanetario . . . . . . . . . . . . . . . 31

2.3 Servicios Web REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.1 RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.2 Apache Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5 Seguridad en sistemas de información . . . . . . . . . . . . . . . . . 34

2.5.1 Criptografía asimétrica . . . . . . . . . . . . . . . . . . . . . . 34

2.5.2 Firmas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5.3 Certificados digitales . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.4 Protocolo de seguridad en capa de transporte . . . . . . . . . 37

2.5.5 Principales riesgos de seguridad en dispositivos móviles . . . 38

2.5.6 Estándar de Verificación de Seguridad en Dispositivos Móviles 39

2.6 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7 Resumen del capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7

3 Trabajos relacionados 41

3.1 Sistemas de denuncia . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Sistemas con anonimato . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Sistemas que usan Blockchain . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Aplicaciones descentralizadas . . . . . . . . . . . . . . . . . . . . . . 43


4 Análisis y diseño de la arquitectura del sistema 45

4.1 Aspectos clave del sistema . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Problemas de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.1 Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.2 Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.3 Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.4 Anonimato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.5 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3 Vista estática del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1 Participantes del sistema . . . . . . . . . . . . . . . . . . . . . 49

4.3.2 Denuncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.5 Vista dinámica del sistema . . . . . . . . . . . . . . . . . . . . . . . . 52


5 Implementación 55

5.1 Metodología de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1 Modelo de desarrollo en cascada . . . . . . . . . . . . . . . . 56

5.1.2 Modelo de desarrollo evolutivo . . . . . . . . . . . . . . . . . 56

5.2 Prototipos desarrollados . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Primera iteración: sistema de denuncias basado exclusivamen-te en Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 Segunda iteración: sistema de denuncias basado en Blockchainy otros servicios . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.3 Tercera iteración: sistema de denuncias basado en Blockchainy tecnologías en la nube . . . . . . . . . . . . . . . . . . . . . 60

5.3 Detalles técnicos de los componentes . . . . . . . . . . . . . . . . . . 61

5.3.1 Aplicación móvil en Android . . . . . . . . . . . . . . . . . . . 62

5.3.2 Infraestructura en Amazon Web Services (AWS) . . . . . . . . 63

5.3.3 Sistema de Archivos Interplanetario . . . . . . . . . . . . . . . 63

5.3.4 Blockchain de Ethereum . . . . . . . . . . . . . . . . . . . . . 64


8 Índice general

6 Pruebas funcionales y resultados 676.1 Componente de despliegue de contratos inteligentes . . . . . . . . . 67

6.1.1 Descripción de la prueba . . . . . . . . . . . . . . . . . . . . . 686.1.2 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Componente de manejo de contratos inteligentes . . . . . . . . . . . 696.2.1 Descripción de la prueba . . . . . . . . . . . . . . . . . . . . . 696.2.2 Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.2.3 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3 Componente de operaciones en base de datos . . . . . . . . . . . . . 716.3.1 Descripción de la prueba . . . . . . . . . . . . . . . . . . . . . 716.3.2 Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.3.3 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.4 Publicación de denuncia en IPFS . . . . . . . . . . . . . . . . . . . . 736.4.1 Descripción de la prueba . . . . . . . . . . . . . . . . . . . . . 736.4.2 Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.4.3 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


7 Conclusiones y trabajo futuro 777.1 Recapitulación del problema . . . . . . . . . . . . . . . . . . . . . . . 777.2 Conclusiones y contribuciones . . . . . . . . . . . . . . . . . . . . . . 787.3 Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8 Acrónimos 81

Bibliografía 83

Índice general 9

Índice de figuras

1.1 Razones para no denunciar delitos en México. Instituto Nacional de Es-tadística y Geografía. “Encuesta Nacional de Victimización y Percepciónsobre Seguridad Pública (ENVIPE)", 2017 . . . . . . . . . . . . . . . . 15

2.1 Un sistema distribuido organizado como una capa de middleware quese extiende sobre diversas computadoras y ofrece a cada aplicación lamisma interfaz (Tanenbaum and Steen, 2007) . . . . . . . . . . . . . . 21

2.2 Arquitecturas de redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Estructura de los bloques de una cadena en Blockchain . . . . . . . . . 26

2.4 Flujo de una transacción en Blockchain . . . . . . . . . . . . . . . . . . 27

2.5 Los nodos en la red cambian de estado tras una transacción válidacompletada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6 Ejemplo de un contrato inteligente. . . . . . . . . . . . . . . . . . . . . 31

2.7 Modelo del esquema de firma digital . . . . . . . . . . . . . . . . . . . 36

2.8 Modelo Mobile AppSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 El usuario interactúa con el sistema a través de su dirección asignadaen Ethereum y de un contrato que corresponde a una denuncia . . . . 48

4.2 Diagrama de componentes del sistema . . . . . . . . . . . . . . . . . . 52

4.3 Diagrama de secuencia del sistema para registro e inicio de sesión . . . 53

4.4 Diagrama de secuencia del sistema para el envío de denuncias . . . . . 53

5.1 Modelo de desarrollo en cascada . . . . . . . . . . . . . . . . . . . . . 57

5.2 Modelo de desarrollo evolutivo . . . . . . . . . . . . . . . . . . . . . . 575.3 Arquitectura inicial del sistema . . . . . . . . . . . . . . . . . . . . . . 595.4 Segunda arquitectura del sistema, agregando más componentes . . . . 60

5.5 Diagrama general de la arquitectura final del sistema . . . . . . . . . . 61

5.6 Arquitectura en AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.1 Resultado de la ejecución de la función de despliegue de contratointeligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Información en Etherscan del contrato inteligente desplegado en laprueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10

6.3 Resultado de la ejecución de la función de consulta de contrato inteligente 706.4 Resultado de las pruebas en la consola de AWS Lambda . . . . . . . . . 726.5 Resultado de las pruebas en la consola de Mongo Atlas . . . . . . . . . 726.6 Pantalla de denuncia en la aplicación móvil . . . . . . . . . . . . . . . 736.7 Resultado de la publicación de la denuncia hacia IPFS mostrado en la

consola de Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . 746.8 Resultado de la consulta a IPFS usando el hash obtenido en la prueba . 75

Índice de figuras 11

Introducción 1Actualmente, existen tecnologías que brindan herramientas para llevar a cabo eldesarrollo de soluciones, capaces de cubrir las necesidades de los ciudadanos enmateria legal. Tal es el caso de las implementaciones de mecanismos criptográficos,como firmas electrónicas (Enciso, 2011) y certificados digitales (Feghhi et al., 1999),que permiten la identificación de una entidad o de una persona de manera digital.Dicha identificación es indispensable en sistemas de información que buscan ofrecerla posibilidad de realizar operaciones con un cierto valor legal para una entidadgubernamental.

A este respecto, existe una tecnología referida como Blockchain (Mattila, 2016), queofrece algunas características que pueden resultar valiosas para sistemas que tengancierto grado de descentralización, confidencialidad, integridad e incluso anonimato.Esta idea nos llevó a pensar en la propuesta de una arquitectura viable para eldesarrollo de un sistema de denuncias de actos delictivos e ilícitos por parte de laciudadanía.

La tecnología Blockchain reúne diversas técnicas criptográficas en una red P2P (Zhouet al., 2006; Martins, 2016) en la que participan varios nodos que almacenan infor-mación, en forma de bloques de transacciones (Wang, 2008). Estos bloques estánenlazados por un identificador, que se obtiene de aplicar sobre ellos una funciónHash (Damgard, 1989; Bakhtiari, 1995) y que es almacenado en el bloque siguien-te de la cadena. A los usuarios conectados a la red, se les asigna una direccióncon la que pueden hacer intercambios mediante transacciones, en las que se veninvolucradas firmas digitales que proveen autenticación. Posteriormente, usandoesta propuesta como base, se integraron contratos inteligentes para permitir laejecución de instrucciones escritas en un lenguaje de programación. Esta integraciónconsiguió que el número de aplicaciones que usan Blockchain aumentara significa-tivamente, dando lugar a lo que se conocen como aplicaciones descentralizadas oDApps (stateofthedapps, 2019).

Otro de los desafíos importantes a los que se enfrentan los desarrollos de sistemas,como el que se describe en esta tesis, es el del acceso a la infraestructura necesariapara implementar el sistema. Se requieren servidores con recursos suficientes paraprocesar y responder a la gran cantidad de peticiones que realizan los usuarios, por

13

lo que las organizaciones se ven obligadas a invertir recursos considerables en laimplantación y el mantenimiento de dichos servidores. El cómputo en la nube (Hayes,2008) da solución a los problemas de infraestructura de las organizaciones. Empresascomo Amazon, Microsoft o Google ofrecen una vasta cantidad de servicios que seadaptan a la mayoría de los sistemas que se desarrollan actualmente para resolverproblemáticas sociales.

En esta tesis, proponemos una arquitectura en la que convergen varias tecnologías yparadigmas emergentes como:

Blockchain Ethereum (Wood, 2014),

Sistema de Archivos Interplanetario (IPFS1 por sus siglas en inglés) (IPFS,2019),

REST-Appis (Richardson, 2007) para el intercambio de información entre loscomponentes del sistema,

cómputo en la nube, que provee la infraestructura necesaria a un sistema querequiere grandes recursos de cómputo,

aplicaciones móviles (Nah et al., 2005) por ser populares y accesibles a laciudadanía,

servicios de streaming (Oyman and Singh, 2012) para el procesamiento degrandes cantidades de información en tiempo real y

tecnologías Web (Hitzler et al., 2009).

Por otro lado, hacemos énfasis en la seguridad (Baskerville, 1993) y en la escalabili-dad (Martínez, 2013) del sistema. Proponemos como aplicación de referencia paranuestra arquitectura, un sistema de denuncias con pseudo-anonimato, usando con-tratos inteligentes de la Blockchain Ethereum, en conjunto con IPFS y los serviciosdel sistema, que serán implantados en la nube de Amazon (AWS, 2006). En cuantoal medio que tendrán los usuarios para usar el sistema y realizar denuncias, se optópor proponer una aplicación móvil que estará conectada a la nube de Google, con elobjetivo de dar información en tiempo real. Finalmente, se plantea también la reco-pilación de la información de todos los usuarios del sistema para ser procesada en lanube de Amazon y para mostrarse en tiempo real en un portal Web de monitoreo,usando un servicio de streaming.

1Interplanetary File System

14 Capítulo 1 Introducción

1.1. Motivación

De acuerdo con el Índice Global de Impunidad México de 2018, publicado por laUniversidad de las Américas Puebla (UDLAP) (IGI-MEX, 2018), México sufre deun alto grado de impunidad, estando a la cabeza de las naciones en América, conun 99.3 % de impunidad por delitos generales en el país, lo cual desencadena unavariedad de problemas legales.

Como se mencionó anteriormente, estamos conscientes de que existen tecnologías ymecanismos que brindan las herramientas suficientes para llevar a cabo el desarrollode soluciones, que estén a la altura de las necesidades de los ciudadanos en materialegal. Algunas de estas tecnologías son Blockchain, cómputo en la nube y serviciosde streaming, de las cuales se hablará con mayor profundidad en el Capítulo 2.

1.2. Planteamiento del problema

De acuerdo a la información presentada en la séptima edición de la EncuestaNacional de Victimización y Percepción de la Seguridad Pública (ENVIPE), que fuerealizada en 2017 por el Instituto Nacional de Estadística y Geografía (INEGI, 2017),se estima en 24.2 millones el número de víctimas de 18 años y más en el país durante2016. Además, la percepción de inseguridad de la población de 18 años y más, enlas entidades federativas, se ubicó en 74.3 %.

Figura 1.1 – Razones para no denunciar delitos en México. Instituto Nacional de Estadísticay Geografía. “Encuesta Nacional de Victimización y Percepción sobre SeguridadPública (ENVIPE)", 2017

De la Figura 1.1, se deduce también que entre las razones de las víctimas para nodenunciar delitos ante las autoridades destacan la "pérdida de tiempo” con 33.1 %

1.1 Motivación 15

y la "desconfianza en la autoridad” con 16.5 %, dentro de las causas atribuiblesa la autoridad. Por otras causas se entienden: miedo al agresor, delito de pocaimportancia, falta de pruebas y otros motivos.

Aunado a esto, actualmente la sociedad mexicana sufre de un alto grado de cen-sura en los medios (Avilés, 2007) que, en muchas ocasiones, genera un problemade impunidad. Lamentablemente, es complicado mantener medios en los que sepuedan denunciar estos actos, sin poner en riesgo la integridad de las personas quecontribuyen (Guevara, 2018), principalmente aquellas que realizan investigacionesde casos que involucran a individuos con mucho poder.

Por otro lado, a pesar del auge en la implementación de sistemas de informaciónpara optimizar procesos civiles y gubernamentales, México carece de herramientasinformáticas que estén al alcance de la población y que tengan como objetivo mitigarel problema de impunidad mencionado anteriormente.

1.3. Objetivos

El objetivo general de esta tesis es proponer una nueva arquitectura para sistemas dedenuncias que permita, a cualquier persona, reportar actos fraudulentos, delictivoso de corrupción a través de un medio digital.

Para lograr este objetivo general, se establecen los siguientes objetivos específicos:

Proponer una solución genérica que pueda aprovecharse como referencia parael desarrollo de sistemas que resuelvan problemáticas de ámbitos distintos allegal, como el de la salud.

Hacer uso de tecnologías emergentes, como Blockchain, aplicaciones móvi-les, la Web y servicios de streaming, para construir un sistema de denunciasconfiable, escalable y robusto.

Implementar, en la nube, los servicios del sistema de denuncias para ofreceruna alternativa de solución a los problemas de infraestructura y de seguridadque se presentan en otros trabajos de este tipo.

Desarrollar prototipos de los componentes de la arquitectura propuesta paramostrar y evaluar la viabilidad de nuestra propuesta.

16 Capítulo 1 Introducción

1.4. Contribuciones

Los aportes de este trabajo de tesis son principalmente teóricos, aunque tambiénpresentamos algunas contribuciones prácticas. En particular, se propone la arquitec-tura de un sistema que podría dar solución a uno de los principales problemas enmateria de seguridad en nuestro país, que es el de la baja participación ciudadanaen el proceso de denuncia de actos delictivos. Asimismo, se presentan prototiposde algunos de los componentes más importantes de la arquitectura, como lo es elcomponente encargado de la comunicación con Blockchain.

Cabe mencionar que el diseño de nuestra arquitectura, así como desarrollo de losprototipos, requirió de conocimientos e investigación sobre el manejo de diversastecnologías, por lo que nuestra propuesta resulta diferente a las que actualmenteatacan el problema planteado en la Sección 1.2. Además, gracias a su diseño modular,la arquitectura propuesta puede ser usada como base conceptual para el desarrollode sistemas con requerimientos similares.

1.5. Organización de la tesis

Esta tesis está dividida en siete capítulos. En el Capítulo 2, se abordan los aspectosmás importantes de las tecnologías que se eligieron para el diseño de nuestraarquitectura. Posteriormente, en el Capítulo 3, se detallan las características dealgunos sistemas similares al de la arquitectura que proponemos. En el Capítulo 4,con un enfoque orientado al desarrollo y a la ingeniería de software, presentamosun análisis general de los problemas a los que se enfrenta el desarrollo del sistema.Describimos las características finales y mostramos los detalles de desarrollo decada uno de los componentes del mismo. En el Capítulo 5, damos un resumen de laforma en que los prototipos presentados fueron implementados. Incluimos detallesde la metodología de desarrollo que seguimos y los recursos y herramientas que seemplearon. Posteriormente, en el Capítulo 6, presentamos las pruebas que realizamossobre los prototipos desarrollados de algunos componentes de la arquitectura, comola aplicación móvil y las funciones creadas en AWS. Finalmente, en el Capítulo 7,presentamos nuestras conclusiones y ofrecemos una visión del trabajo futuro al quenuestra arquitectura da lugar.

1.4 Contribuciones 17

Marco teórico 2Este capítulo está organizado en seis apartados. En la Sección 2.1, se presentauna definición y las características de los sistemas distribuidos, haciendo énfasisen los conceptos de transacciones y redes P2P. Estas definiciones son necesariaspara introducir Blockchain en la Sección 2.2, que es una de las tecnologías de basede nuestra propuesta. A continuación, en la Secciones 2.3 y 2.4, nos enfocamosen otras dos tecnologías esenciales: el modelo REST y la técnica de streaming,respectivamente. En la Sección 2.5, se introducen algunos conceptos relacionadoscon la seguridad de sistemas de información, tales como criptografía asimétrica,firmas y certificados digitales, el protocolo SSL, así como algunos riesgos y medidasde seguridad en dispositivos móviles. Este capítulo finaliza describiendo, en laSección 2.6, los servicios Web de Amazon, que utilizamos para la implementacióndel sistema resultante de la presente tesis.

2.1. Sistemas distribuidos

Un sistema distribuido es una colección de computadoras independientes, quese comporta ante los usuarios como un único sistema coherente. Así, podemosresaltar dos aspectos clave de un sistema distribuido: por un lado, cada uno de suscomponentes es autónomo; por otro lado, los usuarios tienen la impresión de estarinteractuando con un único sistema, por lo que el desarrollo de sistemas distribuidoshace énfasis en definir cómo van a interactuar sus componentes para conseguir dichoobjetivo (Tanenbaum and Steen, 2007).

Como menciona Coulouris et al (2005), los sistemas distribuidos están presentesen cualquier lugar. Internet permite a usuarios, a través del mundo, acceder a susservicios siempre que estos puedan ser localizables. Cada organización maneja unaintranet que provee servicios locales y servicios de Internet a usuarios locales y,por lo general, también provee servicios a otros usuarios de Internet. De hecho, esposible construir pequeños sistemas distribuidos a partir de computadoras móviles yotros dispositivos de cómputo pequeños (como teléfonos inteligentes o tabletas) quepuedan conectarse a una red inalámbrica.

19

El uso compartido de recursos es el factor de motivación principal para construirsistemas distribuidos. Recursos como impresoras, archivos, páginas web o registrosde bases de datos son administrados por servidores del tipo apropiado. Por ejemplo,los servidores web manejan páginas web y otros recursos web. Los recursos sonaccedidos por clientes, por ejemplo, los clientes de servidores web se conocen comonavegadores (Coulouris et al, 2005).

La construcción de sistemas distribuidos implica varios retos (Coulouris et al,2005):

Heterogeneidad: deben ser construidos a partir de una variedad de redes diferentes,sistemas operativos, hardware de computadoras y lenguajes de programación. Losprotocolos de comunicación de Internet enmascaran la diferencia en cuanto a redesy los middlewares pueden tratar las otras diferencias.

Extensibilidad: los sistemas distribuidos deben ser extensibles; el primer paso espublicar las interfaces de los componentes, pero la integración de componentesescritos por diferentes programadores es un reto real.

Seguridad: el cifrado de la información puede ser utilizado para proveer protecciónadecuada de recursos compartidos y mantener secreta información sensitiva cuandoes transmitida en mensajes sobre la red. La protección contra ataques de servicios esaún un problema.

Escalabilidad: un sistema distribuido es escalable si el costo de añadir un usuarioes una cantidad constante en términos de los recursos que deben ser incluidos.Los algoritmos utilizados para añadir datos compartidos deberían evitar cuellos debotella en el desempeño y los datos deberían ser estructurados jerárquicamente paraobtener los mejores tiempos de acceso. Los datos accedidos frecuentemente puedenser replicados.

Manejo de fallas: cualquier proceso, computadora o red puede fallar independien-temente de los otros. Por lo tanto, cada componente necesita “tener consciencia” delas posibles maneras en las que los componentes de los que depende pueden fallar ypueden ser designados para tratar cada una de las fallas apropiadamente.

Concurrencia: la presencia de múltiples usuarios en un sistema distribuido es unafuente de solicitudes concurrentes a sus recursos. Cada recurso debe ser diseñadopara mantenerse seguro en un entorno concurrente.

Transparencia: el interés es hacer ciertos aspectos de distribución invisibles, a losprogramadores de aplicaciones, para que estos sólo necesiten preocuparse por eldiseño de su aplicación particular. Por ejemplo, ellos no necesitan estar preocupados

20 Capítulo 2 Marco teórico

por la ubicación de un componente o por los detalles de cómo sus operaciones sonaccedidas por otros componentes, o si será replicado o migrado. Incluso las fallas deredes y procesos pueden ser presentadas a los programadores de aplicaciones comoexcepciones, pero estas deben ser manejables.

A menudo, los sistemas distribuidos se organizan en términos de una capa desoftware conocida como middleware, i.e., se colocan de manera lógica entre unacapa de alto nivel que consta de usuarios y aplicaciones, y una capa subyacenteconstituida por sistemas operativos y recursos básicos de comunicación (Tanenbaumand Steen, 2007).

Figura 2.1 – Un sistema distribuido organizado como una capa de middleware que seextiende sobre diversas computadoras y ofrece a cada aplicación la mismainterfaz (Tanenbaum and Steen, 2007)

En la Figura 2.1 se pueden ver cuatro computadoras conectadas en red y tresaplicaciones, de las cuales la Aplicación B está distribuida entre las Computadoras 2 y3. A cada aplicación se le ofrece la misma interfaz. El sistema distribuido proporcionalos medios para que los componentes de una sola aplicación distribuida puedancomunicarse entre sí, pero también para permitir la comunicación entre las diferentesaplicaciones. Al mismo tiempo, el sistema distribuido oculta, de la mejor maneraposible, las diferencias que se presentan entre el hardware y los sistemas operativos(SO) para cada aplicación.

2.1 Sistemas distribuidos 21

2.1.1. Redes P2P

Una red peer to peer (P2P) es un modelo de red que no tiene clientes ni servidores fijos(vs Web), sino un conjunto de nodos que se comportan como clientes y servidoresde otros. Las principales características de una red P2P se enlistan a continuación:

Todos los nodos se comportan igual y pueden realizar las mismas operaciones.

Los nodos pueden diferir en configuración local, e.g., número de pares cono-cidos, así como en capacidades de procesamiento, de almacenamiento y decomunicación (ancho de banda).

Una red P2P tiene tres elementos principales:

1. Par: es la unidad de procesamiento básico de cualquier red P2P y se comportacomo una entidad capaz de realizar un trabajo y de comunicar directa oindirectamente los resultados a otra entidad. Existen dos tipos de pares:

Pares simples: sirven a un único usuario final (e.g., eMule), permitién-dole ofrecer servicios desde su dispositivo y empleando los serviciosofrecidos por otros pares. Además, los pares simples tienen naturalezadinámica (i.e., se conectan a la red de forma intermitente) y heterogénea(i.e., tienen capacidades distintas).

Superpares: ayudan a los pares simples a encontrar otros pares. Lospares simples hacen solicitudes de búsqueda de recursos a los superpa-res, los cuales les indican dónde conseguirlos. Al contrario de los paressimples, los superpares tiene naturaleza estática (i.e., están normalmenteconectados a la red) y son fácilmente accesibles.

2. Grupos de pares: es un conjunto formado para servir a un interés comúndictado por los demás pares implicados, e.g., encaminamiento de solicitudesy respuestas. En un sistema P2P en el que todos los pares utilizan el mismoconjunto de protocolos (e.g., JXTA), el concepto de "grupos de pares” se utilizapara dividir el espacio de red, e.g., por protocolos utilizados (e.g., TCP o UDP).

3. Servicios: proporcionan al usuario funcionalidades que se consiguen mediantela cooperación entre los distintos pares, e.g., transferir un archivo, proporcionarinformación de estado, realizar un cálculo y comunicarse con otro usuario. Asícomo existen dos tipos de pares, también existen dos tipos de servicios:


Servicios de pares: son funcionalidades ofrecidas a otros pares por unpar concreto de la red. Si el par se desconecta, el servicio se vuelve nodisponible.

Servicios de grupo de pares: son funcionalidades proporcionadas porvarios miembros del grupo, ofreciendo acceso redundante al servicio. Siun par del grupo se desconecta, el servicio sigue estando disponible.

Figura 2.2 – Arquitecturas de redes P2P

Tres arquitecturas de redes P2P han sido definidas:

1. Modelo híbrido o centralizado: corresponde a la primera generación deredes P2P, la cual usa un modelo de red cliente/servidor (ver parte izquierdade la Figura 2.2). El nodo central mantiene una base de datos con informaciónde los archivos ofrecidos por cada par. La base de datos se actualiza cada vezque un par se conecta o desconecta de la red. Todos los mensajes de solicitud yde control son enviados al nodo central, el cual compara la solicitud de un nodocliente (i.e., un par) con la base de datos y le envía las coincidencias. El nodocliente se encarga de contactar directamente al par para acceder al recursosolicitado. Esta arquitectura presenta un alto rendimiento (i.e., tiempo derespuesta) en la localización de recursos, si el servidor puede hacer búsquedaseficientes. Sin embargo, el nodo central es un potencial cuello de botella.

2. Modelo mixto o semi-centralizado: se refiere a la segunda generación deredes P2P, que usa un modelo distribuido, i.e., no existe un servidor central,


pues todos los pares tienen el mismo estatus (ver parte derecha de la Figura2.2). Cada par actúa a la vez como servidor y cliente, y trata de mantener uncierto número de conexiones constantes con otros pares. El conjunto de paresconectados transporta el tráfico de red, i.e., solicitudes y respuestas a estassolicitudes, así como mensajes de control que facilitan el descubrimiento deotros pares. El número de saltos de un mensaje está limitado por un tiempode vida máximo, el cual es el máximo número de saltos que puede dar unmensaje y decrece cada vez que un mensaje pasa por un nodo, descartandola solicitud si el tiempo de vida máximo llega a cero. Esta arquitectura esmás robusta que la de la primera generación porque no depende de un nodocentral, pero presenta un menor rendimiento (i.e., tiempo de respuesta) ygenera sobrecarga en la red (debida a los mensajes de control); además, noofrece ninguna garantía de que se encuentre el recurso solicitado, aún cuandoexista.

3. Modelo puro o totalmente descentralizado: corresponde a la tercera gene-ración de redes P2P, en la que ciertos pares son seleccionados como superpares(ver parte central de la Figura 2.2). Estos gestionan el tráfico dirigido haciaotros pares y se actualizan a medida que se conectan nuevos pares o se des-conectan. Además, los superpares están conectados entre sí y cada nodo parmantiene un pequeño número de conexiones con algunos superpares. Estaarquitectura tiene dos ventajas principales: vuelve a la red escalable graciasa una reducción en el número de nodos involucrados en el encaminamientoy al volumen de tráfico entre ellos y ofrece un rendimiento (i.e., tiempo derespuesta) comparable al de la arquitectura P2P centralizada.

2.1.2. Transacciones

Una transacción (Tanenbaum and Steen, 2007) es un conjunto de operaciones quedebe ser realizado por un sistema. La característica más importante de una transac-ción es que requiere que todas sus operaciones se ejecuten o, de lo contrario, nose ejecuta ninguna operación. De esta manera, el sistema que las ejecuta siempremantiene un estado correcto. Las operaciones de una transacción pueden ser lla-madas del sistema, procedimientos de biblioteca o instrucciones de un lenguaje deprogramación, según la implementación. Esta propiedad de todo o nada es una delas cuatro características que tienen las transacciones.

De manera más específica, las transacciones son (Coulouris et al, 2005):


1. Atómicas: para el mundo exterior, una transacción es indivisible, por lo queante un fallo en su ejecución no puede quedar como realizada parcialmenteen el sistema.

2. Consistentes: una transacción no viola las reglas del sistema en que se ejecuta.

3. Aisladas: las transacciones concurrentes no interfieren entre sí.

4. Durables: una vez que se confirma una transacción, los cambios son perma-nentes.

La primera propiedad clave que presentan todas las transacciones es que son ató-micas. Esta propiedad garantiza que cada transacción ocurra completamente o seomita y, si ocurre, será en una sola acción instantánea e indivisible. Mientras unatransacción se encuentra en progreso, otros procesos (estén o no involucrados en latransacción) no pueden ver ningún estado intermedio.

La segunda propiedad de las transacciones dice que son consistentes. Esto significaque el sistema tiene ciertas invariantes que deben permanecer siempre, i.e., si semantuvieron antes de la transacción, también permanecerán después. Por ejemplo,en un sistema bancario, una invariante clave es la ley de conservación de dinero.Después de cada transferencia interna, la cantidad de dinero presente en el bancodebe ser la misma que existía antes de la transferencia, pero por un breve momentodurante la transacción, esta invariante puede violarse. Sin embargo, la violación noes visible fuera de la transacción.

La tercera propiedad se refiere a que las transacciones son aisladas o seriales. Estosignifica que si dos o más transacciones se están ejecutando al mismo tiempo, paracada una de ellas y para otros procesos, el resultado final luce como si todas lastransacciones se ejecutaran en secuencia o en cierto orden, según el sistema.

La cuarta propiedad estipula que las transacciones son durables. Esto se refiereal hecho de que una vez confirmada una transacción, no importa qué suceda,la transacción continúa y los resultados se vuelven permanentes. Ninguna fallaocurrida después de la confirmación puede deshacer los resultados u ocasionar quese pierdan.

Las transacciones son fundamentales en los sistemas distribuidos que requieren deoperaciones con las características que ya se mencionaron previamente. Tal es elcaso de Blockchain (Mattila, 2016), uno de los componentes base de la arquitecturapropuesta sobre el que ahondamos a continuación.


2.2. Blockchain

Blockchain (Mattila, 2016) es una bitácora distribuida que almacena informaciónde transacciones entre dos partes. Estas transacciones se hacen en una red P2P queusa un modelo distribuido (i.e., no hay clientes ni servidores fijos, sino una serie denodos que se comportan como iguales entre sí). En esta red, cada nodo debe aprobaruna transacción, antes de que sea agrupada y almacenada en una estructura a la quese le denomina bloque. Cada bloque generado, está enlazado al bloque siguientey al anterior, formando una cadena de bloques que tiene como propiedades másimportantes que es inmodificable e irreversible.

La Figura 2.3 muestra cómo están estructurados los bloques de una cadena en Block-chain. Cada bloque contiene una lista de transacciones válidas recientes, algunosmeta-datos y una referencia criptográfica al bloque anterior, así como al siguiente.

Figura 2.3 – Estructura de los bloques de una cadena en Blockchain

2.2.1. Transacciones en Blockchain

Las transacciones en sistemas que implementan Blockchain, como es el caso deBitcoin (Nakamoto, 2018), se hacen de la siguiente manera:

Suponga que Alicia quiere enviar dinero a Beto. Para hacerlo, Alicia crea en sucomputadora una transacción, la cual debe hacer referencia a una transacción previaen la cadena de bloques en la que ella recibió fondos suficientes, así como su claveprivada para los fondos y la dirección de Beto. Después, esa transacción se envía aotras computadoras (o nodos) de la red. Los nodos validarán la transacción siempreque haya seguido las reglas apropiadas. Luego, los nodos aceptan la informaciónque se agrega en un nuevo bloque. Este procedimiento es llevado a cabo por unsubconjunto de nodos a los que se les denomina mineros, los cuales organizan lastransacciones válidas en los llamados bloques.


Una transacción entre Alicia y Beto está compuesta por tres elementos: 1) la entradade la transacción, que es la dirección desde la que se envía dinero, o en este casobitcoins; 2) la salida de la transacción, que es la dirección a la que se envían esosbitcoins y 3) la cantidad de bitcoins enviados. En la Figura 2.4 se muestra undiagrama del flujo que sigue una transacción en Blockchain.

Figura 2.4 – Flujo de una transacción en Blockchain

En los sistemas basados en Blockchain como Bitcoin (Nakamoto, 2018) y Ethe-reum (Wood, 2014), los mineros compiten para completar nuevos bloques en unproceso denominado prueba de trabajo, el cual consiste en resolver un desafíomatemático que requiere mucho procesamiento y que es exclusivo de cada nuevobloque. Así, el primer minero que resuelva el desafío obtendrá una recompensaen criptomonedas. Ese desafío matemático consiste generalmente en adivinar unnúmero, llamado semilla, que se combina con el resto de datos de las transaccionesorganizadas en cada bloque y se obtiene su código Hash. Este código Hash debecumplir ciertas condiciones, pero si no lo hace el minero prueba otra semilla alea-toria y vuelve a calcular el código Hash. Se necesita una gran cantidad de intentospara encontrar un código Hash válido.

Así, cuando un nodo se convierte en el primero en resolver el reto para un nuevobloque, envía el bloque al resto de la red para que lo apruebe y recibe criptomonedascomo recompensa. La dificultad del proceso está codificada en el protocolo de lacadena de bloques. Bitcoin y Ethereum están diseñados para que cada vez seamás difícil resolver un bloque. Como cada bloque también contiene una referenciaal anterior, los bloques están matemáticamente encadenados. La alteración deun bloque anterior requeriría repetir la prueba de trabajo para todos los bloques

2.2 Blockchain 27

subsecuentes de la cadena, lo cual requiere también una gran cantidad de tiempode procesamiento. Por esta razón, si algún nodo pretende alterar la cadena, dichonodo deberá tener un alto poder de procesamiento para completar esa secuencia decálculos por cada bloque, antes que todos los mineros.

Dos de las propiedades más importantes de Blockchain son:

Seguridad: los métodos de seguridad de Blockchain incluyen el uso de crip-tografía de llave publica, donde la llave publica es la dirección del usuarioen Blockchain. La información sensible de los usuarios, como datos fiscales ohistoriales médicos, se cifra. De esta manera, dicha información está protegidafrente a robos, manipulación o ataques informáticos por parte de terceros, yaque no existe de forma centralizada en ninguna base de datos.

Replicación: el carácter distribuido de Blockchain garantiza que, en caso deque un nodo se desconecte, no se presentan caídas de los servicios que seofrecen porque toda la información está distribuida en otros nodos, en vez deestar centralizada en servidores únicos. Así, si alguna de las partes de la reddeja de estar disponible, el resto sigue funcionando.

Blokchain se ha integrado en múltiples áreas. Su principal uso es como una bitácoradistribuida para el registro de transacciones monetarias, que usan criptomonedascomo medio de intercambio. En Blockchain también es posible el uso de contratosinteligentes, que son programas que se ejecutan por completo o parcialmente sin in-teracción humana. Existen plataformas que soportan el uso de contratos inteligentes,tales como Ethereum, de la cual hablamos con mayor detalle a continuación.

2.2.2. Ethereum

Ethereum (Wood, 2014) es una plataforma que usa Blockchain y que permite laejecución de contratos inteligentes y aplicaciones descentralizadas. Desde un puntode vista general, Bitcoin y Ethereum coinciden en el uso de la tecnología Blockchain,pero difieren en su propósito. Bitcoin usa Blockchain únicamente para ofrecer unaalternativa al dinero, como se conoce actualmente. Por su parte, Ethereum puede servista como una versión especializada de una máquina de estados, criptográficamentesegura, que se basa en transacciones.

Ethereum fue lanzada en 2015 con su propia criptomoneda, llamada Ether, bajolos mismos principios de funcionamiento de Bitcoin. Sin embargo, Ethereum es


Figura 2.5 – Los nodos en la red cambian de estado tras una transacción válida completada.

programable, por lo que permite a los desarrolladores realizar aplicaciones descen-tralizadas, las cuales básicamente son nuevos tipos de aplicaciones que aprovechanla naturaleza descentralizada de Blockchain.

Estas aplicaciones descentralizadas, llamadas DApps, tienen los beneficios de lascriptomonedas y de la tecnología Blockchain. Son confiables puesto que, una vez queson publicadas en Ethereum, siempre se ejecutan como se espera. También puedenmanejar y controlar artefactos digitales con el fin de crear, por ejemplo, nuevasaplicaciones financieras que, por ser descentralizadas, no tienen una entidad que lascontrole.

La estructura de Ethereum es similar a la de Bitcoin en que se trata de un registrocompartido del historial completo de las transacciones del sistema y que cada nodoen la red almacena una copia de este historial. La diferencia con Ethereum es quelos nodos almacenan el estado más reciente de cada contrato inteligente, además detodas las transacciones monetarias que, en este caso, son transacciones de Ether (i.e.,el ítem monetario en Ethereum). Si una transacción cumple con los requerimientospara ser válida, se ejecuta un cambio de estado en los nodos de la red. La Figura 2.5hace referencia a este comportamiento.

Para cada aplicación de Ethereum, la red necesita mantener la información delestado de las aplicaciones que ejecuta, incluyendo el balance de cada usuario, elcódigo de todos los contratos inteligentes y el lugar en donde todo está almacenado.En el caso de Bitcoin, la red suma todos los cambios de las transacciones de cadausuario para obtener dicho balance. En Ethereum, se usan cuentas, de modo similara las cuentas bancarias, i.e., los Ether aparecen organizados en una cartera (wallet)que pueden transferirse a otra cuenta.

2.2 Blockchain 29

2.2.3. Contratos inteligentes

Una de las características más importantes de Ethereum es el uso de contratos inte-ligentes, que son programas que funcionan sin posibilidad de censura, inactividad,fraude o interferencia de terceros (Solidity, 2019). Así, para crear alguna aplicacióndescentralizada, no es necesario diseñar e implementar una nueva plataforma Block-chain, sino que basta con programar contratos que se ejecutan en la Blockchain deEthereum.

Los contratos inteligentes son escritos en un lenguaje Turing-completo y se compilanen bytecode que la máquina virtual de Ethereum puede leer y ejecutar en todos losnodos de la red. Así, cada vez que un usuario lleva a cabo una acción, a través de uncontrato inteligente, todos los nodos en la red deben llegar al acuerdo de que esaacción tuvo lugar. A grandes rasgos, los contratos inteligentes pueden:

Fungir como cuentas de múltiples firmas, i.e., que una cantidad es gastada porun usuario sólo si un porcentaje requerido de personas está de acuerdo en queasí sea.

Administrar acuerdos entre usuarios, e.g., la compra de un seguro a otrousuario.

Proveer funcionalidades a otro contrato inteligente, a modo de biblioteca desoftware.

Almacenar información acerca de una aplicación, tal como el registro de undominio o membresías de algún tipo.

La Figura 2.6 muestra un ejemplo de un contrato inteligente escrito en el lenguajeSolidity, en el que se almacena un valor de tipo entero que puede ser consultado,una vez desplegado el contrato.

2.2.4. Multichain

Multichain (Greenspan, 2015) es una plataforma para la creación y el desarrollode Blockchains privadas, ya sea para asuntos dentro de organizaciones o entreellas. Su objetivo es superar un obstáculo real para el despliegue de la tecnologíaBlockchain en el sector financiero institucional, al proporcionar la privacidad y elcontrol necesarios en un paquete fácil de usar. Al igual que el núcleo de Bitcoin delque se deriva, MultiChain es compatible con servidores Windows, Linux y Mac, yproporciona una interfaz de línea de comandos y una API simple.


Figura 2.6 – Ejemplo de un contrato inteligente.

A diferencia de Ethereum, Multichain no soporta contratos inteligentes, pero poseela ventaja de ser configurable, de tener un mejor rendimiento y de ser soportadapor múltiples recursos de forma nativa, por lo que las pruebas de trabajo que serequieren pueden implementarse para dispositivos de bajo consumo energético.

2.2.5. Sistema de Archivos Interplanetario

El Sistema de Archivos Interplanetario (IPFS1 por sus siglas en inglés) es un sistemadistribuido para almacenar y acceder a archivos, sitios Web, aplicaciones y datos(IPFS, 2019) .

En términos generales, IPFS es una Blockchain destinada a almacenar archivos queofrece las ventajas de esta tecnología. Uno de los aspectos clave de IPFS es quedistribuye, hacia cada uno de sus nodos, los archivos que se almacenan en el sistema.Así, permite acceder a los archivos en varias localizaciones, por lo que continuaríansiendo accesibles, aún si dejaran de existir en alguno de los nodos del sistema.Además, IPFS no está administrado por una organización en particular. Por estarazón, es difícil censurar contenidos por parte de una autoridad, puesto que losarchivos que se obtienen de IPFS pueden provenir de diferentes ubicaciones. Estaarquitectura P2P también tiene la ventaja de que los archivos pueden obtenerse delas ubicaciones más cercanas al punto desde el que se hacen las peticiones.

IPFS permite a cada usuario o par de la red, almacenar todo lo que desee localmente.Cuando se añade nuevo contenido a IPFS, lo que se hace es prepararlo en unformato requerido para compartirlo con la ayuda del protocolo de IPFS. Ese nuevo

1Interplanetary File System

2.2 Blockchain 31

contenido añadido es referenciado con una dirección llamada Identificador Únicode Contenido (CID2, por sus siglas en inglés).

2.3. Servicios Web REST

REST (Richardson, 2007) define un conjunto de principios arquitectónicos paradiseñar servicios Web que se centran en los recursos de un sistema. Este conjuntoincluye la forma en la que los estados de los recursos se dirigen y transfieren, a travésdel protocolo HTTP, por múltiples clientes escritos en diferentes lenguajes. Por elnúmero de servicios Web que lo utilizan en los últimos años, REST se ha convertidoen un modelo de diseño predominante para servicios Web (Allamaraju, 2010).

Una de las principales características de un servicio Web de REST es el uso explícitode métodos HTTP en conformidad con la especificación estándar definida por elRFC 2616 (Fielding, 1999). Por ejemplo, GET se define como un método paraproducir datos, el cual puede ser utilizado por una aplicación cliente para recuperarun recurso, para traer datos desde un servidor Web o para ejecutar una consultacon la expectativa de que el servidor Web busque y responda con un conjunto derecursos que coincidan.

REST pide a los desarrolladores que utilicen HTTP de forma explícita y coherentecon la definición del protocolo. Este principio básico del diseño de REST estableceuna correlación individual entre las operaciones de crear, leer, actualizar y borrar(CRUD) y los métodos HTTP. Según esta correlación:

Para crear un recurso en el servidor, hay que utilizar POST.

Para recuperar un recurso, se debe hacer uso de GET.

Para cambiar el estado de un recurso o actualizarlo, es necesario usar PUT.

Para eliminar un recurso, se requiere emplear DELETE.

Para este trabajo, elegimos usar servicios REST, puesto que exponer los recursosde un sistema a través de una API de REST es una forma flexible de proporcionardiferentes tipos de aplicaciones en las que los datos tengan un formato estándar.Esta elección ayuda a satisfacer los requisitos de integración, que son críticos paraconstruir sistemas en los que los datos se puedan combinar fácilmente, para extender

2Content Identifier


o construir un conjunto de servicios de REST básicos y para crear un sistema aúnmayor.

2.4. Streaming

Esta sección está enfocada en dar al lector una síntesis del Protocolo de Transmisiónen Tiempo Real (RTSP3 por sus siglas en inglés) y de Apache Kafka, que sontecnologías utilizadas en la arquitectura propuesta en este tesis.

2.4.1. RTSP

El protocolo RTSP (Schulzrinne, 1998) establece y controla una o varias transmi-siones de medios continuos sincronizados, como audio y video. Por lo general, noentrega los flujos continuos en sí, aunque es posible intercalar el flujo continuode medios con el flujo de control. En otras palabras, RTSP actúa como un controlremoto de red para servidores multimedia. En este protocolo no hay noción deconexión, sino que un servidor mantiene una sesión etiquetada por un identificador.Una sesión RTSP no está vinculada de ninguna manera a una conexión a nivel de lacapa de transporte, como en una conexión TCP. Durante una sesión RTSP, un clientepuede abrir y cerrar múltiples conexiones de transporte confiables para el servidor,con el fin de emitir solicitudes. Alternativamente, el cliente puede usar un protocolode transporte sin conexión como UDP.

2.4.2. Apache Kafka

Apache Kafka (Garg, 2013) es un proyecto de código abierto para la intermediaciónde mensajes. Fue desarrollado por Apache Software Foundation y está escrito enJava y Scala. El proyecto tiene como objetivo proporcionar una plataforma unificada,de alto rendimiento y de baja latencia para la manipulación en tiempo real defuentes de datos. Puede verse como una cola de mensajes que lleva un registro detransacciones distribuidas y puede escalarse masivamente, bajo el patrón de diseñoPublicación-Suscripción (Gamma, 2002). Esta característica es importante paralas infraestructuras de aplicaciones empresariales.

3Real-Time Streaming Protocol

2.4 Streaming 33

Apache Kafka fue originalmente desarrollado por la empresa LinkedIn, la cual lopublicó como software libre a principios de 2011. En octubre de 2012 superó laetapa de incubación de la fundación Apache. En noviembre 2014, varios ingenierosque trabajaron en el proyecto Kafka de LinkedIn crearon una nueva empresa llamadaConfluent, la cual está enfocada en Kafka.

2.5. Seguridad en sistemas de información

La seguridad en los sistemas de información es un aspecto de especial importanciaen el desarrollo de un sistema, como el que proponemos. Ataques con Ransomware4

y otros tipos de malware, ataques por ingeniería social, suplantación de identidad,ataques usando internet de las cosas (IoT5, por sus siglas en inglés), entre otros, hantenido un incremento alarmante en los últimos años (Sobers Rob, 2019).

Por esta razón, es importante que los analistas, diseñadores y desarrolladores cuentencon conocimientos sobre las mejores técnicas y métodos para la creación de sistemasseguros. Baskerville (1993) detalla los métodos de diseño que se han seguido parala creación de sistemas de información seguros, agrupados en tres generaciones. Losmétodos de seguridad iniciales estaban basados en listas de verificación y análisis deriesgos simples. Los métodos que se propusieron posteriormente se centran en laseparación de los elementos del sistema, en cuanto a su complejidad, sobre la quese hace una búsqueda de los puntos críticos del sistema, i.e., aquellos que cuentancon una protección mínima para un sistema de información completo. Finalmente,los métodos más recientes se enfocan en modelos abstractos del sistema, por loque los cambios en la interacción entre los usuarios y el sistema no afectan lasconsideraciones y propuestas ya realizadas.

En las siguientes subsecciones, damos algunos detalles teóricos de los aspectos deseguridad que se verán involucrados en el desarrollo de nuestra propuesta.

2.5.1. Criptografía asimétrica

La criptografía asimétrica, también llamada criptografía de llave pública (Diffie andHellman, 1976), es un método criptográfico que se usa para conseguir confiden-cialidad en la información mediante un conjunto de operaciones que usan un par

4Tipo de programa que restringe el acceso a determinados archivos de un sistema y pide un rescatepara quitar esta restricción

5Internet of Things


de llaves o claves: una llave pública y una llave privada. Este método introducidopor Diffie and Hellman (1976) da solución a uno de los problemas fundamentalesde la criptografía que es el de la distribución de claves.

El cifrado de clave asimétrica utiliza un par de claves relacionadas matemáticamente,en el que una de ellas descifra los datos resultantes del cifrado que se realiza conla otra. Algunos de estos algoritmos poseen la propiedad adicional de que una delas claves del par no se puede deducir de la otra por ningún método conocido, queno sea el ensayo y error. Con un algoritmo de este tipo, cada usuario sólo necesitaun par de claves. Designando una de las claves del par como privada y la otracomo pública, no se necesita ningún canal seguro para el intercambio de claves.Mientras la clave privada permanezca en secreto, la clave pública puede ser conocidapúblicamente durante un tiempo sin comprometer la seguridad, haciendo que seaseguro reutilizar el mismo par de claves de forma incluso indefinida.

Para que dos usuarios de un algoritmo de clave asimétrica puedan comunicarsede forma segura, a través de un canal inseguro, cada usuario necesita conocer suspropias claves pública y privada y la clave pública del otro usuario.

2.5.2. Firmas digitales

Las firmas digitales son un método robusto de identificación hoy en día. Este me-canismo involucra desde un código de autenticación de mensaje (MAC6, por sussiglas en inglés) el valor del código Hash de algún mensaje o secuencia de interésy protocolos criptográficos. Todas estas técnicas se emplean con el propósito deverificar la integridad de un mensaje principalmente (Pachghare, 2015).

El proceso de firmar digitalmente un mensaje garantiza que su contenido no hayasido alterado durante el envío. Cuando una de las partes (e.g., el servidor con el quese establece comunicación) firma un documento digitalmente, lo que hace es agregaral mensaje el digesto del documento firmado con su llave privada. Posteriormente,el cliente que se conecta al servidor podrá leer el mensaje y además validar suintegridad, así como la identidad del servidor, usando su clave pública.

Para explicar a grandes rasgos cómo funciona el proceso de firma y verificación,podemos considerar el escenario en que Alicia quiere enviar un mensaje a Beto quedebe firmar antes con la ayuda de una aplicación:

6Message Authentication Code

2.5 Seguridad en sistemas de información 35

Figura 2.7 – Modelo del esquema de firma digital

1. Alicia escribe el mensaje que debe ser firmado y presiona un botón en laaplicación para que inicie este proceso.

2. La aplicación de Alicia calcula el código Hash del mensaje.

3. El código Hash obtenido previamente es cifrado con la clave privada de Alicia,i.e., la firma digital del mensaje.

4. La aplicación envía a Beto el mensaje de Alicia con la firma del mensaje.

5. La aplicación de Beto recibe el mensaje de Alicia y descifra la firma, usando laclave pública de Alicia.

6. La aplicación de Beto calcula el código Hash del mensaje de Alicia.

7. El código Hash del mensaje obtenido por la aplicación de Beto se compara conel código Hash descifrado, usando la clave pública de Alicia.

8. Si los códigos Hash son distintos, se asume que el mensaje fue alterado; de locontrario, el mensaje es auténtico.

En la Figura 2.7 se muestra el modelo de una firma, tal como fue descrito anterior-mente.


2.5.3. Certificados digitales

Un certificado digital es un documento digital publicado por una autoridad decertificación (CA7, por sus siglas en inglés). Un certificado digital incluye el nombredel sujeto (la compañía o el individuo que está siendo certificado), la clave públicadel sujeto, un número de serie, una fecha de expiración, la firma de la CA y cualquierotra información relevante.

Una CA es una institución financiera u otra parte confiable, como VeriSign. Laautoridad de certificación es responsable de la autenticación, de manera que debechequear cuidadosamente la información antes de publicar un certificado digital.Los certificados digitales están disponibles públicamente y son contenidos por lasautoridades de certificación en repositorios de certificados.

La CA firma el certificado, ya sea cifrando la clave pública o un valor de código Hashde la clave pública, mediante su propia clave privada. La CA tiene que verificar cadaclave pública individual.

De esa manera, los usuarios deben confiar en la clave pública de la CA. Usualmente,cada CA es parte de una jerarquía de autoridades certificadoras. Dicha jerarquía es, asu vez, una cadena de certificados, empezando por la autoridad raíz de certificación,la cual es Internet Policy Registration Authority (IPRA). IPRA firma certificadosutilizando la clave raíz. La autoridad raíz sólo firma certificados para Autoridadesde Creación de Políticas8, las cuales son organizaciones que establecen políticaspara obtener certificados digitales. De esta manera, las Autoridades de Creación dePolíticas firman los certificados digitales para las CA, las cuales a su vez firman loscertificados digitales para individuos y organizaciones.

2.5.4. Protocolo de seguridad en capa de transporte

SSL9 (Martorell, 2006) es un protocolo de propósito general para establecer comuni-caciones seguras. Fue propuesto en 1994 por Netscape Communications Corporationjunto con su primera versión del navegador. Sin embargo, no fue hasta su terceraversión, conocida como SSL v3.0 que alcanzó su madurez, superando los proble-mas de seguridad y limitaciones de sus predecesores. No es exclusivo del comercioelectrónico, sino que sirve para cualquier comunicación vía Internet y, por lo tanto,también para transacciones económicas.

7Certification Authority8Policy Creation Authorities9Secure Sockets Layer

2.5 Seguridad en sistemas de información 37

SSL está incorporado a muchos navegadores Web, además del navegador de Nets-cape. Hoy constituye la solución de seguridad implantada en la mayoría de losservidores Web que ofrecen servicios de comercio electrónico. SSL está basado en laaplicación conjunta de criptografía simétrica (de clave secreta), criptografía asimé-trica (de clave pública), certificados digitales y firmas digitales para conseguir uncanal o medio seguro de comunicación a través de Internet.

2.5.5. Principales riesgos de seguridad en dispositivosmóviles

En la actualidad existen diversos tipos de ataques y riesgos para los usuarios de dis-positivos móviles (particularmente smartphones) como malware, phishing (Jagatic,2007), fraudes y robo o pérdida del dispositivo. Cada uno de estos riesgos puedenperjudicar al usuario de diferentes maneras.

Por lo general, el éxito en la propagación de cualquier tipo de amenaza informática(exceptuando la pérdida del teléfono) radica principalmente en las estrategias deIngeniería Social que un ciber-delincuente utilice. Para este tipo de dispositivos escomún que se usen, por ejemplo, troyanos que se expanden dando la impresiónde ser algún juego para dispositivos móviles, o incluso el reemplazo de códigosQR (Huidobro, 2009) legítimos por otros que no lo son, con el fin de dirigir alusuario a un sitio que descarga alguna clase de código malicioso. Una vez que elciber-delincuente ha escogido una temática, procede a expandir masivamente algunaamenaza para robar información que se encuentra almacenada en el dispositivo.

Los principales problemas al momento de crear aplicaciones móviles son defectos enel código, resultantes de las malas prácticas y la falta de entrenamiento y experienciacon respecto a temas de seguridad. Inclusive, los errores más básicos en el códigopueden ser atacados y explotados de muchas formas. Se sabe que aproximadamente50 % de todos los errores y vulnerabilidades ocurren a nivel del código de la aplica-ción (Shahriar, 2012). Algunas de las medidas de programación más básicas paraaumentar la seguridad en las aplicaciones móviles son evitar la escritura explicita(hardcode) de credenciales e información sensible en el código de la aplicación,implementar mecanismos de autenticación y autorización, así como la asignaciónde permisos por parte del sistema. Cabe resaltar también que, aunque el códigogenerado es responsabilidad del programador, una aplicación puede ser atacada sitiene una plataforma vulnerable.


Tomando en cuenta las medidas mencionadas actualmente y muchas otras más, sedesarrolló un estándar de verificación de seguridad en dispositivos móviles, como seexplica a continuación.

2.5.6. Estándar de Verificación de Seguridad en DispositivosMóviles

El Estándar de Verificación de Seguridad en Dispositivos Móviles (MASVS10 porsus siglas en inglés), se usa como una guía para establecer un nivel de confianzaen la seguridad de las aplicaciones móviles (MASVS, 2019). Define dos niveles deverificación de seguridad denominados MASVS-L1 y MASVS-L2 y un conjunto derequerimientos llamado MASVS-R para la resistencia ante ingeniería inversa.

Al satisfacer los lineamientos del nivel MASVS-L1, se consigue tener una aplicaciónsegura que sigue las mejores prácticas de seguridad y no sufre de las vulnerabilidadesmás comunes. El nivel MASVS-L2 añade medidas de seguridad con mayor profun-didad que dan lugar a una aplicación más resistente ante ataques más sofisticados.Finalmente, el nivel MASVS-R ayuda a agregar controles de seguridad extra quepueden aplicarse si se desea prevenir amenazas del lado del cliente. En la Figura 2.8se ejemplifica, a grandes rasgos, el modo en que estas capas de requerimientos sonaplicadas.

Figura 2.8 – Modelo Mobile AppSec

2.6. Amazon Web Services

Desde el 2006, Amazon Web Services (AWS) (AWS, 2006) provee servicios deinfraestructura para tecnologías de la información, en forma de servicios web, más10Mobile Application Security Verification Standard

2.6 Amazon Web Services 39

conocido hoy como cómputo en la nube. Uno de los principales beneficios delcómputo en la nube es la oportunidad de reemplazar importantes gastos anticipadosen infraestructura con costos variables reducidos que se escalan con el negocio.Gracias a la nube, las empresas ya no tienen que planificar ni adquirir servidoresni otras infraestructuras de tecnologías de la información con semanas o mesesde antelación. Pueden disponer, en cuestión de minutos, de cientos o de miles deservidores y ofrecer resultados más rápidamente.

Hoy en día, AWS proporciona una plataforma de infraestructura escalable, confiabley económica, que impulsa cientos de miles de negocios de 190 países de todo elmundo.

2.7. Resumen del capítulo

En este capitulo tratamos los aspectos teóricos que conciernen a nuestra propuesta,que van desde métodos criptográficos como el de criptografía de clave públicahasta el de firmas y certificados digitales. Abordamos también algunas medidas deseguridad que se tomarán en cuenta durante el desarrollo de la aplicación móvily damos detalles de las tecnologías en la nube que usaremos en el desarrollo denuestra arquitectura.

En el Capítulo 3, hablamos de algunos sistemas basados en Blockchain que han sidodesarrollados.


Trabajos relacionados 3En este capítulo mostramos, a grandes rasgos, algunos sistemas basados en Block-chain y en tecnologías en la nube. En la Sección 3.1 nos enfocamos en algunossistemas de denuncia que se han implementado en México. Después, en la Sec-ción 3.2, mencionamos dos sitios Web destinados a la recolección de denunciasen forma anónima. En la Sección 3.3 damos algunos detalles de sistemas basadosen Blockchain, algunos con un enfoque social y otros con un interés tecnológico yexperimental. Finalmente, en la Sección 3.4, hacemos énfasis especial en algunasaplicaciones descentralizadas.

3.1. Sistemas de denuncia

La Dirección General de Asuntos Internos de la Secretaría de Seguridad Pública dela ciudad de México cuenta con formato único de denuncia de abusos policiales oactos de corrupción vía Internet.

Existe también un sistema llamado MP Virtu@l 2.0 (MPVirtual, 2019), que brinda ala ciudadanía la posibilidad de ratificar, mediante su firma electrónica, la Querellao Acta Especial formulada vía Internet. Una vez analizada su solicitud, en caso deque si proceda el inicio de una Carpeta de Investigación o Acta Especial, el usuariorecibirá en su correo electrónico de contacto, el formato ratificado que tambiéncontendrá la firma electrónica del Ministerio Público. Este documento, acorde alo señalado por los Artículos 7, 8 y 9 de la Ley de Firma Electrónica de la Ciudadde México, tiene la misma validez de los documentos que se generan y firman enpapel, por lo tanto serán aceptados por las entidades públicas, como si se tratasende documentos con firma autógrafa.

Por otro lado, se encuentra disponible el portal de denuncia ciudadana de la Cuidadde México (DenunciaCDMX, 2019) que permite realizar denuncias por Internet antela Policía Federal, aunque no cuenta con mecanismos para verificar la identidad delas personas que realizan las denuncias.

41

3.2. Sistemas con anonimato

Existen sitios como Wikileaks (Wikileaks, 2019) y Mexicoleaks (Mexicoleaks, 2019)en los que puede publicarse información delicada o confidencial de interés social.La información que se sube a estos sitios es analizada por un grupo de personasantes de publicarse. Para el envío de información, se requiere el uso del exploradorTor (Torbrowser, 2019) y se sugiere tomar otras medidas para aumentar el grado deanonimato de los contribuyentes del sitio.

3.3. Sistemas que usan Blockchain

Se han propuesto sistemas de diversa índole que aprovechan las ventajas que ofreceBlockchain. Tal es el caso de Bitcoin (Nakamoto, 2018) que, como se mencionóen el Capítulo 2, es un sistema de dinero electrónico en el que pueden hacersetransacciones, de manera anónima y segura, en una red P2P (Martins, 2016).

Por otro lado, existen sistemas con aplicaciones en el campo de la Medicina, comoMedRec (Azaria et al., 2016), un sistema descentralizado de administración deregistros médicos electrónicos. MedRec brinda a los pacientes un registro completoe inmutable y un acceso fácil a su información médica entre los proveedores y lossitios de tratamiento.

También se ha usado Blockchain para el desarrollo de una plataforma de administra-ción de datos personales enfocada en la privacidad (Zyskind et al., 2015). En estaplataforma se combina el almacenamiento de información en una Blockchain y fuerade ella, i.e., de forma convencional.

Existe un trabajo desarrollado por Ekbote et al. (2017) en el que se hace unaimplementación de un sistema de remuneraciones basado en Blockchain. En estaimplementación, se realiza el procesamiento de datos en una CPU y en GPUs conla ayuda de CUDA (Garland et al., 2008). De esta manera, se muestra cómo sepuede superar el rendimiento del proceso de pruebas de trabajo en GPUs, cuando sesobrepasa un número determinado de bloques.

42 Capítulo 3 Trabajos relacionados

3.4. Aplicaciones descentralizadas

Las aplicaciones descentralizadas (DApps) (Cai, 2018) son aplicaciones que usan latecnología Blockchain para que los usuarios se relacionen directamente entre ellos,realicen transacciones y cierren acuerdos, sin que exista una entidad central queesté a cargo del servicio.

Actualmente existe una gran cantidad de aplicaciones descentralizadas, en su mayo-ría, para la plataforma Ethereum.

El sitio State of the DApps (stateofthedapps, 2019) muestra que actualmente existenmás de 1900 aplicaciones descentralizadas. State of the DApps es un directorio deaplicaciones descentralizadas creado para categorizar los proyectos desarrollados enEthereum. Cerca del 50 % de los desarrollos registrados corresponde a juegos pararealizar apuestas o recolectar algún tipo de ítems.

En el Cuadro 3.1, se presenta una comparativa de algunas de las aplicaciones regis-tradas en el sitio State of the DApps. El principal criterio para elegir las aplicacionesmostradas es la cantidad de usuarios activos que tienen, pues es un indicador delnivel de utilidad que puede tener una aplicación para los usuarios.

Los aspectos considerados: si es posible usar la aplicación a través de un dispositivomóvil, si hace énfasis en el anonimato de los usuarios, el enfoque o categoría quetiene el proyecto, i.e., si se trata de un proyecto que pretende dar solución a unproblema social o si es de entretenimiento o índole comercial.

Aplicación Móvil Categoría Anonimato Plataforma

IDEX No Intercambio Sí EthereumForkDelta No Intercambio Sí EthereumOmiseGO No Billetera Sí Ethereum333 ETH No Inversión Sí EthereumKarma Sí Social No EOSIlocalethereum No Intercambio Sí EthereumFomo3D No Apuestas Sí EthereumBancor No Intercambio Sí EthereumCryptoKitties No Juego Sí EthereumPoWH 3D No Apuestas Sí Ethereum

Cuadro 3.1 – Comparativa de algunas de las aplicaciones registradas en el sitio State Of theDApps

3.4 Aplicaciones descentralizadas 43


Existen sistemas que usan Blockchain para diversos fines, que van desde sistemas conun enfoque social hasta sistemas que se desarrollan para innovar tecnológicamente.Sin embargo, actualmente no existe uno con un propósito similar al nuestro. Una vezque hemos detallado las bases del sistema que proponemos y que hemos mostradoalgunos enfoques de sistemas que usan tecnologías similares, en el siguiente capitulointroduciremos los aspectos tomados como base para la arquitectura, que son losque nuestra propuesta debe cubrir para cumplir adecuadamente con su propósito.

44 Capítulo 3 Trabajos relacionados

Análisis y diseño de laarquitectura del sistema

4Para el desarrollo de una arquitectura es necesario conocer los aspectos del sistemaque se pretende modelar y construir. Estos aspectos van desde las entidades queparticipan en el sistema y el modo en que interactúan entre ellas, hasta la forma enque se envía o almacena la información y las tecnologías que pueden usarse. En estecapítulo se describe el análisis y el diseño del sistema propuesto. Particularmente,en la Sección 4.1, se identifican los aspectos clave del sistema, mientras que enla Sección 4.2 se detallan dichos aspectos, los cuales están relacionados con laescalabilidad, usabilidad, infraestructura, anonimato y seguridad. A continuación,en las Secciones 4.3 y 4.4, se describen respectivamente los componentes principalesdel sistema, así como su arquitectura general. Finalmente, en la Sección 4.5, sedetalla la interacción de los diferentes componentes del sistema.

4.1. Aspectos clave del sistema

Como en todo sistema computacional que manipula información sensible y que seráusado por una gran cantidad de usuarios, se requiere tomar medidas de seguridaden su diseño. Además es importante que el sistema sea extensible, i.e., que per-mita realizar mejoras en el futuro, que pueden ser desde aspectos simples comoun cambio en la presentación de la información, hasta la incorporación de nuevoscomponentes a la arquitectura. Para lograr esto, es necesario que cada componentedel sistema mantenga cierto grado de independencia con respecto al diseño de losotros componentes. Por lo tanto, se debe evitar, a lo largo de todas las fases del desa-rrollo del proyecto, que los componentes presenten un alto grado de acoplamientoentre sí, de modo que un cambio en un componente no desencadene cambios enlos componentes que estén relacionados al mismo. También es importante que lainterfaz de usuario sea fácil de usar.

Finalmente, puesto que se busca ofrecer la posibilidad de realizar denuncias deforma anónima, se requiere un mecanismo que permita llevar a cabo esa tarea.Generalmente, para conseguir anonimato en Internet, se usa la herramienta Tor

45

(Torproject, 2019), que permite realizar transacciones entre dos puntos de la redindirectamente, distribuyendo las transacciones por varios puntos en Internet paraevitar que se pueda deducir cuál es exactamente el destino de una transacción enconcreto.

En la Sección 4.2, se tratan estos aspectos con mayor detalle, haciendo una propuestade solución para cada uno de ellos.

4.2. Problemas de diseño

En las fases iniciales del análisis de este trabajo, se abordaron diversos problemas dediseño en múltiples ámbitos. A continuación, se describen aquellos problemas quetuvieron un impacto directo en el diseño del sistema.

4.2.1. Escalabilidad

La escalabilidad de un sistema (Martínez, 2013) se refiere a su capacidad paramanejar, de manera fluida, el crecimiento continuo de trabajo (e.g., un númeroincremental de solicitudes) y para hacerse más grande (e.g., puesta en marchanuevos servidores para satisfacer una demanda) sin perder calidad en los serviciosque ofrece.

El sistema que se propone está diseñado para soportar la agregación de nuevoscomponentes, sin la necesidad de modificar significativamente los ya existentes. Esteaspecto es importante, puesto que la información que se recolecta puede ser deutilidad para organizaciones interesadas en temas de seguridad y bienestar social.Así, la agregación de componentes que muestren estadísticas o que permitan lainteracción con los datos que poseemos, podría aumentar la utilidad y el tiempo devida de nuestro sistema.

Ahora bien, aunado al concepto de escalabilidad, está el concepto de elasticidad,usado principalmente para el cómputo en la nube. La elasticidad es la capacidadde un componente en un sistema para expandir o disminuir su capacidad de pro-cesamiento, cantidad de memoria o recursos de almacenamiento. Esta es una delas ventajas más importantes de desarrollar un sistema en la nube puesto que, enprincipio, se usa y se paga únicamente la cantidad de recursos necesaria para laoperación de un sistema. Sin interrumpir la operación del mismo, sus recursos

46 Capítulo 4 Análisis y diseño de la arquitectura del sistema

pueden expandirse para seguir operando de forma habitual en momentos de altademanda.

4.2.2. Usabilidad

La usabilidad de un sistema (Sánchez, 2011) hace referencia a la facilidad de uso,ya sea de una página Web, una aplicación móvil o cualquier otro sistema con elque interactúe un usuario. El concepto generalmente se refiere a una aplicacióninformática o un aparato, aunque también puede aplicarse a cualquier sistema hechocon algún objetivo particular. También se refiere a métodos para mejorar la facilidadde uso durante el proceso de diseño.

Buscamos que el uso de una aplicación móvil no represente una tarea complicada ylarga para los usuarios, al realizar una denuncia, puesto que uno de los propósitosdel sistema es facilitar el procedimiento de denuncias y ponerlo al alcance de todaslas personas que cuenten, al menos, con un dispositivo móvil.

4.2.3. Infraestructura

Sistemas como el que proponemos deben tener la capacidad de dar respuesta agrandes cantidades de usuarios en poco tiempo, por lo que es necesario contar conservidores de gran capacidad de procesamiento para garantizar estas respuestas. A suvez, estos servidores son costosos tanto en su adquisición como en su mantenimientoy requieren de personas calificadas para la configuración, puesta en marcha yadministración de cada una de las tecnologías que son usadas en el sistema.

Otro problema relacionado a la infraestructura es que existen intervalos en los que laactividad de los usuarios es muy baja y no se usa toda la capacidad de los servidores,lo que lleva a que no se aproveche toda la infraestructura por la que se paga.

4.2.4. Anonimato

Durante el proceso de denuncia anónima existen dos principales complicaciones.La primera de ellas es el hecho de que, en una denuncia anónima, debe evitarse elalmacenamiento de información que permita identificar a la persona que la realiza.Esto representa una complicación para los sistemas, puesto que, para mostrar el

4.2 Problemas de diseño 47

Figura 4.1 – El usuario interactúa con el sistema a través de su dirección asignada enEthereum y de un contrato que corresponde a una denuncia

estado de una denuncia, es necesario asociarla a la persona que va a consultarla,quien generalmente es la misma persona que realiza la denuncia.

La segunda complicación es en cuanto a la posibilidad de rastrear el origen y eldestino de las denuncias, por lo que una denuncia podría relacionarse a un origeno usuario. Este problema se resuelve actualmente usando herramientas como Tor(Torproject, 2019). Sin embargo, esta herramienta no tiene un kit de integraciónpara aplicaciones en Android, por lo que debemos proponer un mecanismo con elque se consiga algo similar a lo que Tor hace.

Como mostramos en la Figura 4.1, nuestra propuesta consiste en utilizar la Block-Chain de Ethereum y contratos inteligentes para conseguir pseudo-anonimato. Pla-neamos usar un conjunto de direcciones de Blockchain, del mismo modo en que seusan nodos en Tor, aunque no nos centramos en ocultar el origen de las denuncias,sino en la identidad de quien denuncia. Cada usuario tiene asociada una direccióncon la que publica contratos inteligentes en Ethereum y por medio del contrato sehace la modificación y el seguimiento de las denuncias.

4.2.5. Seguridad

El sistema debe proteger los datos personales de los usuarios, así como los de lasdenuncias realizadas. Existen varios puntos en el sistema en los que la informaciónde los usuarios y las denuncias pueden estar expuestas. El primero de ellos es laaplicación móvil; el segundo es los canales de comunicación y el tercero es losdistintos servidores del sistema.

Para proteger la confidencialidad de los datos en la aplicación móvil y los servidores,se podrían emplear algoritmos de cifrado.


Para proteger los datos durante su transferencia, se podría hacer uso de protocolosseguros que implementan SSL o alguna estrategia que agregue una capa extra decifrado para los datos en tránsito.

Para corroborar la protección de los datos y de los componentes de la arquitectura, seproponen pruebas de penetración sobre la aplicación móvil y los servidores, así comomedidas que serían necesarias en la implementación para mitigar los problemas máscomunes y los más críticos.

4.3. Vista estática del sistema

En esta sección, modelamos las entidades involucradas en el sistema propuesto, asícomo sus relaciones.

4.3.1. Participantes del sistema

El sistema tiene varios perfiles de participantes:

Ciudadano: realiza denuncias desde una aplicación móvil de manera anónimao formal. Puede revisar el estado de su denuncia y puede solicitar revisiones,en caso de considerar que su denuncia no fue debidamente atendida.

Agente: tiene la tarea de calificar cada denuncia como valida o invalida.Además debe dar los detalles de cada invalidación que realice.

Supervisor: puede ver los detalles de la actividad de los Agentes, como sucantidad de denuncias aceptadas y rechazadas, además de otros indicadoresque se generen con datos del sistema.

Administrador: puede ver los detalles de todos los usuarios del sistema,además de todos los indicadores.

4.3.2. Denuncias

Una denuncia es la unidad de intercambio de información más importante delsistema. Para fines prácticos, se enumeran 8 categorías de denuncias en las que sepuede elegir si se realizan de forma anónima o si se incorporan los datos del usuarioque realiza la denuncia. Las categorías incluidas son las siguientes:

4.3 Vista estática del sistema 49

Delitos tecnológicos

Drogas

Homicidio

Secuestro

Terrorismo

Explotación sexual

Maltrato

Asalto

Para cualquiera de estas categorías de denuncias, aplican dos formas de realizarlas,una forma es de manera anónima y la otra es de manera formal. A continuacióndetallamos las características de ambas modalidades de denuncia.

Modalidades de denuncia

Se aceptan denuncias anónimas, que no incluyen datos de la persona que las realizay denuncias formales, que son aquellas que requieren de la identificación de lapersona que las realiza. Cada tipo de denuncia sigue un proceso que se describe acontinuación.

Denuncias formales

Las denuncias formales tienen las siguientes características:

Siguen un formato pre-establecido en el que deben mostrarse datos personalespara ser formalizadas.

Son revisadas y aprobadas por una autoridad, que en este caso será un agentede policía.

Debe notificarse, a la persona que denunció, el estado de la denuncia presenta-da después de su revisión por algún agente.

Si la denuncia es rechazada, debe indicarse la razón del rechazo y debeofrecerse la posibilidad de solicitar una revisión en la que debe participar unnúmero determinado de revisores.


Cada operación realizada con relación a una denuncia es registrada en unacadena de bloques, desde que es enviada y validada, hasta que se reporta suaceptación.

Denuncias anónimas

Las denuncias anónimas presentan las características que se enlistan a continua-ción:

Siguen un formato pre-establecido.

Se envían a personas calificadas para la revisión de información sensible.

Para ser aprobadas o desaprobadas, deben ser sometidas a un consenso.

Si la denuncia es rechazada, debe indicarse la razón del rechazo y debeofrecerse la posibilidad de solicitar una revisión en la que debe participar unnúmero determinado de revisores.

No revelan la identidad del usuario, pero tienen validez por el hecho de que elusuario forma parte de la comunidad.

4.4. Arquitectura general

Nuestro sistema está compuesto principalmente por cuatro bloques:

1. Aplicación móvil en Android: es el punto inicial del flujo en el sistema. Desdela aplicación móvil se realizan las denuncias.

2. Sistema de archivos interplanetario: IPFS es el punto principal en el quese almacenan los archivos que contienen la información de las denunciasrealizadas por los usuarios.

3. Infraestructura de Amazon Web Services (AWS): provee varios servicios quepermiten desarrollar un sistema escalable y persistente. En AWS se encuentranlos servidores del sistema.

4. Blockchain de Ethereum: en esta Blockchain pública se almacenan los datosde las denuncias dentro de una nueva estructura, con el fin de asegurar que lainformación continuará siendo accesible en caso de que la infraestructura delsistema en AWS se vea afectada.

4.4 Arquitectura general 51

Figura 4.2 – Diagrama de componentes del sistema

En la Figura 4.2 mostramos la forma en que se relacionan los componentes delsistema.

4.5. Vista dinámica del sistema

En las Figuras 4.3 y 4.4 ilustramos la forma en que interactúan los usuarios con elsistema y el flujo que siguen las denuncias a través de todos sus componentes.


Figura 4.3 – Diagrama de secuencia del sistema para registro e inicio de sesión

Figura 4.4 – Diagrama de secuencia del sistema para el envío de denuncias


En este capítulo se detallaron los aspectos técnicos clave del sistema que modelanuestra arquitectura, así como las entidades que fueron consideradas y su interacción.

4.6 Resumen del capítulo 53

Finalmente, introducimos de forma general las características de la arquitectura encuanto a sus bloques e ilustramos la secuencia propuesta del envío de denunciascon el sistema. En el siguiente capítulo mostramos los detalles de la arquitecturapropuesta con mayor profundidad.


Implementación 5En este capítulo se presentan los detalles técnicos de la arquitectura. Presentamosla metodología de desarrollo que seguimos en la sección 5.1. Posteriormente, enla sección 5.2 hablamos de los prototipos que se desarrollaron en relación concada uno de los bloques descritos en el Capítulo 4, definiendo una arquitecturafinal partiendo desde el bloque de la aplicación móvil y las herramientas utilizadaspara su comunicación con otros bloques, hasta los mecanismos que siguen losservicios basados en la nube de Amazon, así como el modo en que interactúanlos componentes que están dentro de cada bloque. Finalmente damos los detallestécnicos de los componentes de la arquitectura final del sistema en la sección 5.3.

5.1. Metodología de desarrollo

Para sistemas como el nuestro, Sommerville (2005) recomienda el uso de unametodología de desarrollo mixta, que combina las mejores practicas del modelo dedesarrollo evolutivo y del modelo de desarrollo en cascada.

Decidimos usar una metodología mixta ya que, a pesar de que el desarrollo evolutivoes una buena opción para crear un proyecto de tamaño medio, como el nuestro, esdifícil establecer una arquitectura estable usando únicamente este enfoque. Esto sedebe principalmente a los cambios continuos que se aceptan en el modelo y a losproblemas que conlleva el desarrollo ágil.

En nuestro caso, desarrollamos prototipos desechables usando un enfoque evolutivopara resolver incertidumbres en el alcance del sistema, debido a que experimentamoscon tecnologías nuevas. Después del desarrollo de varios prototipos aislados y unavez resuelta la mayor cantidad de incertidumbres en sus especificaciones, es posibledefinir nuevamente cómo deben ser los componentes del sistema y reimplementarseusando un enfoque más estructurado, como el que se plantea en el modelo dedesarrollo en cascada.

A continuación, describimos a grandes rasgos los modelos de desarrollo evolutivo yen cascada.

55

5.1.1. Modelo de desarrollo en cascada

Este modelo fue el primero en originarse y es la base de todos los demás modelos deciclo de vida. Lleva un orden estricto en las etapas del desarrollo de un sistema, detal forma que establece que el inicio de cada una de las etapas debe darse hasta lafinalización de la etapa anterior. El modelo establece que debe llevarse a cabo unarevisión final en cada etapa, en la que se determina si el proyecto está listo paraavanzar a la siguiente fase de desarrollo o no (Sommerville, 2005). Las etapas deldesarrollo de un sistema son las siguientes:

Definición de requerimientos: se definen en detalle los servicios, restriccio-nes y metas que el sistema debe cumplir, a partir de consultas con los usuarios.

Diseño del sistema y del software: se dividen los requerimientos de la etapaanterior en unidades de software que conforman una arquitectura completadel sistema. En esta etapa, se describen las abstracciones generadas a partir delas solicitudes de los usuarios y se detallan sus relaciones.

Implementación y prueba de unidades: se lleva a cabo el desarrollo de lasunidades de software ya definidas y se verifica que cada una cumpla con suespecificación.

Integración y prueba del sistema: las unidades de software se integran y seprueban como un sistema completo para asegurar que los requerimientos secumplan. Una vez realizadas las pruebas, de forma satisfactoria, el sistema seentrega al usuario o cliente.

Funcionamiento y mantenimiento: el sistema se instala y se pone en funcio-namiento. También se corrigen errores que no se presentaron en etapas previasy se modifican o agregan unidades del sistema conforme se descubren nuevosrequerimientos.

5.1.2. Modelo de desarrollo evolutivo

El desarrollo evolutivo de basa en la idea de desarrollar una implementación inicial,exponiéndola a los comentarios del usuario y refinándola, a través de las diferentesversiones, hasta que se desarrolla un sistema adecuado. En este modelo existe un aco-plamiento y retroalimentación entre las actividades de las etapas de especificación,desarrollo y validación.

Existen dos tipos de desarrollo evolutivo:

56 Capítulo 5 Implementación

Figura 5.1 – Modelo de desarrollo en cascada

Desarrollo exploratorio: este tipo de desarrollo comienza con las partes delsistema que se comprenden mejor y se agregan al sistema nuevos atributos,que el cliente o usuario propone en un proceso de constante retroalimentación.

Prototipos desechables: en este tipo de desarrollo se busca experimentar conlos requerimientos del sistema que no se comprenden del todo, desarrollandoversiones mejoradas de prototipos a lo largo del proceso.

En la Figura 5.2 se muestra cómo se relacionan las actividades en este modelo dedesarrollo.

Figura 5.2 – Modelo de desarrollo evolutivo

5.1 Metodología de desarrollo 57

5.2. Prototipos desarrollados

Desarrollamos varios prototipos, los cuales están directamente relacionados con loscomponentes finales del sistema que presentamos, a detalle, en este trabajo. Algunosde estos prototipos fueron descartados por completo por una nueva propuesta quellevó, además, a una nueva arquitectura para el sistema. Es por esta razón queel desarrollo del sistema pasó por tres conjuntos de prototipos que definían unaarquitectura diferente. A continuación, presentamos los detalles de cada una de lasarquitecturas con las que experimentamos:

5.2.1. Primera iteración: sistema de denuncias basadoexclusivamente en Blockchain

La característica más importante en esta arquitectura era que, para el almacena-miento de la información de denuncias, se usaba una Blockchain privada creadacon la ayuda de la plataforma Multichain (ver Sección 2.2.4). Además, se proponíauna modificación en el núcleo de la plataforma para realizar el proceso de minado,con dispositivos de bajo consumo energético. Durante el desarrollo, se presentarondiversos inconvenientes con esta implementación de la arquitectura:

Centralización: Multichain es una Blockchain privada, i.e., no se ejecuta enuna infraestructura pública, así que si la infraestructura de servidores en la quese encuentra deja de estar disponible, la base de datos deja de estarlo también.Por esta razón, se pierde una de las ventajas más sobresalientes del uso deBlockchain en un sistema, que es el de la independencia ante una entidad, i.e.,su descentralización.

Poca escalabilidad: para agregar componentes o funcionalidades al sistema,como administrador Web, sería necesario hacer modificaciones en la Block-chain privada que nos provee Multichain, lo que necesita tiempo y esfuerzomayores a los que se requerirían si se usara una base de datos convencional.También, debido a que toda la tarea de administración recae en el dueño delservidor en que se ejecuta Multichain, este debe hacerse cargo del manteni-miento del servicio y de sus configuraciones, las cuales son complicadas.

Complejidad en almacenamiento y recuperación de información: es ne-cesario implementar un programa que realice cierto procesamiento para al-macenar datos en Blockchain y para acceder a ellos. Esta implementaciónrequiere tomar en cuenta diversos aspectos, de acuerdo al tipo de información


Figura 5.3 – Arquitectura inicial del sistema

que se almacenará. Ésta es una de las desventajas más importantes al usarMultichain como base de datos, puesto que fue desarrollada principalmentepara el intercambio de ítems del modo en que se hace en Bitcoin. Por lo tanto,en su diseño no hubo consideraciones para el almacenamiento de datos deotro tipo, como imágenes.

5.2.2. Segunda iteración: sistema de denuncias basado enBlockchain y otros servicios

En la segunda arquitectura propuesta, buscamos corregir la desventaja que teníael uso de Blockchain para almacenar toda la información del sistema, por lo queintegramos un gestor de base de datos a la arquitectura.

Añadimos un servicio para el procesamiento de denuncias, previo al almacenamientode estas en la base de datos, lo cual permitía establecer una comunicación bidi-reccional entre los usuarios del sistema y las autoridades encargadas de revisarlas denuncias. Integramos también un administrador Web para las autoridades,haciendo posible dar respuesta a los usuarios sobre el estado de sus denuncias.

Optamos también por usar Ethereum, una Blockchain pública que resuelve el proble-ma de la centralización que presentaba la arquitectura anterior (ver Sección 2.2.2).Ahora, las denuncias son enviadas al sistema por medio de contratos inteligentes(ver Sección 2.2.3) que contienen la información de las denuncias realizadas por losusuarios.

En esta arquitectura se presentaron dos problemas principales:

5.2 Prototipos desarrollados 59

Figura 5.4 – Segunda arquitectura del sistema, agregando más componentes

Comunicación entre Ethereum y Android: para usar Ethereum con disposi-tivos móviles, es necesario compilar los contratos inteligentes en un nuevoarchivo que la biblioteca web3j requiere para llevar a cabo la comunicaciónentre Android y Ethereum. Es por esta razón que cada cambio en los contratosinteligentes utilizados en el sistema hace necesario publicar una actualizaciónde la aplicación móvil, lo que haría al sistema menos mantenible.

Comunicación entre Ethereum y el servidor de procesamiento de denun-cias: para que esta comunicación se lleve a cabo, es necesario desplegar uncontrato inteligente que hace uso de una biblioteca especial llamada Oracle,diseñada para el envío de mensajes desde Blockchain, por medio del protocoloHTTP. El problema con esta propuesta es que los archivos generados en lacompilación de los contratos inteligentes con la biblioteca Oracle no son com-patibles con web3j, por lo que desarrollar una biblioteca con característicassimilares a Oracle requeriría un esfuerzo considerable.

5.2.3. Tercera iteración: sistema de denuncias basado enBlockchain y tecnologías en la nube

En esta arquitectura, damos solución a los problemas que se presentaron duranteel diseño y el desarrollo de la arquitectura anterior. El cambio más importante, conrespecto a la arquitectura anterior, es que integramos algunas de las tecnologías deAmazon Web Services (ver Sección 2.6).

Usamos AWS Lambda, AWS API Gateway y Mongo Atlas principalmente, para lapuesta en marcha de la infraestructura del sistema. Usando estas tres tecnologías enconjunto, podemos ofrecer servicios que son escalables y mantenibles.


Agregamos también una nueva Blockchain, IPFS (ver Sección 2.2.5) que, a diferenciade las Blockchains de las arquitecturas anteriores, tiene el propósito específico dealmacenar información en forma de archivos. Ahora tenemos dos Blockchain ennuestra arquitectura, una que registrará el historial de transacciones y otra quealmacenará los archivos multimedia de las denuncias realizadas por los usuarios.

Para facilitar el acceso a las denuncias de los usuarios, tomando datos de ambasBlockchains, usamos una base de datos convencional que almacena la relación entrelos datos que se envían a IPFS y los datos enviados a Ethereum. De esta formapodemos acceder a la información de las denuncias sin almacenar su contenidoexplícitamente en la base de datos, manteniéndola integra. Con esta base de datostambién se tiene la ventaja de que puede agregarse otro componente al sistema, sintener que conectarlo directamente a Ethereum o a IPFS.

Figura 5.5 – Diagrama general de la arquitectura final del sistema

5.3. Detalles técnicos de los componentes

A continuación, damos más detalles de cada uno de los componentes del sistema.

5.3 Detalles técnicos de los componentes 61

5.3.1. Aplicación móvil en Android

Nuestra aplicación móvil se ejecuta en sistemas operativos Android, usando laversión 28 del kit de desarrollo (SDK). La aplicación es soportada por dispositivoscon las versiones de Android desde 4.0 hasta 9.0.

Los usuarios realizan las denuncias desde la aplicación, por lo que esta es la parteinicial del flujo en el sistema.

Para la publicación de la denuncia en IPFS, la aplicación usa como base una bi-blioteca desarrollada en el lenguaje Kotlin, llamada IPFS API for Kotlin, que aún seencuentra en fase experimental. Usamos también el SDK denominado Amplify-AWSpara consumir algunos de los servicios de AWS.

La aplicación también se comunica con los servicios en Amazon a través de API-Gateway, usando el protocolo HTTP e intercambiando mensajes estructurados en elformato JSON.

Los archivos multimedia de las denuncias son enviados a IPFS; su referencia esincluida en el mensaje que lleva el contenido de la denuncia y que se envía a AWSpara publicarse en Ethereum.

El historial de denuncias se almacena en la aplicación y puede exportarse paraconservar sus referencias en IPFS y Ethereum.

Seguridad

Posterior a la revisión de la documentación mencionada en la Sección 2.5.6, consi-deramos como base los elementos con los que la aplicación del sistema cumpliría elnivel MASVS-L1 de seguridad. Por tratarse de un listado extenso, incluimos algunosde los más importantes a continuación:

MSTG-ARCH-4: los datos considerados sensibles, en el contexto de la aplica-ción móvil, deben identificarse claramente.

MSTG-ARCH-8: se debe seguir una política explícita sobre cómo se adminis-tran las llaves criptográficas y cómo se lleva el ciclo de vida de las mismas.Idealmente, se debe seguir un estándar como NIST SP 800-57 (Barker et al.,2016).

MSTG-STORAGE-3: se debe evitar la escritura de datos sensibles en los logs dela aplicación.


MSTG-STORAGE-14: si se requiere almacenar información sensible localmente,debe cifrarse con una llave obtenida de un mecanismo físico que involucreautenticación.

MSTG-CRYPTO-1: la aplicación no usa llaves almacenadas explícitamente ensu código para sus operaciones criptográficas.

MSTG-CRYPTO-4: la aplicación no usa algoritmos criptográficos obsoletos.

MSTG-AUTH-1: si la aplicación accede a un servicio externo, debe usarse algúntipo de autenticación como usuario y contraseña.

5.3.2. Infraestructura en Amazon Web Services (AWS)

Para el desarrollo del sistema en nuestra propuesta, consideramos tres serviciosalojados en AWS:

API Gateway: permite establecer comunicación entre los servicios que seencuentran en los servidores de Amazon y cualquier fuente externa que conocela ruta y que está autorizada para usar los servicios.

Lambda: es un servicio de AWS que permite ejecutar funciones cuando sepresenta algún evento en especifico. Estas funciones se ejecutan dentro decontenedores que son creados, de acuerdo a la carga de procesamiento queAWS detecta. Por lo que para tareas grandes, se pueden tener en ejecuciónvarias instancias de la misma función, realizando alguna parte de las tareasdel sistema.

Mongo Atlas: es un servicio de base de datos no relacional que puede serdesplegado y configurado en la nube de AWS o en la nube de Microsoft. Adiferencia de una base de datos administrada, Mongo Atlas está automatizadapara ofrecer los recursos que se necesitan, de acuerdo a la demanda que recibe.

5.3.3. Sistema de Archivos Interplanetario

IPFS es el punto principal en el que se almacenan los archivos que contienenla información de las denuncias realizadas por los usuarios. Puesto que en estaBlockchain sólo se almacenan archivos de forma independiente, a los cuales se tieneacceso con una secuencia que se regresa como respuesta tras el envío del archivo,

5.3 Detalles técnicos de los componentes 63

Figura 5.6 – Arquitectura en AWS

requerimos otro mecanismo para mantener el acceso a los mismos, de forma que serecupere toda la información relacionada con una denuncia.

En IPFS publicamos archivos JSON con el contenido de las denuncias, así comolas imagenes y videos que se incluyen en las mismas. Por esta razón, lo primerose publica es el contenido multimedia de la denuncia y posteriormente un archivoJSON que contiene las referencias a este contenido. Como hemos mencionado, unavez publicado este archivo, se mantendrá en la Blockchain y podrá accederse almismo desde diversos medios.

5.3.4. Blockchain de Ethereum

En esta Blockchain publica, se almacenan los datos de las denuncias dentro deuna nueva estructura, con el fin de asegurar que la información continuará siendoaccesible, en caso de que la infraestructura del sistema en AWS sea eliminada.Para esta tarea, se requiere la creación y el despliegue de contratos inteligentes enBlockchain.



En este capítulo mostramos la arquitectura resultante de un proceso iterativo, elcual consistió en un planteamiento inicial de arquitectura y el refinamiento desus características con respecto a los resultados de las pruebas realizadas en cadaiteración. Este proceso iterativo fue de gran utilidad, puesto que permitió mejorarla estrategia para incorporar Blockchain y el resto de los componentes en unaarquitectura de un sistema, ajustándose a los lineamientos establecidos para resolverel problema planteado en esta tesis. En el siguiente capítulo, presentamos algunasde las pruebas que fueron realizadas para el planteamiento de la arquitectura finaldel sistema.


Pruebas funcionales yresultados

6

En este capítulo, se describen los detalles de las pruebas funcionales realizadassobre los componentes del sistema, con el fin de validar diversos aspectos de laarquitectura propuesta. Los resultados son presentados visualmente, para permitiruna rápida inspección, junto con sus respectivas interpretaciones. Adicionalmente,se introducen los criterios aplicados y las herramientas utilizadas para realizar cadauna de las validaciones descritas.

Comenzamos presentando las pruebas sobre las funciones que se ejecutan en lanube de Amazon. En las Secciones 6.1 y 6.2, mostramos respectivamente las pruebasde las funciones encargadas del despliegue y del manejo de contratos inteligentes.A continuación, en la Sección 6.3, presentamos las pruebas del componente deoperaciones en base de datos. Finalmente, en la Sección 6.4, nos centramos en laspruebas realizadas sobre la aplicación móvil y la funcionalidad de publicación dedenuncias en IPFS.

6.1. Componente de despliegue de contratosinteligentes

Este componente se ejecuta en AWS Lambda. Consiste en un script escrito en ellenguaje Node JS que publica un contrato inteligente en la red de Ethereum. Si elcontrato se despliega correctamente, el componente responde con un mensaje enformato JSON, el cual contiene un campo nombrado statusCode con un valor de“200”. Además de este campo, se incluyen campos relacionados con la operaciónrealizada en Ethereum, como el número de bloque en que se encuentra la transaccióno la dirección del contrato que fue desplegado.

67

6.1.1. Descripción de la prueba

El componente de despliegue de contratos inteligentes se ejecuta sin parámetrosdesde la consola de AWS y se espera la respuesta “200”, descrita anteriormente.

6.1.2. Resultado

En la Figura 6.1, se muestra el resultado exitoso de la ejecución de la prueba en laconsola de AWS. En la Figura 6.2 también se muestra la verificación de la prueba,consultando el contrato creado en Etherscan (Matthew et al., 2015).

Figura 6.1 – Resultado de la ejecución de la función de despliegue de contrato inteligente

68 Capítulo 6 Pruebas funcionales y resultados

Figura 6.2 – Información en Etherscan del contrato inteligente desplegado en la prueba

6.2. Componente de manejo de contratosinteligentes

El manejador de contratos inteligentes consiste en un script, escrito en el lenguajeNodeJS, que permite consultar el contenido de algunos campos de un contratointeligente, por medio de su dirección en Ethereum. El contenido del contrato puedeser modificado únicamente por medio de este script, haciendo una llamada directaal método de modificación especificado en el contrato.


Este componente, desarrollado en una función de AWS Lambda, se ejecuta desde laconsola de AWS, tomando como parámetro un objeto JSON que contiene el campocontractAddress, cuyo valor es la dirección de un contrato inteligente que ya fuedesplegado en Ethereum. Esta función debe actualizar, con un valor de “4”, el estadode la denuncia almacenada en el contrato. Si esta tarea se ejecuta correctamente, lafunción regresa un objeto JSON con un valor de “200” en el campo statusCode yel resultado de la operación en el campo result. En caso de que la operación falle,el valor del campo statusCode será de “500”. Para el caso especifico de la prueba,el manejador escribe el campo statusCode con un valor de “4” en el contrato ydespués verifica si el cambio fue publicado en Ethereum.

6.2 Componente de manejo de contratos inteligentes 69

6.2.2. Parámetros

Al manejador de contratos inteligentes, se envía un objeto JSON que contiene ladirección del contrato inteligente sobre el que se hace la prueba:

{"contractAddress": "0x35Ca232C41b65566cc8694bACEC83a1d45087059"

}

6.2.3. Resultado

En la Figura 6.3, se muestra el resultado exitoso de la ejecución de la prueba en laconsola de AWS.

Figura 6.3 – Resultado de la ejecución de la función de consulta de contrato inteligente


6.3. Componente de operaciones en base dedatos

El controlador de base de datos es un script, escrito en Python 3.8, que realiza ope-raciones de inserción, actualización o eliminación de datos en una base de datos norelacional. Este componente se diseñó para ofrecer, al resto de los componentes delsistema, la posibilidad de realizar operaciones en base de datos sin tener informaciónexplícita de sus parámetros de conexión.


Realizamos una operación de inserción desde el componente descrito hasta la basede datos de pruebas. Indicamos una colección y el valor del documento que seráinsertado. Finalmente verificamos que el dato sea insertado en la base.

6.3.2. Parámetros

El mensaje enviado al componente tiene una estructura JSON con tres campos: 1)collection, que incluye el nombre de la colección en la base de datos, 2) data quecontiene una cadena que sigue un formato JSON con los campos de la colecciónque serán usados en la operación y 3) operation que define la operación que va arealizarse. En nuestra prueba, dichos campos toman los siguientes valores:

{"collection": "test","data": "{\"message\":\"Mensaje de prueba\"}","operation": "insert"

}

6.3.3. Resultado

En la Figuras 6.4 y 6.5, se muestra el resultado de la operación en las consola deAWS Lambda y de Mongo Atlas, respectivamente.

6.3 Componente de operaciones en base de datos 71

Figura 6.4 – Resultado de las pruebas en la consola de AWS Lambda

Figura 6.5 – Resultado de las pruebas en la consola de Mongo Atlas


6.4. Publicación de denuncia en IPFS

La publicación de denuncias en IPFS se hace desde un módulo integrado en unaaplicación en Android. Este componente toma datos de una denuncia desde lainterfaz de usuario. Una vez que se presiona el botón ENVIAR, se toman los datosque fueron introducidos, se agrupan en un string que sigue una estructura JSON yse envían a IPFS.

Figura 6.6 – Pantalla de denuncia en la aplicación móvil


Enviamos una denuncia a IPFS con ayuda de la aplicación móvil que fue desarrolladapara las pruebas. Verificamos desde la consola del IDE que la operación se hayarealizado con éxito. Después, haciendo uso del hash que IPFS responde como

6.4 Publicación de denuncia en IPFS 73

confirmación comprobamos, usando un cliente HTTP, que la denuncia haya sidopublicada en IPFS.

6.4.2. Parámetros

Los parámetros se introducen desde la aplicación móvil, como se muestra en laFigura 6.6.

6.4.3. Resultado

La Figura 6.7 muestra el resultado en consola de la ejecución de la tarea desdela aplicación móvil. El código hash que IPFS asignó a nuestra publicación fueQmac6Ax5mUL6m5ZDvvCL147ipJgrof2jnBVmSkFFUzzdBj. Finalmente, se muestra enla Figura 6.8 la petición realizada a IPFS para obtener los datos de la denuncia quefue enviada.

Figura 6.7 – Resultado de la publicación de la denuncia hacia IPFS mostrado en la consolade Android Studio


En este capítulo mostramos las pruebas funcionales que llevamos a cabo para validarlos componentes planteados en la arquitectura final del sistema. Es importanteresaltar que se probaron prototipos para evaluar la factibilidad de estas implementa-ciones, en términos funcionales y tecnológicos. Una vez que estos prototipos fueronprobados y que se obtuvieron resultados satisfactorios, decidimos mantener estaarquitectura como la propuesta final para el alcance de esta tesis.

En el siguiente capítulo, presentamos nuestras conclusiones, ideas de mejora ytrabajo futuro identificado durante el desarrollo de este trabajo de tesis.


Figura 6.8 – Resultado de la consulta a IPFS usando el hash obtenido en la prueba


Conclusiones y trabajo futuro 7Este último capítulo de la presente tesis está organizado de la siguiente manera.En la Sección 7.1, hacemos una recapitulación del problema que inspiró esta tesis.Después, en la Sección 7.2 presentamos las contribuciones que dan soporte a estetrabajo y las conclusiones derivadas del mismo. Finalmente, en la Sección 7.3, pro-ponemos algunas ideas de mejora y trabajo futuro basadas en nuestras conclusionesy hallazgos.

7.1. Recapitulación del problema

Actualmente los sistemas computacionales tienden a evolucionar al desarrollo ba-sado en arquitecturas en la nube, además de que muchos buscan tener enfoquesdescentralizados. Esta evolución ha dado lugar al desarrollo de nuevas herramientasy tecnologías que hacen posible el diseño de soluciones informáticas, capaces desatisfacer las necesidades de los ciudadanos en muchos de los ámbitos de la vidacotidiana. No obstante, existen aún varias áreas importantes de oportunidad ennuestro país como es el caso de la seguridad.

En la Sección 1.2, mencionamos que la percepción de inseguridad de la poblaciónmexicana es muy elevada y su disposición para denunciar es muy reducida, debido adiversas razones, como la idea de perdida de tiempo, la desconfianza en la autoridad,la dificultad en los trámites, así como la actitud hostil del personal y de la autoridad.Consideramos que el trámite de las denuncias se puede digitalizar para hacerlomás eficiente. Sin embargo, actualmente, no existen sistemas accesibles para losciudadanos, que busquen resolver o mitigar los problemas que originan la falta departicipación de la población.

Como primera parte del desarrollo de un sistema, es importante establecer cómoserá construido y determinar las tecnologías con las que va a construirse.

77

7.2. Conclusiones y contribuciones

La propuesta de arquitectura desarrollada en esta tesis partió desde la noción de laexistencia de la tecnología Blockchain y la tendencia actual por implementarse ensistemas descentralizados.

Experimentamos con diversas arquitecturas tomando ésta tecnología como basey buscando ofrecer descentralización como la característica más importante enel sistema. Sin embargo, durante el análisis y las pruebas de las arquitecturasque se plantearon, encontramos que un sistema completamente descentralizado nodaría solución a los problemas de diseño que planteamos en el Capítulo 4. Fueasí que refinamos nuestra propuesta de arquitectura, dando nuevos enfoques parasolucionar los problemas que se presentaban al experimentar con nuevas tecnologíasy plataformas.

La arquitectura propuesta en este trabajo puede ser tomada como referencia para eldesarrollo de proyectos con intensiones similares y ofrece la ventaja de que algunosde los enfoques propuestos ya fueron probados. Así, las principales aportaciones deesta tesis son:

La propuesta de una solución genérica que puede ser aprovechada comoreferencia para el desarrollo de sistemas en ámbitos similares.

Una arquitectura que incorpora tecnologías emergentes.

El desarrollo y el estudio de prototipos que pueden tomarse como base con-ceptual para nuevos proyectos.

Con esta tesis mostramos que es posible diseñar e implementar sistemas compu-tacionales que usan Blockchain, sin acoplar su funcionalidad exclusivamenteal enfoque de esta tecnología, lo que puede convertir a este trabajo en unanueva referencia en cuanto a la incorporación de Blockchain en sistemascomputacionales.

Exploramos la posibilidad de interactuar directamente con una Blockchain,específicamente IPFS, usando una aplicación móvil, lo que puede dar pasoa nuevas propuestas de aplicaciones que hagan uso del sistema de archivosinterplanetario.

Mostramos que se puede hacer uso del enfoque sin servidores para agilizar eldesarrollo de los servicios de un sistema, además de conseguir la escalabilidad

78 Capítulo 7 Conclusiones y trabajo futuro

de los servicios administrados sin invertir en una infraestructura y herramientasde administración.

7.3. Trabajo Futuro

Durante el planteamiento de las arquitecturas, encontramos diversas oportunidadesde trabajo a futuro. En esta sección listamos los puntos identificados:

Incorporar tecnologías para el uso de módulos de notificaciones en tiempo realhacia los dispositivos móviles y el portal web.

Brindar la posibilidad de que cada usuario, desde su dispositivo, pueda conec-tarse directamente a Ethereum para la consulta de sus denuncias, sin pasarpor la infraestructura principal del sistema.

Implementar un mecanismo colaborativo y de auto regulación para la comuni-dad, en el que intervengan más personas al momento de evaluar las denuncias,para así identificar su veracidad con ayuda de la comunidad que usa el sistema.

Trabajar en una arquitectura que sea agnóstica a la nube en que se ejecuta,eligiendo tecnologías que son referentes o estándares en la industria.

Integrar en la aplicación y en la plataforma web un módulo con funcionalidadcomo la de Tor, con el fin de conseguir completo anonimato al momento deenviar las denuncias al sistema.

Trabajar en conjunto con una entidad gubernamental para modelar mejor losprocesos y los flujos que el sistema debe seguir y, con ello, incorporar nuevoselementos a la arquitectura.

Retomar y desarrollar, con mayor profundidad, cada prototipo propuesto eneste trabajo.

7.3 Trabajo Futuro 79

Acrónimos 8P2P Red de pares

DApp Aplicación descentralizada

IPFS Sistema de archivos interplanetario

REST Transferencia de estado representacional

REST-Appis Aplicación de transferencia de estado representacional

SSL Capa de puertos seguros

CA Autoridad certificadora

IPRA Autoridad de registro de políticas de Internet

AppSec Seguridad en aplicaciones

81

Bibliografía

La impunidad subnacional en México y sus dimensiones IGI-MEX 2018. Disponi-ble en: https://www.udlap.mx/igimex/assets/files/2018/igimex2018_ESP.pdf Consultado el 1 de Noviembre del 2018

Instituto Nacional de Estadística y Geografía. “Encuesta Nacional de Victimización yPercepción sobre Seguridad Pública (ENVIPE)", 2017

R. Avilés, “La censura al periodismo en México: Revisión Histórica y Perspectivas.-azón y palabra 2007. Disponible en: http://www.redalyc.org/articulo.oa?id=199520703007. Consultado el 30 de Octubre del 2018

J. Guevara, L. Chávez, “Impunity in the context of enforced disappearance in Mexico",Eunomía. Revista en Cultura de la Legalidad. Septiembre 2018

J. Mattila, “The Blockchain Phenomenon", Berkeley Roundtable on the internationaleconomy, 2016

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system", Última consulta: 01,Octubre, 2018. Disponible en: http://www.bitcoin.org/bitcoin.pdf

T. Wang, J. Vonk, B. Kratz and P. Grefen, “A survey on the history of transactionmanagement:from flat to grid transactions´´, Distributed and Parallel Databases,2008

A. Azaria, A. Ekblaw, T. Viera and A. Lippman , “MedRec: Using Blockchain for Medi-cal Data Access and Permission Management", 2016 2nd International Conferenceon Open and Big Data, 2016.

G. Zyskind, O. Nathan and A. Pentland, “Decentralizing Privacy: Using Blockchain toProtect Personal Data”, 2015 IEEE CS Security and Privacy Workshops, 2015

B. Ekbote, V. Hire, P. Mahajan, J. Sisodia, Blockchain based remittances and miningusing CUDA. In Smart Technologies For Smart Nation (SmartTechCon), 2017International Conference On (pp. 908-911). IEEE.

G. Wood, “Ethereum: a secure decentraliced generalised transaction ledger", Ethe-reum Project Yellow Paper, 2014.

83

https://www.udlap.mx/igimex/assets/files/2018/igimex2018_ESP.pdf

https://www.udlap.mx/igimex/assets/files/2018/igimex2018_ESP.pdf

http://www.redalyc.org/articulo.oa?id=199520703007

http://www.redalyc.org/articulo.oa?id=199520703007

http://www.bitcoin.org/bitcoin.pdf

Introduction to Smart Contracts. Mayo 2019, Disponible en: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html

Greenspan, G. MultiChain private blockchain—White paper. Disponible en http://www.multichain.com/download/MultiChain-White-Paper.pdf

IPFS is the Distributed Web. Mayo 2019. Disponible en: https://ipfs.io/

N. Kshetri, “Blockchain in Developing Countries", IT Professional, 2018

V. Martins, E. Pacitti, P. Valduriez. “Survey of data replication in P2P systems”.[ResearchReport] RR-6083, INRIA. 2006

S. Bakhtiari, R. Safavi-Naini y J. Pieprzyk, “Cryptographic hash functions: A survey(Vol. 4)”, Technical Report 95-09, Department of Computer Science, University ofWollongong, 1995.

A. Tanenbaum and M. Steen, “Distributed systems: principles and paradigms”,Second Edition, Prentice Hall, 2007

G. Coulouris, J. Dollimore, T. Kindberg y B. Gordon,“Distributed systems: Conceptsand design”, Pearson education, 2005.

I. Sommerville. Software Engineering - Séptima edición. Inglaterra, Pearson Addison-Wesley, 2005.

Cervantes Ojeda, J.; Gómez Fuentes, María del Carmen, Taxonomía de los modelosy metodologías de desarrollo de software más utilizados, Universidades, núm. 52,enero-marzo, 2012, pp. 37-47, Unión de Universidades de América Latina y elCaribe, Distrito Federal, Organismo Internacional, ISSN: 0041-8935

Richardson, L. and Ruby, S. RESTful Web Services. O’Reilly Media, Inc. (2007)

Allamaraju, S. (2010). Restful web services cookbook: solutions for improvingscalability and simplicity. O’Reilly Media, Inc..

Fielding, et al., RFC 2616 - Hypertext Transfer Protocol – HTTP/1.1, Junio 1999.Disponible en https://tools.ietf.org/html/rfc2616.

Schulzrinne, H. (1998). Real time streaming protocol (RTSP).

Sobers Rob, 2019. 60 Must-Know Cybersecurity Statistics for 2019. Disponible enhttps://www.varonis.com/blog/cybersecurity-statistics/

Tor: Overview, Disponible en https://2019.www.torproject.org/about/overview.html.en. Consultado el 2 de Agosto del 2019.

84 Bibliografía

https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html

https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html

http://www.multichain.com/download/MultiChain-White-Paper.pdf

http://www.multichain.com/download/MultiChain-White-Paper.pdf

https://ipfs.io/

https://tools.ietf.org/html/rfc2616

https://www.varonis.com/blog/cybersecurity-statistics/

https://2019.www.torproject.org/about/overview.html.en

https://2019.www.torproject.org/about/overview.html.en

Baskerville, R. 1993. Information systems security design methods: implications forinformation systems development. ACM Computing Surveys, 25(4), 375–414.

Diffie, W., and Hellman, M. 1976. New directions in cryptography. IEEE transactionson Information Theory, 22(6), 644-654.

Martorell S., Gutiérrez L., 2006. Protocolo de seguridad SSL. Ingeniería Industrial,27(2-3), 57-62.

Huidobro J., 2009. Código QR. Bit, dic.-ene, 172, 47-49.

Jagatic T., Johnson N., Jakobsson M., Menczer F. 2007. Social phishing. Communi-cations of the ACM, 50(10), 94-100.

Shahriar, H. y Zulkernine, M. 2012. Mitigating program security vulnerabilities:approaches and challenges. acm Computing Surveys, 44(3)

The Mobile Application Security Verification Standard. Disponible en https://github.com/OWASP/owasp-masvs/releases. COnsultado el 20 de agosto del2019.

V.K.Pachghare, 2015. Cryptography and information security, PHI Learning

Acerca de AWS. Disponible en https://aws.amazon.com/es/about-aws/. Consul-tado el 20 de agosto del 2019.

Ministerio Público Virtual. Disponible en https://mpvirtual.pgj.cdmx.gob.mx/.Consultado el 29 de mayo del 2019.

Denuncia ciudadana por internet ante la Policía Federal, 2019. Disponible en https://denunciaciudadana.cns.gob.mx/. Consultado el 15 de Mayo del 2019.

Wikileaks. 2019. Disponible en https://wikileaks.org/.

Mexicoleaks. 2019. Disponible en https://mexicoleaks.mx/. Consultado el 15 deMayo del 2019.

Torbrowser. 2019. Disponible en https://www.torproject.org/projects/torbrowser.html. Consultado el 15 de Mayo del 2019.

Cai, W., Wang, Z., Ernst, J. B., Hong, Z., Feng, C., Leung, V. C. (2018). Decentralizedapplications: The blockchain-empowered software system. IEEE Access, 6, 53019-53033.

State of the Dapps. 2019. Disponible en https://www.stateofthedapps.com/. Con-sultado el 15 de Mayo del 2019.

Bibliografía 85

https://github.com/OWASP/owasp-masvs/releases

https://github.com/OWASP/owasp-masvs/releases

https://aws.amazon.com/es/about-aws/

https://mpvirtual.pgj.cdmx.gob.mx/

https://denunciaciudadana.cns.gob.mx/

https://denunciaciudadana.cns.gob.mx/

https://wikileaks.org/

https://mexicoleaks.mx/

https://www.torproject.org/projects/torbrowser.html

https://www.torproject.org/projects/torbrowser.html

https://www.stateofthedapps.com/

Martínez, J.F. Implantación de aplicaciones web en entornos internet, intranet y ex-tranet. Disponible en https://books.google.com.mx/books?id=Go6fDwAAQBAJ

Sánchez, Walter. “La usabilidad en Ingeniería de Software: definición y característi-cas”. Ing-novación. Revista de Ingeniería e Innovación de la Facultad de Ingeniería,Universidad Don Bosco. Agosto 2011, Año 1, No. 2. pp. 7-21. ISSN 2221-1136.

Enciso, León Izquierdo. La implementación de la Firma Electrónica en México.Economía, Vol. 369, 2011.

Jalal Feghhi, Jalil Feghhi, and Peter Williams. Digital certificates. Applied InternetSecurity, Addison-Wesley, 1999, ISBN: 0-201-30980-7.

Wen-Li Zhou and Xiao-Fei Wu. Survey of P2P technologies. Computer Engineeringand Design, Vol. 1, 2006.

Damgard, Ivan Bjerre. A design principle for hash functions. In Conference on theTheory and Application of Cryptology. Springer, New York, NY, pp. 416-427, 1989.

Hayes, Brian. Cloud computing. Communications of the ACM, vol. 51, no 7, pp. 9-11,2008.

Garg, Nishant. Apache Kafka. Packt Publishing Ltd, 2013.

Gamma, et al., Patrones de diseño elementos de software orientado a objetos re-utilizable, ISBN:9788478290598, Addison-Wesley professional computing series,2002, Pearson Educación

Nah, Fiona Fui-Hoon; Siau, Keng; Sheng, Hong. The value of mobile applications:a utility company study. Communications of the ACM, vol. 48, no 2, pp. 85-90,2005.

Oyman, Ozgur; Singh, Sarabjot. Quality of experience for HTTP adaptive streamingservices. IEEE Communications Magazine, Vol. 50, no 4, pp. 20-27, 2012.

Garland, M., Le Grand, S., Nickolls, J., Anderson, J., Hardwick, J., Morton, S., andVolkov, V. Parallel computing experiences with CUDA. IEEE micro, vol. 28, no. 4,pp. 13-27, 2008.

Hitzler, Pascal, Markus Krotzsch, and Sebastian Rudolph. Foundations of semanticweb technologies. Chapman and Hall/CRC, 2009.

86 Bibliografía

https://books.google.com.mx/books?id=Go6fDwAAQBAJ

Asit K. Mishra, Joseph L. Hellerstein, Walfredo Cirne, and Chita R. Das. 2010.Towards characterizing cloud backend workloads: insights from Google compu-te clusters. SIGMETRICS Perform. Eval. Rev. 37, 4 (March 2010), 34-41. DOI:https://doi.org/10.1145/1773394.1773400

E. Barker, W. Barker, W. Burr, W. Polk y Miles Smid. Recommendation for KeyManagement. Computer Security Division Information Technology Laboratory

T. Matthew et al. Etherscan. Disponible en https://etherscan.io/.

Bibliografía 87

https://etherscan.io/

Departamento de Computación Arquitectura para un sistema ...

Documents

Transcript of Departamento de Computación Arquitectura para un sistema ...