Sistema de autenticación basado en blockchain para la gestión de billetes en un entorno de transporte inteligente - Máster Universitario en ...
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Sistema de autenticación basado
en blockchain para la gestión de
billetes en un entorno de
transporte inteligente
Máster Universitario en Ciberseguridad
Trabajo Fin de Máster
Autor:
ADRIÁN MONTOYA ROS
Tutor/es:
ANTONIO ZAMORA GÓMEZ
Septiembre 2021
1
Justificación y objetivos
Durante el desarrollo de mi Trabajo de Fin de Grado “Estudio y aplicación de sistemas
de votación basados en tecnologı́a BLOCKCHAIN ” me encontré con un requisito fun-
damental: la identificación de los usuarios que acceden al sistema; para ello realicé una
investigación extensa sobre como poder incorporar este requisito al sistema de votación,
descubriendo que existen redes blockchain orientadas exclusivamente a esta tarea. Por
motivos de simplicidad, implementé este requisito empleando un SaaS (Software as a
Service) de la empresa Trinsic.id que utiliza, por debajo, una red pública blockchain
orientada a la identidad. Todo esto me resultó muy llamativo e interesante, queriendo
investigar y profundizar más acerca del tema.
Este Trabajo de Fin de Máster me ha dado la oportunidad de satisfacer esa curiosidad
que quedó latente con el Trabajo de Fin de Grado, siendo la idea principal profundizar
y ampliar el conocimiento sobre estas redes blockchain orientadas a la identificación;
descubriendo como funcionan, cual es su nivel de seguridad, cuales son los beneficios y
problemas que aportan y cómo pueden ser utilizadas para poder solventar los problemas
que los sistemas de identificación tienen actualmente.
2
3
Agradecimientos
En primer lugar, me gustarı́a darle las gracias a mi tutor, Antonio Zamora Gómez,
por toda la ayuda a lo largo del desarrollo de este proyecto.
Me gustarı́a también dedicar unas lineas a todos mis compañeros durante estos años,
tanto del Grado de Ingenierı́a Informática como del Máster de Ciberseguridad, en es-
pecial a Eddie Rodrı́guez, Rafael Soria, Manuel Alberola, Silvia Veguillas y Jasmina Rais.
Por último y no menos importante, a mi madre. Por permitirme estudiar aquello que al
principio me gustaba y ahora me apasiona, pero sobre todo por el apoyo incondicional
que ha sido muy útil.
4
5
Índice
Índice de figuras 10
1. Introducción 14
2. Identidad 16
2.1. La era de las contraseñas . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1. Problemas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2. Evolución y soluciones . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2. Identidad como servicio - IDaaS . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2. Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.3. JSON Web Token - JWT . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4. Autoridad Certificadora . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3. El futuro de la identidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1. Blockchain IDaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.2. Identidad digital y Auto-Soberana . . . . . . . . . . . . . . . . . . 31
2.3.3. Identificadores descentralizados . . . . . . . . . . . . . . . . . . . . 31
2.3.4. Credenciales verificables . . . . . . . . . . . . . . . . . . . . . . . . 32
3. Blockchain 33
3.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1. ¿Qué es una cadena de bloques? . . . . . . . . . . . . . . . . . . . 33
3.1.2. Criptografı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3. Red descentralizada . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.4. Wallets o monederos . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.5. Otras redes Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.6. Contratos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2. Tipos de Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3. Hyperledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1. Hyperledger Indy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.2. Hyperledger Aries . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.3. Hyperledger Ursa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4. La red Sovrin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6
4. Prototipo 56
4.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2. Descripción del prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3. WEB1: Gobierno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Identificador descentralizado . . . . . . . . . . . . . . . . . . . . . 58
4.3.2. Configurar la credencial . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3. Emisión de credenciales . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4. WEB2: Sanidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.1. Identificador descentralizado . . . . . . . . . . . . . . . . . . . . . 62
4.4.2. Configurar la credencial . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4.3. Emisión de credenciales . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5. WEB3: Trenfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.5.1. Identificador descentralizado . . . . . . . . . . . . . . . . . . . . . 66
4.5.2. Rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.3. Prueba de credencial . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.4. Configurar la credencial . . . . . . . . . . . . . . . . . . . . . . . . 70
4.5.5. Emisión de billete . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.6. Comprobación del billete . . . . . . . . . . . . . . . . . . . . . . . 72
4.6. WEB4: Airberia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6.1. Identificador descentralizado . . . . . . . . . . . . . . . . . . . . . 75
4.6.2. Rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.6.3. Prueba de credencial . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.6.4. Configurar la credencial . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6.5. Emisión de billete . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6.6. Comprobación del billete . . . . . . . . . . . . . . . . . . . . . . . 81
4.7. Wallet móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5. Resultados 86
Bibliografı́a 88
7
8
9
Índice de figuras
1. Estructura ARPANET - Abril 1971 . . . . . . . . . . . . . . . . . . . . . 14
2. Relación entre HTTP, HTML y URL . . . . . . . . . . . . . . . . . . . 15
3. Evolución del número de páginas web . . . . . . . . . . . . . . . . . . . . 16
4. Proceso de registro e inicio de sesión . . . . . . . . . . . . . . . . . . . . . 18
5. Nombre de la cookie según la tecnologı́a del servidor . . . . . . . . . . . . 19
6. Lista de webs con brechas de seguridad . . . . . . . . . . . . . . . . . . . 20
7. Comparativa entre cifrado y funciones resumen . . . . . . . . . . . . . . . 22
8. Ejemplo sistema con conocimiento cero . . . . . . . . . . . . . . . . . . . . 24
9. Diagrama TOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Diagrama OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Diagrama JWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Esquema DID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Esquema Credenciales verificables . . . . . . . . . . . . . . . . . . . . . . . 32
14. Estructura de un bloque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. La cadena de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16. Esquema árbol Merkle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
17. Esquema red P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
18. Prueba de trabajo Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . 38
19. Pasos creación de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
20. Estructura bloque Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . 42
21. Funcionamiento contrato inteligente Kickstarter . . . . . . . . . . . . . . 45
22. Mapa de proyectos Hyperledger . . . . . . . . . . . . . . . . . . . . . . . 47
23. Esquema RBFT de 3 fases . . . . . . . . . . . . . . . . . . . . . . . . . . 48
24. Ejemplo esquema de credenciales . . . . . . . . . . . . . . . . . . . . . . . 49
25. Ejemplo identificadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
26. Esquema emitir una credencial . . . . . . . . . . . . . . . . . . . . . . . . 51
27. Esquema solicitar una credencial . . . . . . . . . . . . . . . . . . . . . . . 52
28. Diagrama relacional Hyperledger Indy, Aries y Ursa . . . . . . . . . 53
29. Logotipo Sovrin - Fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
30. Diagrama del prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
31. Identificador DID de la WEB1 en la red Sovrin . . . . . . . . . . . . . 58
32. Schema credencial WEB1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
33. credential definition credencial WEB1 . . . . . . . . . . . . . . . . . . . . 59
34. Ejemplo QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1035. Aceptar credencial DNI SSI . . . . . . . . . . . . . . . . . . . . . . . . . 61
36. Identificador DID de la WEB2 en la red Sovrin . . . . . . . . . . . . . 62
37. Schema pasaporte COVID . . . . . . . . . . . . . . . . . . . . . . . . . . 63
38. Credential definition pasaporte COVID . . . . . . . . . . . . . . . . . . . 63
39. Ejemplo QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
40. Aceptar pasaporte COVID SSI . . . . . . . . . . . . . . . . . . . . . . . 65
41. Identificador DID de la WEB3 en la red Sovrin . . . . . . . . . . . . . 66
42. ProofRequest para solicitar credencial DNI SSI . . . . . . . . . . . . . . 68
43. Aceptar
presentación DNI SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
44. Schema billete Trenfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
45. Credential definition billete Trenfe . . . . . . . . . . . . . . . . . . . . . . 71
46. Ejemplo QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
47. Aceptar billete Trenfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
48. ProofRequest para solicitar billete Trenfe . . . . . . . . . . . . . . . . . . 73
49. Aceptar presentación billete Trenfe . . . . . . . . . . . . . . . . . . . . . 74
50. Identificador DID de la WEB4 en la red Sovrin . . . . . . . . . . . . . 75
51. ProofRequest para solicitar credencial DNI SSI . . . . . . . . . . . . . . 77
52. Aceptar
presentación DNI SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
53. Schema billete Airberia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
54. Credential definition billete Airberia . . . . . . . . . . . . . . . . . . . . 80
55. Ejemplo QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
56. Aceptar billete Airberia . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
57. ProofRequest billete Airberia y pasaporte COVID SSI . . . . . . . . . 82
58. Aceptar presentación billete Airberia y pasaporte COVID SSI . . . . . 83
59. Menú principal APP Trinsic.id . . . . . . . . . . . . . . . . . . . . . . . 84
60. Pestaña credentials APP Trinsic.id . . . . . . . . . . . . . . . . . . . . . 85
1112
13
1. Introducción
El estilo de vida de los seres humanos ha sufrido grandes alteraciones a lo largo de la
historia, pero sin duda una de las más importantes se debe a la computación, afectando
a la forma de trabajar, al entretenimiento e incluso a la forma de relacionarse social-
mente. Pero para que esta alteración se produjese y maximizar su impacto, era también
necesario una forma de comunicación entre los dispositivos: Internet.
Esta interconexión de dispositivos provocó que se inventará años más tarde la WEB,
un conjunto de tecnologı́as que permitı́an a determinados dispositivos ofrecer contenido
o información a través de Internet. La irrupción de los dispositivos móviles inteligentes
o smartphones también han contribuido a este cambio de estilo de vida, permitiendo
llevar un ordenador y conexión a Internet en el bolsillo, dando lugar también a un nue-
vo producto software exclusivo denominado APPs. De hecho, y gracias a todo esto,
existe un nuevo mercado económico que se basa precisamente en ofrecer servicios a los
usuarios, dando lugar a plataformas de streaming de vı́deo como Youtube, Twitch o
Netflix, páginas web de tiendas como Mediamarkt o Amazon, páginas web de transpor-
te como Renfe o Iberia, e incluso páginas web gubernamentales como Agencia Tributaria.
Pero, ni internet ni los servidores web fueron desarrollados teniendo en cuenta esta for-
ma de uso. En primer lugar, Advanced Research Projects Agency NETwork, abreviado
como ARPANET, fue la primera red de computadoras construida en 1969 en EEUU,
con el objetivo de enviar datos militares y conectar principales grupos de investigación.
Observando la Figura 1, se trataba de una red de pocos dispositivos bien identificados.
Figura 1: Estructura ARPANET - Abril 1971 - Fuente1
1
https://www.xataka.com/historia-tecnologica/mapa-arpanet
14Esta red fue aumentado el número de dispositivos paulatinamente e incorporó nuevas
tecnologı́as, como por ejemplo File Transfer Protocol o FTP en 1971, facilitando el
movimiento de ficheros en ARPANET, o el protocolo TCP/IP en 1983. Gracias a
este último se produjo una estandarización, dando más tarde lugar a la red global que
actualmente se conoce como Internet.
Sin duda alguna, uno de los servicios más caracterı́sticos de internet es World Wi-
de Web, WWW o ((web)). Su origen se remonta a principios de la década de los 90,
cuando el desarrollador Timothy John Berners-Lee se percató que muchos proyectos del
CERN se encontraban dispersos por el planeta, y debı́an iniciar sesión en diferentes dis-
positivos para acceder a ellos. Por esto, él propuso a los gerentes del CERN desarrollar
un sistema de gestión de información, que en primer lugar no fue aceptada, pero que
gracias a la asociación con Robert Cailliau, se perfiló la propuesta y finalmente se le con-
cedió un plazo de desarrollo. El resultado, 3 tecnologı́as: HyperText Markup Language o
HTML, HyperText Transfer Protocol o HTTP y Uniform Resource Locator o URL.
HTML es un lenguaje de marcado que determina la estructura y el contenido de una
página web, siendo interpretado por el navegador web. El protocolo HTTP se encarga
de solicitar y servir este tipo de información. Por último, URL se emplea para la direc-
ción única y especı́fica que se asigna a cada uno de los recursos disponibles de la World
Wide Web, para que puedan ser localizados por el navegador.
Figura 2: Relación entre HTTP, HTML y URL - Fuente2
Como se puede observar en la Figura 2, Internet y la web no incorporan ningún meca-
nismo que tenga en cuenta la identidad del usuario que se encuentra utilizándolo, por
lo que cuando su uso se masificó y las empresas empezaron a vender servicios, tuvieron
estas que implementar por su cuenta una forma de identificar a los usuarios.
2
https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/protocolo-http/
152. Identidad
Un año después de la invención de ((la web)), aparece la primera web de la historia. Se
trata de la página web del CERN la cual todavı́a es accesible3 . El auge de esta tecno-
logı́a fue espectacular, tal y como se aprecia en la Figura 3, y en tan solo un par de años
ya se habı́a alcanzado el millón de páginas webs.
Figura 3: Evolución del número de páginas web - Fuente4
A finales de la década de los 90 se produjo ((la burbuja punto-com))5 . Algunos gigantes
tecnológicos muy populares en la actualidad comienzan a ofrecer servicios a los usuarios
a través de Internet en esa época, como por ejemplo Google, Paypal o Amazon. Pero
para ofrecer un servicio exclusivo a un cliente es muy importante saber diferenciarlo de
otro, y para ello se recurre al concepto de identidad.
3
http://info.cern.ch/hypertext/WWW/TheProject.html
4
https://www.internetlivestats.com/total-number-of-websites/
5
https://medium.com/the-investors-handbook/the-dot-com-bubble-burst-46cf6b27fd9d
16- Definición de identidad
Según la Real Academia Española, la palabra identidad tiene diversas acepciones, entre
las que destaca la siguiente:
“Conjunto de rasgos propios de un individuo o de una colectividad que los carac-
terizan frente a los demás.”
Esta definición se emplea tanto en el mundo digital como en el mundo real, aunque sus
implementaciones son muy diferentes.
- Proceso de identificación
En el mundo real, si se requiere una identificación frente a un policı́a o en un deter-
minado servicio, se suele recurrir a mostrar el documento de identidad oficial, como por
ejemplo el DNI o Pasaporte. Este documento, ha sido expedido por el Estado, entidad
del que todas las partes confı́an, por lo que se trata de un documento válido.
Sin embargo, el proceso clásico de identificación en la web es completamente distin-
to. La web es la que almacena determinada información del usuario, y el usuario el que
debe demostrar su identidad enviando dicha información. El ejemplo más común es el
uso de contraseñas.
2.1. La era de las contraseñas
El primer jueves de marzo se celebra el dı́a mundial de la contraseña. Fue declarado
ası́ por el equipo de seguridad de Intel, basándose en las recomendaciones que Mark
Burnett, investigador de seguridad, publicó en su libro Perfect Passwords de 2005, con
el objetivo de que una vez al año los usuarios cambiasen las contraseñas más crı́ticas.
Pero realmente el concepto de contraseña se remonta hace muchos años, incluso se
podrı́a remontar a la antigua Roma. Se considera a Fernando Corbató como el padre
de la contraseña informática moderna, ya que en 1960, cuando trabajaba en el MIT,
la universidad habı́a desarrollado un sistema de almacenamiento de ficheros primitivo,
denominado Compatible Time-Sharing System o CTSS, al que todos los investigadores
tenı́an acceso y compartı́an una unidad de disco. Para añadirle privacidad a los ficheros
y que solo sus dueños pudiesen acceder, se desarrollo el concepto de contraseña.
17Este método fue y sigue siendo el más extendido en la actualidad, su funcionamiento es
muy sencillo y esta detallado en la Figura 4. En primer lugar el usuario debe registrarse
en el sitio web en cuestión, para ello rellenará un formulario de inscripción indicando un
usuario y contraseña, junto con cualquier otro dato que la web considere imprescindible.
Cabe destacar que normalmente como usuario se hace referencia a una dirección de co-
rreo electrónico. El proceso autenticación es bastante similar, pues el usuario solo tendrá
que indicar el usuario y contraseña. Si estos datos coinciden con los datos almacenados
por la web en su base de datos, el inicio de sesión, y por ende la autenticación, será
exitoso.
Figura 4: Proceso de registro e inicio de sesión
El proceso se repite para cada una de las webs en las que el usuario este interesado
apuntarse, y cada web almacenará la información relativa al usuario que considere. Por
ejemplo Facebook, la red social más utilizada en el mundo6 , podrı́a almacenar mucha
información personal, Linkedin, una red social orientada al trabajo, almacenará infor-
mación laboral, mientras que por ejemplo Netflix, una plataforma de vı́deo en streaming,
almacenará poca información personal pero añadirá información sobre un método de pa-
go. Queda en manos de los dueños de la web recopilar la cantidad de información que
ellos consideren para su servicio.
Tras realizar el proceso de verificación de la identidad y que este sea exitoso, se ne-
cesita un mecanismo que indique a la web que el usuario ya ha iniciado sesión, y que
esta pueda vincularlo con la información almacenada en su base de datos.
6
https://mkparadise.com/redes-sociales-mas-utilizadas
18- Cookies
Las ((cookies)) o galletas en castellano, son un recurso del protocolo HTTP que per-
mite tanto a los navegadores como a los servidores web, enviar información adicional.
Se emplea mediante la cabecera HTTP 7 Cookie y su uso más común es la gestión de
la sesión, almacenando una cadena aleatoria que identifica exclusivamente a un usuario
tras realizar un inicio de sesión. Esta cadena aleatoria es almacenada temporalmente
por el servidor web, de forma que por cada solicitud que el cliente realice, se envı́a dicha
cabecera HTTP y el servidor comprueba si es válida.
Dependiendo de la tecnologı́a empleada para realizar el servidor web, esta cookie re-
cibe un nombre determinado, siendo recomendable cambiarlo por motivos de seguridad.
Tecnologı́a Cookie
PHP PHPSESSID
Microsoft IIS ASPSESSIONID
ASP.Net ASP.NET SessionId
Java JSESSIONID
Figura 5: Nombre de la cookie según la tecnologı́a del servidor
2.1.1. Problemas de seguridad
Tanto la estrategia de identificación y como el esquema de almacenamiento de datos
presentan diversos problemas de seguridad, que pueden comprometer gravemente la pri-
vacidad de los usuarios.
En primer lugar, toda la información relativa al usuario va a ser almacenada, gestio-
nada y utilizada por cada web según sus intereses. Conocido es el caso de Facebook,
cuando en 2010 presuntamente compartió, sin consentimiento, los datos de 87 millones
de usuarios con la firma de consultorı́a polı́tica Cambridge Analytica8 .
7
https://developer.mozilla.org/es/docs/Web/HTTP/Headers
8
https://www.xataka.com/legislacion-y-derechos/facebook-cambridge-analytica
19En segundo lugar, cada sitio web es un sistema opaco del que se desconoce el nivel de
seguridad que aplica, estando expuesta dicha información a malos diseños o agujeros de
seguridad. Lamentablemente es muy común que sucedan filtraciones, llegando a existir
webs como haveibeenpwned donde al introducir un email, indica si ha sufrido alguna
de estas filtraciones de datos y que servicio ha sido.
En la Figura 6 se muestra un listado de las webs con el número de veces que han sufrido
una brecha de seguridad, ordenadas de manera descendente por el número de clientes
afectados.
Figura 6: Lista de webs con brechas de seguridad - Fuente9
Debido al gran número de webs que un usuario emplea, es bastante común que la contra-
seña se utilice también en otro sitio web, por lo que ante la filtración de un determinado
sitio, es posible que la información de muchos otros también se vea comprometida. De
hecho, algunos ciberdelincuentes se dedican precisamente a vender10 las credenciales de
acceso, recopiladas en ficheros de gran tamaño, también conocidos como combo-lists,
donde consta el usuario y la contraseña.
Por último, el sistema de contraseñas puede tener un problema de seguridad extra si el
usuario elige contraseñas fáciles de recordar o cortas. Un ciberdelincuente puede recurrir
a técnicas como la fuerza bruta o ataques de diccionarios, como por ejemplo ((rockyou))
incluido en Kali Linux, para averiguar la contraseña, siendo inviable este método en
contraseñas largas o complejas.
9
https://www.pcmag.com/news/these-companies-data-breaches-impact-their-users-the-most
10
https://gbhackers.com/account-take-over/
202.1.2. Evolución y soluciones
Para garantizar la protección de la información, el mundo de la computación recurre a
la criptografı́a, la cual busca enmascarar o alterar los mensajes para que sean ininteli-
gibles a receptores no autorizados. Existen diversas técnicas que son de vital importancia.
- Cifrado
Dentro de la criptografı́a se encuentran los procedimientos de cifrado, tanto simétri-
co como asimétrico, con el objetivo de enmascarar un mensaje y que solo las personas
que conocen la clave sean capaces de recuperarlo.
· Simétrico
Se trata del procedimiento que emplea la misma clave tanto para cifrar como descifrar.
Una ventaja de este procedimiento es que es más rápido y eficiente, mientras que pre-
senta la desventaja de almacenar y transmitir de forma segura la clave. El algoritmo por
excelencia dentro de esta categorı́a es AES o ((Advanced Encryption Standard)), desa-
rrollado en 1998 por John Daemen y Vincent Rijmen bajo el nombre de ((Rijndael))11
· Asimétrico
Por otro lado existe el procedimiento que emplea dos claves distintas para cifrar y des-
cifrar. Se considera que una clave es pública y puede ser difundida, mientras que la otra
es privada y debe de guardarse en secreto. Este procedimiento facilita la transmisión de
claves, además de que permite implementar la firma digital, mecanismo con el que se
puede garantizar el autor del mensaje y que este no ha sido modificado. Por contra, este
procedimiento es más lento que la clave simétrica. Uno de los algoritmos más conocidos
es RSA12 , nombre que hace referencia a sus desarrolladores Rivest, Shamir y Adleman.
· Hı́brido
Debido a que cada uno presenta sus ventajas y sus desventajas, en ocasiones se emplean
ambos mecanismos al mismo tiempo, como por ejemplo en el protocolo HTTPS13 , donde
se emplea clave asimétrica durante el ((saludo TLS)) o ((TLS handshake)) para establecer
una clave simétrica que cifrará toda la comunicación.
11
https://www.password-depot.de/es/know-how/blowfish-y-rijndael.htm
12
https://www.educative.io/edpresso/what-is-the-rsa-algorithm
13
https://www.cloudflare.com/es-es/learning/ssl/what-is-asymmetric-encryption/
21- Hashing
Conocido en castellano como ((funciones resumen)), estos algoritmos producen una salida
de tamaño determinado, denominada hash, que es exclusiva respecto a una entrada de
tamaño indeterminado, siendo irreversible el proceso. La ventaja de estos algoritmos es
que son muy rápidos, y permiten validar la integridad de la entrada. Por ejemplo, si se
calcula el hash de un determinado fichero, si algún ciberdelincuente modifica una sola
letra, la salida obtenida al volver a calcularlo seria completamente diferente. La familia
de algoritmos más usados en la actualidad es ((Secure Hash Algorithms)) o SHA.
Figura 7: Comparativa entre cifrado y funciones resumen - Fuente14
- Buenas prácticas
Para maximizar la seguridad de los usuarios, muchas webs emplean estos principios con
el objetivo de no almacenar información sensible directamente y que pueda ser extraı́da
por ciberdelincuentes. La gran mayorı́a de los problemas citados en el Apartado 2.1.1
se debe principalmente a que las webs almacenan la contraseña de los usuarios en texto
plano, es decir, tal cual.
Una de las opciones más utilizadas para solventar este problema es almacenar el hash
de la contraseña en vez de la contraseña en texto plano, de forma que si un ciberdelin-
cuente accede a esta información, no será capaz de conocer, a priori, la contraseña. Sin
embargo, si dos usuarios utilizan la misma contraseña, su hash será el mismo, lo que
abre la puerta a que los ciberdelincuentes puedan reciclar hashes que ya conozcan. Tam-
bién a estos hashes puede que se les aplique un ataque de fuerza bruta o tablas arcoı́ris 15 .
Para solventar estos nuevos inconvenientes de seguridad, se recurre a los conceptos de
sal, pimienta y funciones de derivación de clave.
14
https://aboutssl.org/hashing-vs-encryption/
15
https://medium.com/@ayushv.1298/bruteforce-rainbowtables-and-dictionary-attacks
22- Función de derivación de clave
En inglés KDF o ((Key Derivation Function)), son un tipo de función que se encarga de
generar una o más claves respecto una entrada. La principal ventaja de estos algoritmos
es que, además de la entrada, admiten parámetros adicionales, como por ejemplo la sal
o el número de iteraciones. Algunos van más allá, y con el objetivo de evitar ataques
de fuerza bruta, sobre todo de GPUs, permiten configurar el tiempo de ejecución, la
memoria requerida o el grado de paralelismo, como por ejemplo el algoritmo Argon216 .
· Sal
La sal es uno de los parámetros que estas funciones admiten, aunque también es frecuen-
te emplearlo con funciones resumen. Su objetivo es que las tablas arcoı́ris no se puedan
emplear, y para ello a la hora de almacenar la contraseña en la base de datos, en vez
de almacenarla el hash, se mezcle la contraseña y la sal, que es una serie de caracteres
aleatorios diferente para cada usuario, de forma que aunque varios usuarios indiquen la
misma contraseña, como la sal será diferente, el resultado del hash también lo será.
· Pimienta
El funcionamiento de la pimienta es algo similar a la sal. Mientras que la sal se almacena
en la base de datos junto con el hash resultante, quedando expuesta si un ciberdelin-
cuente entra en la misma, la pimienta normalmente se implementa en el propio proceso
de inicio de sesión y no se almacena en ningún sitio. El procedimiento habitual es conca-
tenar uno o pocos caracteres aleatorios extra a la contraseña enviada por el usuario, sin
guardar información de estos, aplicando posteriormente funciones resumen o de deriva-
ción de clave, y almacenando el hash resultante en la base de datos. En el momento de
inicio de sesión, el usuario enviará su contraseña, y el sistema probará todas las combi-
naciones posibles. Aunque el proceso se ralentiza debido al número de comprobaciones
que tiene que realizar, si un ciberdelincuente entra en la base de datos no sabrá si se
esta empleando o no pimienta.
Por ejemplo, si se diseña el sistema con un solo dı́gito extra, es decir del 0 al 9, el sistema
de verificación de contraseña tendrá que realizar una comprobación de contraseña por
cada una de las posibilidades, realizando un total de 10.
16
https://www.ory.sh/choose-recommended-argon2-parameters-password-hashing/
23- Conocimiento cero
También conocido como protocolo o prueba de conocimiento cero, se trata de una fi-
losofı́a y un protocolo criptográfico por el que una de las partes prueba a otra que una
declaración es cierta, sin necesidad de revelar información sensible. Una de las mayores
ventajas y aplicaciones que esta filosofı́a tiene, es que aplicada a los sistemas informáti-
cos, hace que los servidores desconozcan el contenido que almacenan. Mientras que un
cifrado de la información protege la información de personas que desconozcan la clave,
si es el servidor es quien cifra y almacena la clave, este hipotéticamente podrı́a revertir
el proceso y tener acceso.
La Figura 8 representa una comparativa muy sencilla de esta filosofı́a:
Figura 8: Ejemplo sistema con conocimiento cero
En un sistema clásico, el usuario envı́a el fichero al servidor sin cifrar (1*), y es el servidor
quien genera una clave y almacena cifrado el fichero (2*). En un sistema con conocimien-
to cero, la información que envı́a el usuario se cifra en relación a algo que lo vincule,
como por ejemplo su contraseña (3*). El servidor puede o no volver a cifrarlo (4*), pero
nunca podrá deshacer el cifrado del usuario y recuperar el fichero original, desconociendo
por tanto el contenido almacenado. Sin embargo, como el usuario ha cifrado el fichero
con su contraseña, el si es capaz de obtener el fichero original.
24- Múltiples factores de autenticación
En los últimos años ha surgido una corriente de seguridad que busca proteger las opera-
ciones sensibles, como por ejemplo acceder a tu cuenta bancaria online, mediante diversos
factores de autenticación. Esta corriente se basa en que para demostrar la autenticidad
del usuario se van a emplear varios procesos de autenticación distintos, basados en al-
guno de los siguientes principios:
- Algo que el usuario sabe: Ciertos conocimientos que solo el usuario conoce, como una
contraseña o PIN. [Por defecto]
- Algo que tiene el usuario: Cualquier objeto fı́sico en posesión del usuario, como una
tarjeta coordenadas o emplear aplicaciones TOTP... etc.
- Como es el usuario: Alguna caracterı́stica fı́sica del usuario biométrica, como una hue-
lla digital, reconocimiento facial o de voz... etc
- El lugar donde se encuentra el usuario: Analizar alguna conexión a una red informáti-
ca especı́fica o usar el GPS para identificar la ubicación.
Como norma general, todas las webs implementan el principio “algo que el usuario
sabe” mediante el usuario y la contraseña. Cuando una web emplea exclusivamente dos
factores, se le suele denominar como 2FA o ((2-Factor Authentication)), y uno de los
principios más usados para implementar el segundo factor es “algo que tiene el usua-
rio”. Para implementarlo es muy frecuente recurrir a aplicaciones móviles que emplean
el estándar RFC6238 - TOTP: Time-Based One-Time Password Algorithm, como por
ejemplo Google Authenticator.
Figura 9: Diagrama TOTP - Fuente17
17
https://www.twilio.com/docs/glossary/totp
25Como se puede observar en la Figura 9, la idea tras este mecanismo es que usuario y
servidor acuerdan una clave aleatoria en el momento de alta. En el momento de validar el
segundo factor de autenticación, ambos actores calculan el código temporal aplicando un
algoritmo a la clave acordada, el cual que tiene una vida útil aproximada de un minuto.
El usuario envı́a el código y se verifica con el código calculado por el servidor.
2.2. Identidad como servicio - IDaaS
Con el paso de los años, determinados servicios o empresas se han convertido en gigan-
tes tecnológicos debido al gran volumen de usuarios que los utilizan, como por ejemplo
Google, Microsoft, Facebook o Twitter. Desarrolladores de esta última compañı́a, propu-
sieron en 2007 un estándar de autorización denominado OAuth, que permitiese delegar,
de manera controlada, el acceso a datos de usuarios a terceros. Dicho de otra forma,
gracias a este estándar, los usuarios del sitio A pueden intercambiar los datos alojados
en ese sitio, con el sitio B sin necesidad de registrarse en este último.
2.2.1. OAuth 2.0
Un ejemplo clásico para entender la utilidad de este estándar es pensar en una web de
impresión de imágenes clásica. En esta web, tradicionalmente se subı́a manualmente las
imágenes, estando estas alojadas en el ordenador o en la cámara de fotos. Pero en la
actualidad esto es diferente, ya que la mayorı́a de imágenes están almacenadas en la
nube. Sin este mecanismo, para que la web de impresión de imágenes pudiera acceder a
las imágenes habrı́a que darle las credenciales de acceso a la nube, dándole control total
de la información y de la cuenta.
Mediante OAuth se puede solventar este problema, tal y como se observa en la Figura 10.
El usuario accede al sitio web de fotos (1º), y este va a solicitar a la nube la información.
La primera vez que se solicite se realizará sin código de autorización (2º), por lo que
el proceso de obtener las imágenes llevará al usuario a la pasarela de autorización (3º),
donde se le indica los permisos que esta solicitando la web de impresión de fotos (4º).
Si el usuario acepta (5º), el servidor de autorización generará el código de autorización
(6º). Ahora la web de impresión de fotos si podrá obtener las fotos alojadas en la nube,
empleando dicho código (7º).
Aunque OAuth esta orientado a la autorización, también se puede emplear como método
de autenticación, obteniendo la información relativa a la cuenta de usuario.
26Figura 10: Diagrama OAuth - Fuente18
2.2.2. Token
Para gestionar este acceso delegado se emplea un código o ((token)) de autorización. Por
regla general se emplea un token con un tiempo de validez corto denominado ((access
token)) o código de acceso. Al mismo tiempo, también se suele utilizar un segundo token
orientado a generar de nuevo un access token, el cual recibe el nombre de ((refresh token))
y tiene un tiempo de vida más largo.
Es habitual que el código de acceso almacene la información que el servicio va a uti-
lizar, y para ello se recurre al estándar JWT, el cual define una estructura de datos y
diversas formas de garantizar que no ha sido alterado.
18
https://docs.oracle.com/oauth guide/content/oauth intro
272.2.3. JSON Web Token - JWT
Los estándares RFC 7519 - JWT y RFC 7515 - JWS definen el token conocido como
JWT, aunque realmente se denomina JWS, ya que existen otro tipo y puede dar a
confusión. Tal y como se muestran en la Figura 11, se trata de un conjunto de 3 partes
definidas: header, payload y signature.
Figura 11: Diagrama JWT - Fuente19
- Header o cabecera
La cabecera se codifica en base64 y esta formada por un JSON de 2 campos: typ y alg.
El campo “typ” siempre contendrá el valor “jwt” mientras que el campo “alg” indicará
el algoritmo empleado para calcular la firma o signatura, de los definidos por el estándar
RFC 7518 - JWA.
- Payload o carga útil
Esta parte también se trata de un JSON que se codifica en base64. Este JSON puede
llegar a contener una lista de campos muy extensa, dependiendo del estándar en el que se
base20 . Además, se permite añadir cualquier campo propio no definido en dicha lista. Uno
de los campos más importantes es “exp” el cual indica la fecha limite de validez del token.
- Signature o firma
Para añadir una capa de seguridad y asegurar que el token no ha sido alterado, ya que en
las dos partes anteriores la información va codificada y no cifrada, el JWS implementa
un mecanismo de firma mediante el algoritmo indicado en la cabecera. En caso de alterar
el contenido, la firma no será válida y el servidor descartará la solicitud.
19
https://javadesde0.com/json-web-tokens-jwt/
20
https://www.iana.org/assignments/jwt/jwt.xhtml
28El uso de JWT se ha disparado en últimos años debido a que se ha producido un
cambio de filosofı́a en el desarrollo de páginas webs. Tradicionalmente el servidor web
se encargaba de generar la página HTML completa, y esta era enviada al cliente. En
la actualidad, con la irrupción de las APIs web21 y tecnologı́as como ((Single-Page
Application)) o SPA22 , Angular23 o NodeJS24 , se ha separado la generación de la página
web en dos partes: la plantilla HTML y la obtención de la información a mostrar.
Los objetivo de esta separación, empleada por diversas webs de éxito como por ejem-
plo Twitter, son diversos. En primer lugar la web descarga la plantilla sin datos y la
pinta por pantalla, produciendo la sensación de rapidez al usuario. Tras esto obtiene la
información y la coloca en su sitio. El resto de solicitudes solamente van a refrescar la
información, realizando peticiones concretas y de poca información, por lo que se libera
carga del servidor y reducen considerablemente el ancho de banda.
Para que estas webs funcionen correctamente, la identificación de los usuarios se rea-
liza mediante la utilización de JWT, normalmente JWS. Dentro del payload se van a
incluir todos los campos necesarios para el funcionamiento de la web, tanto para la parte
visual como para la autenticación con el servidor, como por ejemplo el id de usuario o
la dirección de correo electrónico.
Uno de los inconvenientes de utilizar este sistema, es que la información que se encuen-
tra dentro del JWT no va cifrada, si no codificada en base64, un proceso fácilmente
reversible, y firmada para asegurar su integridad. Es por esto que, aunque como normal
general siempre deberı́a usarse el protocolo de comunicación HTTPS, en los sistemas
que empleen autenticación o autorización mediante JWT es vital. De caso contrario,
un ciberdelincuente que este escuchando el tráfico, podrı́a obtener el JWT y aparte de
suplantar la identidad del usuario, obtener información acerca del mismo, quedando en
grave riesgo su privacidad.
Existe otra opción para maximizar la seguridad de la información intercambiada me-
diante JWT, y es la utilización de cifrado, definido por el estándar RFC 7516 - JWE y
denominando a estos tokens como JWE.
21
https://developer.mozilla.org/es/docs/Learn/JavaScript/Client-side web APIs/Introduction
22
https://www.digital55.com/desarrollo-tecnologia/que-son-single-page-application-spa
23
https://angular.io/
24
https://nodejs.org/es/
292.2.4. Autoridad Certificadora
Retomando el ejemplo de la web de impresión de fotos y la utilización del código de
acceso expedido por la nube para gestionar la autorización, tanto la web de impre-
sión de fotos como el usuario confı́an en la información que aporta la nube, recordando
ligeramente al ejemplo del DNI del proceso de identificación fı́sica comentado en el
Apartado 2 - Proceso de identificación. En este ejemplo, tanto el policı́a como el usua-
rio confı́an en la autoridad que ha certificado dicho documento oficial, en este caso el
Ministerio del Interior.
Otro caso muy similar son los certificados digitales, los cuales también son avalados
por una Autoridad certificadora, la cual actúa como entidad de confianza entre las
partes, y es responsable de emitir y revocar los documentos, y es en la que deben confiar
los usuarios. Estos certificados se utilizan junto con criptografı́a de clave pública-privada
vista en el Apartado 2.1.2 - Cifrado asimétrico. La autoridad certificadora nace debido
a la necesidad de verificar si una clave pública pertenece realmente a un usuario, y el
mecanismo más común para garantizar esto se basa en firmar el certificado digital, de
forma que si el usuario confı́a en dicha autoridad y conoce la clave pública de esta, podrá
verificar si el certificado es correcto y confiar en el otro interviniente.
El esquema en el que los intervinientes confı́an en una tercera entidad y es esta la que
se encarga de almacenar la información y transmitirla, implementando algún método
para que los intervinientes pueden verificar que es correcta esa información, normalmen-
te recibe el nombre IDaaS o ((IDentity as a Service)). El estándar más común para
implementar este esquema es OAuth 2.0, su versión más moderna hasta la fecha, sien-
do usado por el ejemplo de la Figura 10. Además de OAuth, existen otros estándares
para implementarlo, como por ejemplo SAML25 basado en el intercambio de mensajes
XML26 u OpenID27 el cual esta orientado a la autenticación.
2.3. El futuro de la identidad
En los últimos años se han desarrollado proyectos e ideas orientadas a mejorar los sis-
temas de identificación digital con mucho potencial a largo plazo, y que poco a poco su
impacto y uso de mercado va creciendo.
25
https://www.nts-solutions.com/blog/saml-que-es.html
26
https://rockcontent.com/es/blog/que-es-xml/
27
https://openid.net/connect/
302.3.1. Blockchain IDaaS
Una clara mejora que se puede realizar al sistema de autoridades certificadoras o siste-
mas IDaaS es emplear una red Blockchain para almacenar y controlar la información,
de forma que todas las autoridades certificadores registren los certificados en un libro
descentralizado, aveces llamado por sus siglas en inglés DLT28 o ((Distributed Ledger
Technology)), permitiendo el acceso a todos los actores intervinientes. Mediante la tec-
nologı́a blockchain se logra que la información sea pública y que no este controlada por
ninguna entidad, sino que se controla mediante su mecanismo de consenso29 .
2.3.2. Identidad digital y Auto-Soberana
Queda patente que el sistema de identidad que se emplea actualmente en Internet tiene
limitaciones, y su funcionamiento es diferente a como se realiza en el mundo real.
Debido a esto, en los últimos años se han promovido conceptos como Identidad di-
gital o Identidad auto-soberana. El primer concepto se encuentra dentro de la lla-
mada teorı́a de web 2.0, y su objetivo es permitir a los usuarios colaborar entre si. La
identidad auto-soberana busca recuperar el control de la información por parte de los
usuarios y no de los sitios. En definitiva, estos dos principios buscan que los procesos de
identificación en Internet sean muy similares a un proceso de identificación en el mundo
real, olvidando las problemáticas credenciales de usuario basadas en nick-contraseñas, y
empleando una nueva forma basada en identificadores y certificados digitales.
2.3.3. Identificadores descentralizados
Una propuesta para estos nuevos identificadores es el llamado DID o ((Descentralized
Identifiers)). Son propuestos como estándar por la W3C, cuyo fundador es el mismo que
desarrollo la web, y ponen a disposición de todos los usuarios el documento que detalla
que caracterı́sticas debe cumplir30 .
DID es la combinación de dos partes: identificador y documento descriptivo. El identi-
ficador es una cadena de texto de tres partes separadas por “:”. En primer lugar esta el
nombre de esquema, seguido de la especificación y por ultimo el identificador único.
28
https://www.bbva.com/es/diferencia-dlt-blockchain/
29
https://es.cointelegraph.com/news/cuantos-algoritmos-de-consenso-existen-para-las-blockchain
30
https://www.w3.org/TR/did-core/
31El documento descriptivo esta enlazado a esta identificador, y almacena las claves públi-
cas necesarias para el correcto funcionamiento del sistema, entre otras cosas. El estándar
realizado por el W3C permite a los desarrolles implementar distintas versión y estruc-
turas, destacando Hyperledger Indy como tecnologı́a y Sovrin como red. En la figura
Figura 12 se muestra un ejemplo de un identificador DID.
Figura 12: Esquema DID
Para gestionar estos identificadores existe el concepto de Trust Anchor, definido por
el estándar RFC 6024, y se trata de la representación de una autoridad certificadora.
2.3.4. Credenciales verificables
Del inglés ((Verifiable Credentials)) o abreviado VC, se trata de otro estándar propuesto
por el W3C con el objetivo de impulsar las credenciales digitales, formando un sistema
que proporciona un mecanismo para expresar credenciales en Internet de manera segura
y verificable, que además busca garantizar la privacidad de los usuarios. Tal y como se
puede observar en la Figura 13, en este sistema se determinan 4 roles: issuer o emisor,
holder o poseedor y verifier o verificador. Para el correcto funcionamiento del sistema,
tanto el emisor como el verificador deben compartir un registro común para la correcta
verificación de las credenciales.
Figura 13: Esquema Credenciales verificables - Fuente
323. Blockchain
El 1 de noviembre de 2008, bajo el seudónimo de Satoshi Nakamoto, se publicó un enlace
a un documento técnico en una conocida página web dedicada a criptografı́a acerca de
un sistema P2P de dinero digital. Bautizado como Bitcoin, en dicho documento se
describı́a una nueva estructura de datos: cadena de bloques o Blockchain, ası́ como
todas las caracterı́sticas y pasos que debı́a seguir dicha red distribuida. Aproximadamente
2 meses más tarde, el 3 de Enero de 2009, entró en funcionamiento la primera red P2P
basada en el protocolo Bitcoin.
3.1. Funcionamiento
3.1.1. ¿Qué es una cadena de bloques?
Ya que Bitcoin fue la primera red Blockchain, se procede a describirla. Las transaccio-
nes dentro de esta red se agrupan mediante bloques. Cada bloque contiene un número
variable de transacciones, añadiendo además una serie de campos extra para el funcio-
namiento y la validación de la red, como se puede observar en la Figura 14.
Figura 14: Estructura de un bloque
Bloque
Número mágico: Caracteres alfanuméricos que identifican un formato
Tamaño del bloque: Tamaño en bytes del bloque
Contador de transacciones: Número de transacciones incluidas en el bloque
Lista de transacciones: Lista de transacciones incluidas en el bloque
33Cabecera del bloque
Versión: Versión del bloque
Hash bloque anterior: hash que hace de referencia al bloque anterior para poder
generar una lista ordenada
Hash árbol Merkle: hash que hace de referencia a la raiz de la estructura de
tipo árbol Merkle que se produce enlazando todas las transacciones del bloque
Marca temporal: Momento exacto en el que se crea el bloque
Dificultad: Requisito de la prueba de esfuerzo para que el bloque sea aprobado
Número aleatorio: Número aleatorio que es empleado en la prueba de esfuerzo
Estos bloques se organizan en una lista cronológica, añadiendo siempre el último bloque
generado al final. Para realizar esta organización, cada bloque contiene una referencia
única o hash que apunta al bloque anterior. De esta forma, conociendo el último bloque
se puede recorrer toda la lista hasta el primero de todos. Al primer bloque de una red
Blockchain se le denomina bloque génesis 31 .
Figura 15: La cadena de bloques
El bloque génesis se utiliza para inicializar la configuración de la red, indicando todas
las caracterı́sticas que el resto de bloques van a heredar. Además de esto, se emplea para
emparejar a todos los nodos de la red siempre y cuando ese bloque sea exactamente
igual, maximizando la seguridad de la red al evitar intrusos potencialmente peligrosos.
Cabe destacar que el bloque génesis no puede hacer referencia a ningún bloque anterior
ya que este es el origen de la red.
31
https://academy.bit2me.com/que-es-bloque-genesis/
343.1.2. Criptografı́a
Uno de los principios más importantes en los que se basan las redes Blockchain es la
criptografı́a. De forma resumida, Bitcoin emplea frecuentemente las funciones resumen
explicadas en el Apartado 2.1.2 - Criptografia. Concretamente Bitcoin emplea el algorit-
mo SHA-256 para obtener hashes, siendo un hash producido por dicho algoritmo una
cadena de texto de 256 bits en formato hexadecimal como resultado de una determinada
entrada.
Gracias a este algoritmo se tiene un identificador exclusivo para cada bloque, utilizando
como entrada la cabecera del bloque (la parte coloreada de azul de la Figura 14). Tam-
bién se aplica para generar el Árbol Merkle, la cual es una estructura de datos de tipo
árbol para la representación jerárquica de la información, partiendo todo de un nodo
principal denominado raı́z. La raı́z puede estar conectada a ramas o a hojas. Las hojas
son los últimos elementos del árbol y son los que no tienen nodos inferiores o nodos hijo,
mientras que los nodos que se encuentran entre la raı́z y las hojas se denominan ramas.
Figura 16: Esquema árbol Merkle
La aplicación de esta estructura de datos en la red Bitcoin se realiza de la siguiente
manera. En las hojas de dicho árbol, se va a almacenar el hash de cada una de las tran-
sacciones independientemente del resto. Tras esto, se van a ir formando las ramas del
árbol, almacenando el hash de los dos nodos hijos que tiene. Este proceso se repite hasta
alcanzar la raı́z del árbol.
Esta estructura aporta una serie de caracterı́sticas imprescindibles para el correcto y
descentralizado funcionamiento del sistema.
35Eficiencia: Permite que sea mucho más sencillo comprobar las transacciones, ya
que permite que al comparar el hash de la raı́z, se comprueba el resto de tran-
sacciones, sin que tener que comprobar una a una por una todas las transacciones
incluidas en el bloque.
Integridad: Cualquier intento de cambio, aun por muy pequeño que sea, en cual-
quier transacción modificarı́a los valores hash de todo el árbol merkle, produciendo
un resultado diferente en el hash de la raı́z
Ahorro: Evita tener que enviar una gran cantidad de datos, ya que solamente se
envı́a los hashes asociados a ellos
3.1.3. Red descentralizada
Una vez ya visto las caracterı́sticas de la cadena de bloques, hay que entender como la
red Blockchain la gestiona. En primer lugar, y tal y como aparece en la introducción, una
red Blockchain es una red P2P o ((Peer-to-Peer)), o red distribuida en castellano. Una
red distribuida es un tipo de estructura en la que no existen ni clientes ni servidores fijos.
Existe pues, ordenadores, que son también llamado nodos, que pueden actuar al mismo
tiempo de cliente y servidor. De esta forma, se rompe el esquema de centralización de
los servidores clásicos, obteniendo las siguiente serie de caracterı́sticas:
La información se almacena de forma más segura al estar distribuida ya que no
esta exclusivamente en un único lugar
Mayor escalabilidad ya que la carga de trabajo se puede dividir por toda la red y
no solo a una unidad central
Figura 17: Esquema red P2P
36Estos nodos se conectan en pares, intercambiando la información necesaria, teniendo
una instancia de la información cada nodo de la red. Esto significa que en cada nodo
de la red va a existir una copia del estado actualizado de la blockchain. Un ejemplo de
sistema P2P muy conocido es BitTorrent. Este protocolo fue creado en 2001, con el ob-
jetivo de que los usuarios pudiesen intercambiar archivos de una manera descentralizada.
Aunque ambos sean sistemas P2P, en la tecnologı́a blockchain los nodos van un pa-
so más allá en cuanto a las tareas que realizan. Existen 4 tipos de nodos dentro de una
red Blockchain y cada tipo tiene asociado unas tareas que puede realizar.
Nodo completo: Son capaces de validar todas las transacciones desde la más
reciente del último bloque hasta la primera del bloque génesis.
Super-nodo: Son los nodos que ayudan a otros nodos a conectarse entre ellos,
dispersando en ellos y verificando el estado actualizado de la blockchain
Nodo ligero: Son nodos capaces de validar un número concreto y limitado de
transacciones. Esta orientado a dispositivos de bajo rendimiento y para el IoT32
Nodo minero: Son los nodos encargados de crear nuevos bloques. Su papel es
fundamental en el crecimiento de la blockchain
La validación de transacciones y la creación de bloques presenta varias fases.
Paso 1: Transacción
Para poder generar un nuevo bloque, los usuario deben realizar transacciones. Estas
transacciones se realizan empleando el monedero personal del usuario, indicando la can-
tidad de Bitcoins a enviar y la dirección destino. Para verificar que el usuario es quien
ha realizado la transacción, se concatena una firma digital empleando la clave privada.
Esta transacción es comunicada por la red blockchain.
Paso 2: Compilación
Los nodos mineros se encargan de agrupar estas transacciones, formando ası́ cada nodo
su propio bloque de máximo 1 MB. Es posible que una transacción este presente en
varios de estos bloques temporales.
32
https://www2.deloitte.com/es/es/pages/technology/articles/IoT-internet-of-things
37Paso 3: Formación
Cada transacción puede tener asociado un incentivo para los nodos mineros. Con esto
se pueden priorizar transacciones importantes, ya que todos los nodos mineros estarán
interesados en esa comisión. En esta fase, los nodos mineros además, filtraran los bloques
con las transacciones que ya hayan sido validadas, excluyéndolas del bloque. El bloque
pasará a ser candidato de ser validado.
Paso 4: Prueba de trabajo
Una vez un nodo minero tiene un bloque candidato asociado, deberá realizar una prueba
de trabajo al mismo. Este proceso se realiza debido a que debe existir un sistema de
consenso que se encarga de determinar los bloques que son válidos, teniendo esta prueba
un coste computacional muy alto. Consiste en obtener un hash del bloque que cumpla
los requisitos de dificultad que indica el bloque en la cabecera.
Figura 18: Prueba de trabajo Bitcoin
Para obtener ese hash, se utiliza un contador aleatorio que se va incrementando y que se
combina con la información del bloque, aplicando a todo esto el algoritmo SHA-256. De
esta forma, cada vez que se incrementa el contador, el hash resultante de la operación es
diferente. El resultado de esta operación se vuelve a pasar por la función resumen. Tras
este ‘doble hash’ se obtiene una cadena hexadecimal a la que se le denomina firma. Para
que la firma, y por ende el bloque, sean válidos, tiene que cumplir con las restricciones
que impone el concepto de dificultad. La dificultad es una representación directa e in-
versa de otro concepto llamado objetivo. Para que un bloque sea válido, el valor de la
firma debe de ser inferior al valor del objetivo. Cuanto mayor sea la dificultad, menor
será el valor asociado al objetivo y por lo tanto más complicado de calcular.
38El valor de la dificultad de los bloques se gestiona por la red Blockchain cada 2016
bloques, comprobando las marcas temporales de todos los bloques. Si los bloques tienen
menos de dos semanas de vida, la dificultad aumentará. En caso contrario, si tienen
más de dos semanas de vida, la dificultad se reducirá. Estos cambios son globales en
la red Blockchain, y se emplea para mantener un ritmo constante en la validación de
bloques, evitando ası́ periodos demasiado largos o demasiado cortos de validación de
transacciones. De media, un bloque se valida cada 10 minutos33 , aunque es posible que
se produzcan 2 bloques en un minuto o 1 cada hora.
Paso 5: Transmisión
Tras encontrar una firma válida, el nodo minero comunica el bloque con toda la red.
En este también en este momento en el que se ponen en circulación nuevas monedas,
siendo asignadas, como recompensa, al monedero del nodo minero que ha superado la
prueba de esfuerzo, junto con la comisión asociada a todas las transacciones.
Paso 6: Verificación
Obtener el número aleatorio que valida un bloque es un proceso muy costoso, tanto
computacional como enérgicamente hablando. Sin embargo, verificar ese bloque es un
proceso sencillo. Una vez el nodo minero lo comunica al resto de la red, es el resto de
nodos los que se encargan de realizar la verificación, comprobando no solo que el que
hash coincide con los requisitos de dificultad y se produce con dicho número aleatorio,
sino que todo el contenido del bloque es correcto.
Paso 7: Confirmación
El último paso es continuar la evolución de la cadena de bloques. Una vez el bloque
ha sido validado, es añadido a continuación del último bloque. A partir de este mo-
mento, todos los nodos mineros comenzarán a repetir el proceso y añadirán el siguiente
bloque justo detrás de este. Las transacciones que no han sido incluidas a la blockchain
con este bloque, quedan a la espera de que sean incluidas en un próximo bloque.
En la Figura 19 se detalla gráficamente los pasos del proceso de generación de un bloque.
33
https://www.investopedia.com/terms/b/block-time-cryptocurrency.asp
39Figura 19: Pasos creación de bloques
3.1.4. Wallets o monederos
Es importante precisar como se generan estas transacciones. En primer lugar, una tran-
sacción es un intercambio de información entre dos usuarios, identificados mediante
direcciones. Una dirección es un identificador único que se obtiene mediante el uso de
criptografı́a asimétrica. Mediante este método criptográfico, se obtiene un par de claves
seguras, que el usuario utiliza para comunicarse con la red blockchain, que reciben el
nombre de clave pública y de clave privada.
La clave pública puede ser compartida sin ningún tipo de riesgo, y la dirección que
utiliza la red blockchain para hacer referencia a los usuarios es un hash de dicha clave.
Por contra, la clave privada debe ser tratada muy cautelosamente, y se emplea para
verificar la propiedad de la clave pública. Estas claves se utilizan mediante el concepto
wallet o monedero. Un monedero es un software o hardware que se utiliza para crear y
consultar transacciones dentro de una red Blockchain. Existen diversos tipos de monede-
ros, como por ejemplo versiones web, de escritorio, para dispositivos móviles, entre otros.
Para realizar cualquier transacción es imprescindible disponer de un monedero y no
existe ninguna restricción para su creación, por lo cual cualquier usuario puede crear
cuantos monederos quiera. En una red blockchain no existe ningún tipo registro de los
monederos creados, solo se almacenan los intercambios de divisas entre ellos, por lo que
no hay constancia de la existencia de un monedero en la red hasta que haya recibido una
transacción, siendo posible enviar transacciones a direcciones que no existen.
40También puede leer
