Identidades Parciales

Trabajo de Fin de Grado Identidades Parciales Partial Identities Alumno: Pablo Martín Huertas Tutor: Juan Carlos Fabero Jiménez Doble Grado en Ingeniería Informática y Matemáticas 26 de junio de 2020 Prólogo “La pieza fundamental de cualquier sociedad es el individuo.” El concepto de sociedad es intrínseco a la naturaleza del ser humano. Debido a que todos formamos parte de algún grupo social, es esencial dar respuesta a las preguntas de quiénes somos y qué nos diferencia de los demás. Estas cuestiones dieron lugar a la génesis del concepto de Identidad. Las personas somos el conjunto de características que nos identifican: nuestra edad, sexo, estatura, comportamiento, lugar de residencia, progenitores, afiliación a grupos sociales... Todos estos rasgos representan la esencia de nuestro ser y son los que dictan cuál es nuestro lugar en la sociedad a la que pertenecemos. La posesión de todo aquello que forma nuestra propia identidad es vital, desde el uso de un pasaporte o documento nacional de identidad a la hora de viajar hasta el uso de un carné de conducir para poder circular en un vehículo, las personas estamos constantemente empleando los credenciales que tenemos. Hoy en día más que nunca tenemos la necesidad de administrar nuestros credenciales para realizar todo tipo de trámites dentro de la sociedad en la que vivimos. He aquí el objetivo de este trabajo, permitir de manera selectiva y fiable la identificación de credenciales a través de internet. El resultado buscado es hacer al individuo el único soberano de su propia identidad y permitirle la tarea de identificación. Existen una infinidad de aplicaciones a raíz de la identificación de credenciales en línea, como ejemplo, basta imaginar la posibilidad de realizar todo tipo de trámites gestionados por la administración pública de un país desde la comodidad de una casa. Para lograr este objetivo, en este trabajo proponemos la remodelación del concepto de red de confianza. Dichas redes de confianza son un sistema ideado por Phil Zimmermann en 1992. Su finalidad era resolver el problema de la asociación clave-usuario que planteaba la criptografía de la época. La idea que vamos a plantear es la actualización de estas redes mediante el uso de la novedosa tecnología blockchain para así poder resolver gran parte de los problemas que surgían en el sistema tradicional. Palabras clave Identidad, verificación de credenciales, criptografía, infraestructura de clave pública, red de confianza, autoridad de certificación, blockchain, certificado X.509, DID, transacción digital. Abstract “The cornerstone of any society is the individual.” The concept of society is intrinsic to the nature of the human being. Because we are all part of some social group, it is essential to answer the questions of who we are and what sets us apart from others. These questions gave rise to the genesis of the concept of Identity.People are the set of characteristics that identify them: their age, sex, height, behavior, place of residence, parents, affiliation to social groups ... All these traits represent the essence of our being and are what dictate what is our place in the society to which we belong. The possession of everything that forms our own identity is vital, from the use of a passport or national identity document when traveling to the use of a driving license to circulate in a vehicle, people are constantly using the credentials that they own. Today more than ever we have the need to manage our credentials to carry out all kinds of procedures within the society in which we live. Here is the objective of this work, to selectively allow the identification of credentials through the internet. The desired result is to make the individual the sole sovereign of their own identity and allow them the task of identification. There are an infinity of applications that make use of the identification of credentials online, as an example, just imagine the possibility of carrying out all kinds of procedures managed by the public administration of a country from the comfort of a home. To achieve this goal, in this work we propose the remodeling of the concept of Web Of Trust. Such Webs Of Trust are systems devised by Phil Zimmermann in 1992. Their purpose was to solve the key-user association problem posed by the cryptography of the time. The idea that we are going to propose is updating these webs by using the new technology blockchain in order to be able to solve many of the problems that arose in the traditional system. Keywords Identity, credential verification, cryptography, public key infrastructure, web of trust, certificate authority, blockchain, X.509 certificate, DID, digital transaction. Contenidos 1. Introducción 9 1.1. Motivacióndeltrabajo...................................... 9 1.2. Estadodelarte.......................................... 12 1.2.1. WebofTrust-PGP2.0................................. 12 1.2.2. RebootingWebofTrust................................. 13 1.3. Análisisdelacompetencia.................................... 15 1.3.1. Competenciadirecta................................... 15 1.3.1.1. IBM Blockchain Trusted Identity Networks . . . . . . . . . . . . . . . . . 15 1.3.1.2. Evernym .................................... 17 1.3.1.3. VeresOne.................................... 18 1.3.2. Competenciaparcial................................... 18 1.3.2.1. IXO-Microsoft ................................ 18 1.3.2.2. DIF - Decentralized Identity Foundation . . . . . . . . . . . . . . . . . . 19 1.3.2.3. ConsenSys ................................... 20 1.3.3. Conclusiones ....................................... 22 2. Desarrollo 23 2.1. Plandetrabajo.......................................... 23 2.2. Casosdeuso ........................................... 24 2.3. Herramientasauxiliares ..................................... 27 2.3.1. DID - Decentralized Identifier .............................. 27 2.3.2. HyperledgerFabric.................................... 29 2.4. Especificación........................................... 31 2.5. Objetivos del trabajo e implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.1. Herramientas auxiliares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.2. Generacióndelentorno ................................. 37 2.5.3. Implementación del chaincode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.5.4. Implementación de los scripts de transacciones . . . . . . . . . . . . . . . . . . . . 42 2.5.5. Pruebadeejecución ................................... 43 3. Conclusiones 49 3.1. Resumen del trabajo y conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8 Contenidos 3.2. Ampliaciónfutura ........................................ 53 3.3. Opiniónpersonal......................................... 55 4. Apéndices 57 4.1. Infraestructura de Clave Pública - PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Bibliografía 59 Índice alfabético 61 Capítulo 1 Introducción 1.1. Motivación del trabajo Actualmente, la seguridad en el paso de información por medios electrónicos es esencial para nuestra sociedad. Desde las transacciones de un banco hasta la base de datos de un centro médico, la protección y autenticidad de la información supone una necesidad vital para su correcto funcionamiento. Originalmente, internet no fue diseñado para ser una herramienta de comunicación segura por lo que a lo largo de la historia se han tenido que ingeniar diversas técnicas que garanticen dicha seguridad en las comunicaciones. Podemos extraer las siguientes cuatro características fundamentales: Autenticación: poder verificar que el usuario que está enviando el mensaje realmente es quien dice ser. Confidencialidad: asegurar que la información enviada tan solo puede ser leída por el remitente y el destinatario. Integridad: imposibilitar la alteración de la información enviada por un usuario ajeno a la comunicación. No repudio: no permitir que el remitente pueda negar haber mandado la información. Este problema se termina por resolver mediante los algoritmos de clave pública y clave privada1 desarrollados entre los años 1970-1980. Dichos algoritmos son capaces de asegurarnos las características de confidencialidad, integridad y no repudio; sin embargo, esto plantea un serio reto. ¿Cómo podemos asegurar que una clave pública realmente pertenece a un individuo en concreto? Tengamos en cuenta que una vez que seamos capaces de asegurar dicha afirmación ya podremos comunicarnos con ese individuo con garantía de que se cumplen las cuatro características que buscábamos. El problema se resolvería de forma trivial si conociésemos al individuo en persona, pues bastaría intercambiar las claves públicas en mano y así no quedaría ninguna duda de que dicha clave le pertenece. Ahora el problema es claro: ¿qué ocurre si no podemos hacer dicho intercambio físicamente? ¿Cómo podríamos asegurar quién es el propietario de dicha clave? Para abordar este problema la comunidad científica y las grandes empresas tecnológicas de la época desarrollaron el sistema PKI2. Básicamente se traba de un estándar tanto hardware como software que 1Principalmente con la invención del algoritmo RSA (Rivest–Shamir–Adleman) cuyo poder de encriptación se basa en el concepto de One-way trapdoor function, es decir, una función tal que su imagen directa se calcula con complejidad polinomial pero la imagen inversa requiere de un algoritmo con complejidad no polinomial. 2Las siglas PKI corresponden a “Public Key Infraestructure”, concepto que se explica con más profundidad en la sección 4.1 16 1. Introducción Además, la descentralización aportada por la base en blockchain nos aporta dos características esenciales: un registro inmutable con todas interacciones que un individuo ha realizado con su clave pública y un intercambio seguro de claves que el tradicional sistema de PKI no nos permitía. Una característica esencial del uso de blockchain es que la cadena no almacena los credenciales de los individuos. La cadena del blockchain tiene como objetivo el intercambio de claves públicas, pero los credenciales se han de intercambiar con otro protocolo adicional. El funcionamiento del sistema de identidades parciales de IBM está basado en que cada individuo es el único propietario de todas las características que le identifican, para ello se definen los siguientes tres componentes. Decentralized Identifier (DID)8: se trata de un tipo de URL que pertenece íntegramente al individuo u organización. Su objetivo es relacionar dicho URL con una identidad para poder asegurar la confianza en la interacción. Credenciales verificables: son los credenciales que mediante algún estándar deben poder ser verificados. Administración descentralizada de llaves: cada individuo es poseedor de su clave pública y su clave privada, con ellas se realiza la verificación de las interacciones a través de DID. La interacción en el blockchain se puede resumir en: Figura 1.5: Ejemplo de los pasos que se llevarían a cabo para la verificación de credenciales en el sistema. 8Los DID serán fundamentales para este trabajo por lo que se hará posteriormente un estudio de los mismos en la sección 2.3.1 1.3. Análisis de la competencia 17 Para llevar a cabo este proyecto, IBM colabora con las siguientes cinco organizaciones. DIF: desarrolladora del un motor de resolución de DID. W3C: aporta la especificación que dichos DID deben seguir. Sovrin: miembro colaborador de la organización DIF. Hyperledger: proyecto open source que proporciona una base de blockchain Oasis: propone el estándar de comunicación de los sistemas de encriptación. 1.3.1.2. Evernym La compañía Evernym se promociona mediante el eslogan “The future is built on trust.”. Su principal actividad es proporcionar a clientes con soluciones que permitan la verificación de credenciales digitales. Una de sus características más interesantes es que, al igual que muchos de los otros proyectos que hemos estudiado, Evernym también se basa en código open Source y en estándares abiertos (los que indica W3C). Evernym da mucha importancia al concepto Self Sovereign Identity, se trata de algo que ya hemos explicado anteriormente: el individuo viene caracterizado por sus credenciales y el objetivo es que sea el individuo el único propietario de los mismos. De aquí la necesidad nuevamente del uso de DID en algún tipo de sistema descentralizado (sobre todo tipo blockchain), para asegurar que el individuo es poseedor de su identidad. El esquema de funcionamiento de los prototipos Evernym vienen especificados en tres etapas: Obtención y verificación de credenciales mediante la herramienta Verity. Inclusión de dichos credenciales en la wallet del usuario para que pueda usarlos mediante la herramienta Connect.Me. Permitir que esa wallet pueda ser empleada por multitud de aplicaciones de terceros mediante Mobile SDK que proporciona Evernym. Una diferencia con el prototipo de IBM es que en caso de Evernym se usa otro tipo de Open Source para la base del sistema descentralizado: Hyperledger INDY. Dicho proyecto está siendo desarrollado por la Linux Foundation. Además cabe indicar que Evernym colabora con otro de los miembros que participan en el proyecto de IBM, Sovrin Identity For All. 18 1. Introducción 1.3.1.3. Veres One Veres One se define a sí misma como “Una solución usando blockchain a medida para optimizar las identidades en la web”. De nuevo estamos ante un proyecto de competencia directa pues el objetivo de Veres One es una solución al problema de identidades parciales, en su caso las propiedades que hacen destacar a Veres One del resto de compañías son: Precios bajos: el blockchain de Veres One a diferencia de otros tipo Ethereum que son de propósito general, está centrado únicamente en el problema de identidades parciales, por lo que se ha optimizado la eficiencia en esa tarea. No especulativo: en otros blockchain existe el concepto de scarce network token que tiene el efecto de hacer variar de manera difícilmente controlable los precios del sistema, en Veres One este concepto no existe y se asegura que las comisiones sean bajas y estables. Distribuida: como otras redes descentralizadas, el hecho de que no exista una organización central que controle el sistema tiene una serie de ventajas que ya hemos indicado en varias ocasiones con anterioridad. Permite auditorías: esto es una consecuencia directa de que la información de la cadena es pública por todos los usuarios de la red. Privacidad: Veres One en consonancia con la ley de protección de datos europea GDPR, almacena únicamente en la cadena los datos estrictamente necesarios para llevar a cabo la actividad de la aplicación. Indicamos un aspecto que Veres One aclara en su página web: aunque en muchos de los apartados de este trabajo nos referimos a los credenciales de los “individuos” en realidad también puede tratarse de organizaciones o colectivos. El funcionamiento de la aplicación de Veres One viene sostenida por dos tipos de participantes: Aceleradores: pPueden ser gobiernos, organizaciones que proporcionan credenciales o registradores. Su objetivo es colaborar en agilizar los procesos de creación y validación de los credenciales de los individuos. Deben estar de acuerdo con el “Accelerator Agreement” desarrollado por la compañía. Nodos: son esencialmente los verificadores que mantienen la cadena consistente mediante las pruebas de trabajo. Como en otros sistemas blockchain existe un convenio de recompensa a los nodos por la generación de los hash correctos. Un aspecto que hace a Veres One especialmente interesante de entre las demás compañías de la competencia es la seriedad con la que tratan el tema de la privacidad. Un ejemplo claro de una medida que tomaron al respecto trata sobre el almacenamiento de los credenciales: el usuario tiene la elección de si decide guardar sus credenciales únicamente en su dispositivo, únicamente en la nube o en ambos. 1.3.2. Competencia parcial 1.3.2.1. IXO - Microsoft Se trata de un proyecto desarrollado por la fundación IXO. En este caso el objetivo principal no son las identidades parciales (verificación de credenciales en línea), sino que el propósito de IXO es el de 1.3. Análisis de la competencia 19 proporcionar un sistema descentralizado blockchain que recoja una gran cantidad de datos de calidad y que los analice mediante algoritmos de inteligencia artificial. La parte polifacética de este proyecto viene en el momento en el que hemos indicado “una gran cantidad de datos”, ya que dichos datos pueden ser de cualquier índole. La plataforma IXO nos proporciona una base a partir de la cual cualquier usuario es capaz de crear un proyecto que se adjunta al sistema para recaudar un tipo de datos específicos, por ejemplo puede haber proyectos de: recaudación de datos meteorológicos de una zona, datos sobre el censo de una población... La razón por la que esta plataforma puede resultar de interés para nuestro trabajo es que implementa una metodología que permite decidir qué miembros participan en un proyecto concreto desplegado en esta plataforma. De esta manera, se podría realizar un proyecto que se ajuste parcialmente a lo que estamos buscando: recaudar credenciales que personas que para participar en este subsistema en concreta tienen que recibir permiso para ingresar (por ejemplo una CA que les verifique) 1.3.2.2. DIF - Decentralized Identity Foundation La fundación DIF tiene como objetivo principal el desarrollo de los estándares que se han de implementar para la verificación de identidades de sistemas descentralizados. Esto viene en gran medida relacionado con la sección de DID (Decentralized Identifiers) que se estudia a continuación en el apartado de desarrollo de este trabajo. La idea es que históricamente para identificar credenciales es imperativo seguir algún convenio que por ejemplo un gobierno ha dictado, como el formato de un pasaporte. Ahora en el caso de una red descentralizada, necesitamos un formato común a partir del cual implementar nuestro “equivalente al pasaporte”. El trabajo de DIF se compone de: Especificaciones técnicas: se trata de un convenio que deben seguir los sistemas descentralizados que implementen autenticación de identidades. Implementaciones ejemplares: lLa fundación también desarrolla prototipos de cómo se han de implementar estas especificaciones para ayudar a la comunidad de programadores. Coordinación de la industria: DIF trabaja en ayudar a la coordinación de las organizaciones que cooperan en el desarrollo de proyectos sobre la autenticación de identidades en sistemas descentralizados. Por ejemplo, ayudan al proyecto que ya hemos estudiado de IBM Blockchain Trusted Identity Networks. En nuestro caso nos interesa destacar el prototipo de referencia: DIF Universal Resolver9. Se trata de un programa que, dado un URL del tipo DID, hace una búsqueda en una de las redes descentralizadas existentes. Por ejemplo, podríamos buscar a qué DID-Document apunta una dirección DID en la cadena del Bitcoin con la llamada “did:btcr:xz35-jznz-q6mr-7q6”, donde btcr es el protocolo específico de busqueda en el blockchain de Bitcoin. 9La herramienta it DIF Universal Resolver tiene una demo accesible online a partir del link: https://uniresolver.io/. En ella se pueden ejecutar casos de prueba de búsqueda de DID-documents en diferentes redes descentralizadas. 20 1. Introducción Para nuestro proyecto vamos a implementar una función parecida pues vamos a tener una cadena en nuestro blockchain que contenga los DID-Documents asociados a los DID de los individuos que forman parte de nuestra red. Por ello deberemos programar una función de búsqueda en nuestra cadena análoga a las implementadas por el DIF Universal Resolver. 1.3.2.3. ConsenSys La compañía ConsenSys tiene su negocio basado en consultoría de soluciones tecnológicas basadas en blockchain. Su trabajo se divide en los siguientes cuatro sectores: Enterprise: se trata de la solución de problemas relacionados con blockchain que un cliente presente, para ello ConsenSys se especializa en soluciones mediante la plataforma Ethereum10. Startups: la innovación es un aspecto esencial para una tecnología tan nueva como las redes descentralizadas, por ello ConsenSys invierte en numerosas startups que desarrollan soluciones blockchain. Development: además de llevar a cabo soluciones en Ethereum, la empresa desarrolla y publica herramientas para dicha plataforma. Education: finalmente, la compañía ofrece cursos tanto online como presenciales para enseñar a trabajar en Ethereum. En cuanto a la variedad de soluciones ofrecidas es muy amplia: finanzas, energía y sostenibilidad, sector público, comercio internacional... Para nuestro trabajo nos vamos a enfocar en la solución que trata las identidades parciales, Digital Identity[3]. Desde las propias publicaciones de la compañía nos indican los tres aspectos fundamentales que tratar en la sección de identidades parciales:11 Para compañías: “...Las compañías tienen que recopilar los datos de sus usuarios para poder hacer su trabajo. Esto crea un riesgo frente a las regulaciones de privacidad como pueden ser el GDPR...” Para Internet of Things: “...Los dispositivos de IoT deben identificar sensores, monitores y otros dispositivos para organizar el acceso a datos sensibles de una manera segura...” Para usuarios: “...La identidad es central para el funcionamiento de una sociedad. Cada persona está compuesta de una colección de credenciales que le identifican. El objetivo es proporcionar a los usuarios una forma de reclamar la propiedad de su propia identidad para llevar a cabo operaciones online...” Vemos que en las propias palabras de ConsenSys, los problemas que plantea la Digital Identity son realmente interesantes debido a las necesidades que los usuarios tienen en la actualidad. La parte más en línea con nuestro trabajo es la destinada a las usuarios: se trata de permitir la verificación de credenciales online. La ventaja de una solución con tecnologías descentralizadas reside en permitir a los usuarios ser los únicos propietarios de su propia identidad y de reducir la cantidad de información personal identificable (nombre, dirección, datos biométricos...) que un usuario tiene que mantener en la red. 10Ethereum es una plataforma de blockchain que se caracteriza por proporcionar una base a todo tipo de sistemas descentralizados, la clave reside en que en Ethereum lo que se transmite son contratos digitales (que ejecutan chaincode), los cuales los especifica el propio desarrollador, dando así libertad para realizar todo tipo de operaciones. 11Todas las citas se han obtenido desde la referencia [3] de la bibliografía. 1.3. Análisis de la competencia 21 Tal y como ya hemos vistos en otros casos, de nuevo ConsenSys propone el uso del estándar de DID para sus soluciones relacionadas con identidades parciales. Dichos DID recordamos que son como el “pasaporte” común para que los usuarios de una red descentralizada puedan procesar la información de los demás. Además, una vez que un usuario sepa que cierta clave pertenece a otro individuo, mediante criptografía de clave asimétrica ya tiene garantizado poder comunicarse con él de manera segura. 22 1. Introducción 1.3.3. Conclusiones Realmente en esta sección hemos estudiado una gran cantidad de información, podemos observar cómo todos los proyectos que hemos mostrado son muy recientes (desarrollados durante los últimos 8 años). Esto nos da un claro indicador de que estamos ante un problema de gran interés y por el que está surgiendo una fuerte competencia para apoderarse del mercado. Es importante ver esto como un claro refuerzo de la predicción de que una tecnología que resuelva el problema de las identidades parciales se va a implantar en nuestra sociedad en un futuro. Ahora bien, además de habernos asegurado que el tema tratado en este trabajo es relevante tanto para la comunidad científica como para la sociedad, nuestro segundo objetivo va a ser extraer las conclusiones clave que nos ayuden a desarrollar un prototipo propio. Para ello y debido a la gran cantidad de información que comprende esta sección vamos a presentar la siguiente tabla con los aspectos más importantes de cada una de las iniciativas. Proyecto Trata principalmente el problema de identidades parciales Hace uso del estándar DID El proyecto tiene menos de 8 años Característica distintiva Emplea tecnología Blockchain (especificar) IBM 3 3 3 La cadena no posee información personal identificable 3Hyperledger Fabric Evernym 3 3 3 Permite usar su wallet de credenciales en terceros mediante su Mobile SDK 3Hyperledger INDY Veres One 3 3 3 Introduce concepto de Aceleradores para agilizar creación/verificación de credenciales 3Hyperledger Fabric IXO 7*3 Base multiplataforma que permite desplegar proyectos de todo tipo sobre redes descentralizadas. 3 DIF 7 3 3 Herramienta auxiliar a proyectos de identidades parciales para resolver la conexión DID/DID-Document 3(Múltiples) ConsenSys 7*3 Consultora que proporciona variedad de soluciones basadas en blockchain 3 *: puede usar el estándar DID dependiendo del proyecto concreto que esté tratando. Podemos extraer las siguientes conclusiones para nuestro trabajo: Será esencial usar el estándar DID que ha especificado la organización W3C, pues todos los proyectos actuales de gran calibre lo tienen en cuenta. Hemos decidido usar el open source Hyperledger Fabric para tener una eficiente base de nuestro blockchain. El funcionamiento de Hyperledger Fabric se estudiará con más detenimiento en la siguiente sección 2 de desarrollo. Nos parece de gran interés la filosofía de IBM de no introducir información personal identificable en la cadena pública, por lo que en nuestro prototipo tan solo introduciremos documentos DID. Es decir, la red descentralizada es como un mecanismo auxiliar para resolver el problema de identificar a un individuo con su clave. Capítulo 2 Desarrollo 2.1. Plan de trabajo Tras el estudio del estado del arte sobre el tema que abarca este trabajo y habiendo reflexionado sobre las conclusiones que hemos obtenido a partir del análisis de la competencia, ya estamos preparados para el desarrollo de nuestro proyecto. Con el fin de facilitar y mejorar la eficiencia de dicho desarrollo, esta sección constará de los siguientes cuatro bloques fundamentales: propuestas de casos de uso, estudio de las herramientas auxiliares, especificación del sistema y detalles de la implementación. Más concretamente, cada apartado comprenderá la siguiente información: Casos de uso: se propondrán una serie de objetivos que un usuario de nuestra aplicación debe ser capaz de realizar. Una vez planteado un objetivo se especificará tanto la secuencia de acciones que el usuario deberá realizar como otras características como pueden ser los requisitos, las precondiciones, el tipo de actor... Herramientas auxiliares: a la hora de implementar nuestra prueba de concepto propuesta, vamos a hacer uso de herramientas de software libre que se encuentra en la red pues nuestra meta es avanzar en la materia de la autenticación de credenciales en redes descentralizadas a partir de la base que ya nos proporciona la comunidad científica. Especificación: una vez ya hemos expuesto qué tareas debe ser capaz de realizar el usuario y las herramientas que nuestro sistema va a requerir, podemos pasar a la especificación concreta que indicará el funcionamiento del prototipo que desarrollemos. Implementación: finalmente, tras la puesta en código de la especificación señalada en el apartado anterior se remarcarán las características principales del mismo para así dar a entender con mayor nitidez lo que hay por detrás del funcionamiento de la prueba de concepto. Además se realizarán pruebas de ejecuciones que confirmen el correcto funcionamiento. 24 2. Desarrollo 2.2. Casos de uso El objetivo de esta subsección es aclarar las funcionalidades que se esperará que el prototipo ofrezca. Para ello vamos a exponer una serie de casos de uso reales que aclaren dichas funcionalidades. Este apartado será de gran importancia pues tras él realizaremos un breve esquema-resumen con las acciones realizables que nos permitirá entender las decisiones de diseño de los siguientes apartados. La estructura de los casos de uso se compone de las siguientes partes: Número del caso de uso y título Nivel: este apartado es vital pues la filosofía de cada caso de uso viene dada por el nivel que trata, hay dos posibles: •Objetivo del usuario: estas acciones suponen aquellas que los usuarios finales deben poder realizar mediante las herramientas que proporcione el prototipo. •Subfunciones del sistema: estas acciones son “transparentes” al usuario, pues no las ejecuta directamente; sin embargo, serán esenciales para mantener tanto el buen funcionamiento del sistema como asegurar las prestaciones que nuestro prototipo debe ofrecer. Actores: tanto principales, los que desencadenan la acción, como se secundarios, los que participan en el transcurso de la misma. Objetivo de contexto: es la meta que el usuario o en su caso la subfunción se proponen a la hora de realizar la acción. Precondiciones: en el caso de un usuario es el la acción que comienza el caso, mientras que en una subfunción es el desencadenante del caso. Postcondiciones: son los posibles estados finales tras acabar el caso de uso. Flujo principal: hace un seguimiento del caso de uso paso a paso. Flujos secundarios: en caso de haber ramificaciones en los pasos a tomar, se aclararán en este apartado. Frecuencia de ocurrencia: indicará la frecuencia con la que dicho caso de uso aparecerá en la práctica real. En las siguientes páginas vamos a presentar la lista con los casos de uso que hemos propuesto como más relevantes para la aplicación. 2.2. Casos de uso 25 Caso de uso 1: Registro en un canal1del blockchain Identificador del caso: USO_REGISTRO_CANAL Nivel: Objetivo del usuario Actor principal: Usuario final Actores secundarios: Miembro del canal Objetivo en contexto: Un usuario nuevo a un canal hace una petición de registro para poder tener acceso a las operaciones sobre la cadena distribuida en dicho canal. Precondiciones: El usuario realiza una solicitud de registro a un miembro con permisos del canal. Postcondiciones: Éxito: el miembro receptor de la petición acepta la unión y proporciona al usuario un credencial que se le añadirá a su wallet con la identificación. Fallo: es rechazada o no contestada la petición y el usuario recibe un mensaje de fallo al acceder al canal. Flujo principal: 1. El usuario manda una petición de ingreso a un canal. 2. Un miembro de dicho canal recibe el mensaje y decide aceptarlo. 3. El usuario envía un mensaje al miembro con su clave pública. 4. El miembro manda un mensaje de actualización a los demás miembros y verificadores para que otorguen permisos a la clave pública del usuario novel. 5. El usuario almacena sus credenciales con la clave pública en su wallet. Flujos secundarios: 2.a El miembro pide información adicional antes de tomar la decisión: 1. El miembro manda un mensaje con una petición de datos al usuario. 2. El usuario envía los datos pedidos. 3. Se vuelve al paso 2 del flujo principal. 2.b El miembro rechaza la petición. 1. El miembro manda un mensaje de rechazo a la solicitud. Frecuencia de ocurrencia: Única durante el ingreso a un nuevo canal. 1En lo que concierne a esta sección podemos definir de manera intuitiva el concepto de canal como el medio a través del cual un usuario podrá mandar mensajes a los miembros del blockchain. Sin embargo, una definión más formal y precisa se puede encontrar en la sección 2.3.2 que sigue inmediatamente a ésta. 32 2. Desarrollo Cabecera ID del bloque: Se trata de un identificador único del bloque, una forma simple de asegurar dicha unicidad es atribuirle su posición en la cadena (concepto que se explica más adelante) como ID del bloque. Hash de datos: Una vez se haya configurado completamente un bloque, será necesario crear un hash criptográfico a partir de dicha información y añadirla en este campo. El hash de datos tiene como entrada todos los apartados del bloque excepto éste y el de metadatos. Hash anterior: Se trata de una copia idéntica del hash criptográfico que se asignó al bloque anterior de la cadena. Datos Documentos DID: En esta sección se introducirá uno o varios documentos DID que vienen especificados tal y como los estudiamos en el apartado de estudio de herramientas auxiliares. Metadatos Certificado y firma: El creador del bloque debe añadir su certificado y firma para que el resto de verificadores del sistema puedan validar el bloque, la relevancia de este apartado se mostrará más adelante. Indicador de válido/inválido: Se trata de una función auxiliar que permite detectar a los verificadores si el bloque está repetido. Con esta estructura podemos ahora visualizar mejor la cadena: Acabamos este apartado de estructura del blockchain presentando los dos últimos componentes: Base de datos del estado: como indicamos en la cadena, se trata de una lista enlazada en una dirección por lo que una búsqueda a los bloques más antiguos puede llegar a ser costosa con el tiempo. Para mejorar la eficiencia de los búsquedas de los documentos DID nuestro sistema implementa una base de datos de tipo CouchDB donde se guardan las conexiones (DID) ⇐⇒ 2.4. Especificación 33 (Documento DID) de las operaciones de búsqueda más recientes. De esta manera solo habrá que recorrer la cadena en caso de que no se encuentre el documento en la base de datos. Canales: para obtener una copia de la cadena y poder introducir documentos DID en la misma, debe de establecer una conexión con el canal. El canal es esencialmente la red donde están conectados todos los miembros que participan en el sistema, a través de él se realizan las operaciones de introducción de nuevos bloques y verificación/publicación de la cadena actualizada. Actores del sistema Nuestra red descentralizada va a ser mantenida por dos tipos de participantes cuyas funcionalidades son distintas: Usuarios: son todos aquellos individuos u organizaciones que introducen sus respectivos documentos DID a la cadena. Recordemos que el documento DID contiene tanto una clave pública como un método de contacto, luego esto nos permitirá solucionar el problema de identificar al poseedor de la clave. Este tipo de actor corresponde con el definido como “orderer node” de Hyperledger Fabric. Verificadores: son aquellos individuos que se encuentran a la escucha de la aparación de bloques de nueva creación, su objetivo es la de validar que la sintaxis del bloque es correcta y de buscar el hash criptográfico que se introduce en el apartado hash de datos. Una vez encontrado un hash correcto, los verificadores envían mensajes de actualización con la nueva cadena. Nótese que dicho hash no es un cálculo trivial, pues usualmente se exigen ciertas características al mismo que solo se pueden resolver por fuerza bruta. Por ejemplo que en el final del hash haya Nnúmero de ceros. Contenido del wallet El aspecto clave de nuestro prototipo hemos visto que es el hecho de que en la cadena pública tan solo se pueden introducir documentos DID. Esto lo complementamos con que solo permitimos añadir identificaciones en el wallet, es decir una clave pública. Para inscribirse como usuario al sistema es necesario mandar una petición de ingreso a miembros ya existentes del mismo, en caso de aceptar al nuevo usuario, a éste se le asigna en su wallet un documento de texto firmado por un verificador. A partir de este momento, el usuario puede realizar operaciones de introducción de documentos DID en la cadena usando su clave pública. En caso de que una cuenta intente realizar una transacción a la cadena sin poseer el correspondiente documento firmado por un verificador en su wallet, entonces la transacción será invalidada por los verificadores. Chaincode Recordamos que para la unión de un nuevo usuario a la red era necesario una petición de ingreso, ahora bien, una vez dentro todos los usuarios deben ser capaces de ponerse de acuerdo en el conjunto de transacciones válidas. Para ello, en nuestro sistema desarrollaremos un chaincode, es decir, el conjunto de instrucciones con las funcionalidades que se permiten realizar en la red. Dicho chaincode debe ser aprobado por todos los usuarios del sistema que quieran usarlo, esto implica que son los usuarios los que deben asegurarse de que el chaincode realmente hace lo esperado. Una vez que el usuario ha ingresado en una red con su clave pública en el wallet y ha aceptado el código del chaincode, éste tendrá permitido llevar a cabo todas las funciones que le proporciona. Para nuestra prueba de concepto vamos a implementar las siguientes: queryAllDID: [Sin parámetros de entrada] Función que recorre toda la cadena pública y devuelve todos los DID-Document que pertenecen a la misma. 34 2. Desarrollo queryDID: [Dirección DID como entrada] Dado un DID, es decir el análogo a dirección URL del DID (el ejemplo que vimos cuando estudiamos los DID era “did:example:123456789abcdefghijk”), busca en la cadena un DID-Document cuyo campo “id” coincida con el buscado. addDIDdoc [DID-Document como entrada] Para esta función el usuario proporciona un DID-Document y los verificadores actúan siguiendo el siguiente esquema: •Comprueba que el usuario que inicia la transacción lo hace usando una clave pública de su wallet. •Comprueba que la sintaxis del DID-Document es correcta de acuerdo con la especificación proporcionada por el W3C. •Para finalizar se realiza la prueba de trabajo, es decir, se genera el bloque correspondiente que va contender al documento y se hace el cálculo del hash de datos para poder insertarlo en cadena. •Una vez calculado el hash el verificador comienza a anunciar la nueva cadena para el resto de miembros de la red. Verificación de credenciales Recordemos que los DID-Document tienen dos secciones esenciales: “authentication”y“service”. En la primera se dispone de algún mecanismo de encriptación, en nuestro caso usaremos claves RSA. Mientras que en la segunda sección que expone alguna forma de contacto del usuario, puede ser una dirección IP, una dirección de correo electrónico, incluso una dirección física si se trata de una organización... Esto nos resuelve el problema de asociar la relación usuario-clave. Es decir si pensamos en una dirección DID como un apodo y recuperamos su documento asociado desde la cadena, podemos asegurarnos al contactar con el medio que aparece en “service” que la clave pública pertenece al usuario con dicho apodo (puesto que en el nos responde demostrando que tiene posesión de la clave privada asociada). Con todo esto ya podemos establecer una conexión con el usuario que posee dicha dirección DID y estar seguros de que es el individuo que esperábamos. Así pasamos a la última parte del trabajo y es la verificación de credenciales. Para este caso tendremos que acudir a la ayuda de una CA (Certificate Authority), sin embargo, tan solo será una vez por credencial. El proceso es el siguiente, el usuario pide a la CA que le certifique con su clave privada un credencial que antes ha tenido que presentar. Una vez obtiene el certificado, el usuario lo guarda para su uso posterior. Ahora cuando se realice la conexión segura siguiendo lo que hemos indicado anteriormente, el usuario podrá presentar su certificado y así acreditar el credencial en cuestión. Esta acreditación deberá llevarse a cabo mediante un protocolo auxiliar adicional y externo al prototipo propuesto, se trataría de añadir una forma estandariza de enviar los certificados firmados por la CA que posee el individuo. Para este trabajo no nos hemos centrado en desarrollar dicho protocolo pues recordamos que el problema principal a resolver es el de las relaciones usuario-clave pública, para ello nos hemos apoyado en la tecnología blockchain. Entorno de ejecución Todo el prototipo se va desarrollar en un sistema Linux, la versión 19.10 de Ubuntu. Vamos a partir de la base que nos proporciona Hyperledger Fabric, para ello usaremos el código Open Source que aparece en su GitHub oficial: https://github.com/hyperledger/ . Ahora bien, La amplia gama de herramientas que proporciona el proyecto de Hyperledger está fuera del alcance del prototipo que vamos a desarrollar en este trabajo, por lo que nosotros nos vamos a restringir a trabajar con el entorno de ejemplos. Es decir nuestro proyecto comienza a partir de clonar los ficheros de https://github.com/hyperledger/fabric-samples El proyecto Hyperledger posee una licencia Apache 2.0, por lo que tras documentar adecuadamente la fuente del mismo (más información en la sección de bibliografía), tenemos derecho a usar el código para nuestro prototipo. 2.4. Especificación 35 En cuanto a los ejemplos que nos proporciona la carpeta fabric-samples, al final nos hemos decantado por usar como base el llamado “FabCar”. Se trata de un prototipo de red descentralizada en la que se gestionan coches y sus propietarios. A pesar de que también consideramos en un principio basarnos en “first-network” que es una prueba de red de criptomonedas, las operaciones de FabCar nos parecieron más fácilmente generalizables. Para entender la siguiente sección con la implementación vamos a presentar el esquema que sigue el prototipo FabCar: Se creará un canal con la cadena al que todas las máquinas ingresarán •mychannel Hay dos organizaciones y cada una tiene dos verificadores y una CA •Org1 ◦peer0.org1.example.com * ◦peer1.org1.example.com ◦ca_peerOrg1 •Org2 ◦peer0.org2.example.com * ◦peer1.org2.example.com ◦ca_peerOrg2 Existen 6 usuarios que realizan transacciones a la cadena •orderer.example.com •orderer1.example.com •orderer2.example.com •orderer3.example.com •orderer4.example.com •orderer5.example.com Hay cuatro bases de datos •couchdb0 •couchdb1 •couchdb2 •couchdb3 * : Estos verificadores son además asignados como los MSP3de cada organización. Una duda natural que surge es cuál será el papel de las máquinas ca_peerOrg1 yca_peerOrg2. Éstas se encargan de funcionalidades auxiliares: Ayudar a los MSP (en este caso peer0.org1.example.com ypeer0.org2.example.com), en el proceso de ingreso de nuevos usuarios, generando los documentos firmados que se añadirán al wallet del nuevo miembro para que pueda realizar transacciones. Asegurar que solo los miembros registrados son capaces de realizar transacciones en la red, puesto que, cuando un usuario intente realizar una transacción las máquinas ca_peerOrg1 yca_peerOrg2 3Recordamos que un MSP era un Membership Service Provider, es decir los encargados de llevar a cabo el proceso que permite el ingreso de nuevos usuarios a la red. 36 2. Desarrollo comprobarán que dicho usuario tiene en su wallet una clave pública válida, es decir, obtenida durante el proceso usual de ingreso. Durante la prueba del prototipo, nosotros tomaremos el papel de orderer.example.com, desde donde ingresaremos a la red y realizaremos una serie de transacciones. Todo este esquema parece bastante complejo, así que presentamos la figura 2.3 con todas las máquinas: Figura 2.3: Esquema con todos los actores y elementos del prototipo que vamos a desarrollar. 2.5. Objetivos del trabajo e implementación 37 2.5. Objetivos del trabajo e implementación Nuestra tarea consistirá en: Alterar el chaincode localizado en “/fabric-samples/chaincode/fabcar/go/fabcar.go” de tal manera que la cadena pase a guardar DID-Documents en vez de coches y además redefinir todas las funciones que pueden usar las máquinas de la red para adaptarlas a nuestro objetivo. Crear en “/fabric-samples/fabcar/javascript/” los ficheros .js que los usuarios ejecutarán para realizar las operaciones sobre la cadena. (Estos .js harán llamadas a las funciones implementadas en el .go del chaincode) Todos estos cambios se realizarán a partir de un fork del github con el proyecto oficial de Hyperledger Fabric. Se puede acceder a dicho proyecto con el código nuevo a través del siguiente enlace https://github.com/pmartinhuertas/fabric-samples 2.5.1. Herramientas auxiliares El primer paso de esta sección es poner en marcha todo el sistema base que nos proporciona Hyperledger Fabric. Para ello comenzamos por clonar el repositorio hyperledger/fabric-samples, a continuación tenemos que instalar todas las herramientas auxiliares de las que hace uso el prototipo. El primer paso será instalar todos los archivos binarios, los propios desarrolladores de hyperledger proporcionan un instalador automático. El segundo paso será instalar la herramienta Docker, la cual nos permitirá gestionar todos los procesos que lancemos en el prototipo mediante el uso de contenedores. Recordemos que el ejemplo tiene 4 verificadores, 6 clientes, 4 bases de datos y cada uno se ejecuta en un entorno distinto. El tercer paso consistirá en instalar el lenguaje Go en una versión 1.13 o posterior. En esencia es un lenguaje similar a C, su utilidad es que el chaincode del ejemplo FabCar que vamos a modificar se encuentra escrito en Go por lo que nos vamos a adaptar a él. El cuarto paso será instalar Node.js, veremos que las transacciones que ejecutan los usuarios serán ficheros .js (terminación de javaScript), los cuales ejecutaremos con esta herramienta. El quinto y último paso será instalar la versión de Python 2.7. Actualmente la versión de Ubuntu más reciente contiene la versión 3.5.1, sin embargo, para Node.js SDK algunas operaciones solo funcionarán correctamente con la versión 2.7. Nota: Una guía más detallada del proceso de instalación de todas las herramientas necesarias se encuentra en las siguientes referencias de la bibliografía: [4] y [5]. 2.5.2. Generación del entorno El lanzamiento de nuestro prototipo se realizará navegando a la carpeta “fabric-samples/fabcar/” y ejecutando el script “startFabric.sh”, a continuación se montarán todos los actores y elementos de nuestra red. Repasemos ayudándonos de figuras que contienen la salida del terminal que ejecuta el script, todos los pasos que se realizan cronológicamente para montar el sistema: 38 2. Desarrollo El primer paso de todos es tan solo auxiliar, pues su objetivo será la eliminación de todos los ficheros y los procesos que se hubiesen generado durante una ejecución anterior del sistema. Esto nos asegura evitar errores causados por el solapamiento de ejecuciones. Figura 2.4: Eliminación de todos los procesos y ficheros de la ejecución anterior. Acto seguido, vamos a generar todos los ficheros de configuración. Generamos el bloque génesis, es decir, el primer bloque de la cadena. Recordemos que cada bloque debe contener el hash del anterior, sin embargo, para este primer bloque es necesario hacer una creación especial. Creamos el fichero de configuración “ channel.tx”. En él se especificarán las config policies, es decir las políticas de configuración que indicarán cuál será el proceso de creación/unión/interacción/salida del propio canal. Esto quiere decir que aquí se indicará quién en un principio tendrá los permisos de MSP. El último paso es añadir a este fichero fichero “channel.tx” los anchor peer, es decir vamos a indicarle a la configuración que tanto la organización 1 como la organización 2 tendrán permisos de MSP para poder decidir quién entra en el canal. Figura 2.5: Creación de bloque génesis y generación de la configuración del canal “mychannel”. 2.5. Objetivos del trabajo e implementación 39 Lo siguiente es crear todos los procesos que comprenden a los usuarios, verificadores, bases de datos. Además podemos ver como dichos procesos se gestionan mediante los contenedores que proporciona la herramienta Docker. Figura 2.6: 1) Creación de drivers que permiten la conexión entre procesos. 2) creación de procesos. 3) Encapsulamiento de procesos en contenedores. El siguiente paso es crear el único canal de nuestro prototipo que llevará el nombre de “mychannel”. Para su creación se hace uso del fichero de configuración “channel.tx” que hemos generado anteriormente. Figura 2.7: Creación del canal “mychannel”. Ahora vamos a llamar a todas las máquinas de las organizaciones (en nuestro caso procesos, porque estamos ejecutando todo en el mismo ordenador) a que se unan al canal común que contiene la cadena. Nótese que los 6 usuarios que hacen el papel de clientes no se unen al canal durante este proceso inicial, ellos deberán unirse más adelante pidiendo permiso a alguno de los dos MSP del sistema, uno de cada organización. 40 2. Desarrollo Figura 2.8: Unión de máquinas de organizaciones al canal “mychannel”. Finalmente, usando la configuración de los dos MSP que definimos en el canal, vamos a asignar a los MSP: tenemos el primero como peer0.org1.example.com y el segundo como peer0.org2.example.com. Figura 2.9: Asignación de las máquinas que actuarán como MSP en el canal. El último paso del procedimiento de inicialización del entorno es el de aceptar el chaincode. Es decir, todas las máquinas que pertenezca a la red deben aprobar el chaincode; solo una vez aceptado podrán realizar transacciones sobre la misma (claramente usando únicamente las funciones que se definen en dicho chaincode ). Figura 2.10: Ejemplo de instalación y aceptación del chaincode de la máquina peer0.org1.example.com. Esto completa la generación del entorno del prototipo. 2.5.3. Implementación del chaincode Ahora mostramos la modificación del fichero “/fabric-samples/chaincode/fabcar/go/fabcar.go” para su adaptación a soportar la gestión de documentos DID. El primer paso consiste en definir la estructura que contendrá los datos de dichos documentos, a pesar de que en la especificación proporcionada por W3C existe una amplia variedad de campos adicionales para rellenar en el documento, hemos decidido que los documentos de nuestro proyecto tengan únicamente los parámetros esenciales. Recordamos que los dos apartados esenciales de los documentos DID eran por un lado authentication y por otro service, es decir, el primero se refiere al método criptográfico que se usará para la comunicación (en nuestro caso claves públicas RSA) y el segundo indica la forma de contacto del poseedor del documento DID que en los ejemplos será un sitio web, sin embargo, éste podría ser cualquier medio como un correo electrónico, una dirección física... Pasemos entonces a las cuatro funciones que implementa el chaincode para manipular la cadena pública. 2.5. Objetivos del trabajo e implementación 41 Figura 2.11: Definición de la estructura que representa a un documento DID. El código completo del fichero con el chaincode se puede obtener a partir del siguiente enlace: https://github.com/pmartinhuertas/fabric-samples/blob/master/chaincode/fabcar/go/fabcar.go InitLedger •Parámetros de entrada: ninguno. •Funcionalidad: se le llama únicamente cuando se crea la cadena por primera vez, su objetivo es añadir un par de DID de ejemplo a la cadena inicial que nos servirán más tarde para las pruebas de ejecución que realicemos sobre el código nuevo. •Devuelve: nada en caso de funcionar correctamente y un mensaje de error si falla la inserción de los documentos de ejemplo. Estos son los documentos de ejemplo: Figura 2.12: Documentos DID de ejemplo en la cadena inicial. CreateDid •Parámetros de entrada: uno por cada atributo definido en struct Did más un atributo auxiliar de clave (key). •Funcionalidad: dados todos los datos de un documento DID, genera la estructura que lo representa y lo introduce en la cadena pública. •Devuelve: nada. QueryDidByKey •Parámetros de entrada: cadena que representa la clave. •Funcionalidad: dada una clave (por ejemplo “DID1”) busca en la cadena al documento DID al que apunta y lo devuelve. •Devuelve: si se encuentra devuelve un puntero al documento DID, en caso contrario muestra un mensaje de error por pantalla. Capítulo 3 Conclusiones 3.1. Resumen del trabajo y conclusión Finalmente, tras alrededor de 30 páginas repletas de información, el contenido del trabajo sea, probablemente, demasiado “denso”. La idea de este apartado va a ser un repaso breve que haga un seguimiento cronológico de todo lo que hemos visto, haciendo hincapié en los puntos clave que ayudan a entender la cadena de razonamiento del trabajo. Propósito del trabajo: identidades parciales Permitir la verificación de credenciales de manera selectiva a través de internet, es decir, el usuario es el que decide qué datos va a aportar. Para lograrlo hay que garantizar que dicho proceso de verificación es seguro. Éste es el punto en el que nos hemos centrado, la creación de un sistema base que proporcione dicha seguridad. Las razones por las que se decidió que este trabajo era interesante desde el punto de vista de la investigación se pueden resumir en los siguientes puntos. El trabajo trata un problema real que existe en las Certificate Authority actuales. Cuando se proporciona una clave pública a un tercero, éste puede obtener todos los datos asociados a la misma, mientras que el usuario posiblemente solo quiera otorgarle cierta información. Es un tema de investigación novedoso, la prueba está en que uno de los máximos exponentes de este concepto Rebooting Web of Trust comenzó a finales de 2015. En los últimos años ha surgido un auge de investigación sobre este tema, esto se puede ver en proyectos de gran calibre como el desarrollado por IBM que actualmente se encuentra en una versión alfa cerrada. Permite demostrar conocimientos de ingeniería informática de multitud de ramas, pudiendo destacar: •Metodología de Ingeniería del Software realizando un análisis de la competencia y un apartado de casos de uso. •Conocimientos de programación tanto de lenguajes orientados a objetos (javascript) como de lenguajes imperativos (Go un lenguaje similar a C). •Dominio de conceptos de redes, centrados principalmente en criptografía de claves y certificados. •Ampliación en áreas avanzadas como la de redes descentralizadas del tipo blockchain. 50 3. Conclusiones Todos estos puntos reforzaron la idea de que era un trabajo que merecía la pena desde un punto de vista académico e incluso, también, desde un punto de vista comercial. Para entender el desarrollo del trabajo es esencial entender los dos problemas fundamentales que nos plantean las identidades parciales: ¿Cómo podemos asociar una clave pública con un usuario concreto? ¿Cómo se realiza la verificación de credenciales? A priori no eramos capaces de dar respuestas a estas preguntas por lo que el primer paso fue realizar un estudio exhaustivo de la competencia en proyectos similares para poder así extraer conclusiones. En el trabajo al final nos decantamos por dar solución a la primera de las preguntas pues abarcar ambas suponía una carga excesiva. Principalmente aprendimos que dicha conexión de clave pública-usuario antiguamente se realizaba mediante redes de confianza PGP; sin embargo, existe una alternativa más atractiva: redes descentralizas con blockchain. El otro punto clave es que va a ser necesario la ayuda de CA tradicionales mínimamente por lo que no es un gran problema. La idea es la siguiente, una vez se ha resuelto el problema de clave pública-usuario podemos garantizar que la comunicación es con quien realmente dice ser, por lo que el último paso sería que el usuario posea una serie de documentos firmados, cada uno verificando un credencial. Luego bastaría con mandar únicamente el certificado deseado durante la comunicación. Ciertamente la obtención de dicho documentos firmados supondría tener que acudir a una CA u otra organización de confianza, sin embargo consideramos éste un problema menor en comparación con asegurar que la conexión es segura gracias a la asociación usuario-clave pública. Teniendo en cuenta todo lo indicado anteriormente pasamos al desarrollo en sí del trabajo, los dos conceptos fundamentales que hay que entender son: Documento DID: es un estándar que permite la identificación de usuarios (direcciones DID) con un servicio (forma de contacto, por ejemplo el correo electrónico). La idea es la siguiente: consideremos el pasaporte de un país, el tamaño, los campos, el estilo de letra, etc. Todos esos parámetros son un convenio que el gobierno del país en cuestión ha llevado a cabo. Estamos ante un fenómeno similar, necesitamos un documento que nos identifique pero para facilidad de tratamiento de los datos es imperativo que todos los usuarios usen la misma sintaxis. Exactamente eso define un documento DID. Red descentralizada: nos referimos a redes que funcionan mediante blockchain, es decir, nadie es el propietario absoluto de la red, sino que existen una serie verificadores de distintos organismos que soportan la red mediante “pruebas de trabajo”. Con estos dos conceptos ya podemos entender el objetivo de implementación del trabajo, vamos a crear una red descentralizada en la cual se puedan introducir documentos DID. De esta manera permitimos resolver el problema de relacionar clave pública con usuario y aseguramos que nadie tiene el control absoluto del medio. Tal sistema sería una solución para la primera parte del proyecto de identidades parciales, la segunda mitad es la verificación de credenciales que dejamos como una posible ampliación futura del proyecto. Puesto que hoy en día ya existen proyectos interesantes que podemos usar como base, nuestro código es una modificación de un sistema de blockchain open source llamado Hyperledger Fabric, en el cual adaptamos una red descentralizada que permitía la gestión de coches a una que permita la gestión de documentos DID. La implementación se resume en: Implementación Alterar el chaincode en lenguaje Go de tal manera que la cadena pase a administrar documentos DID. Crear los ficheros javascript que los usuarios ejecutarán para realizar las operaciones sobre la cadena. Éstos ficheros son los que hacen llamadas al chaincode. El proyecto está publicado en el enlance: https://github.com/pmartinhuertas/fabric-samples 3.1. Resumen del trabajo y conclusión 51 Summary and Conclusion Finally, after around 30 pages full of information, the content of the work is probably too “dense”. The idea of this section is going to be a brief review that makes a chronological follow-up of everything we have seen, emphasizing the key points that help to understand the chain of reasoning of the work. Goal of this Work: Partial Identities To allow the verification of credentials selectively through the internet, that is: the user is the one who decides what data to provide. To achieve this, it must be ensured that said verification process is safe. This is the point on which we have focused, the creation of a base system that provides such security. The reasons why this work was decided to be worthwhile from the research point of view can be summarized in the following points. The work addresses a real problem that exists in today’s certification authorities. When a public key is provided to a third party, such third party can obtain all the data associated with the public key whereas there is the possibility that the user may only want to provide certain information. It is a new research topic, the proof is that one of the maximum exponents of this concept Rebooting Web of Trust began in late 2015. In recent years there has been a boom in research on this topic, this can be seen in large-scale projects such as the one developed by IBM, which is currently in a closed alpha version. It allows to demonstrate computer engineering knowledge of many branches, being able to highlight:: •Software Engineering Methodology carrying out a competition analysis and a use cases section. •Knowledge of programming both object-oriented languages (javascript) and imperative languages ( Go a language similar to C). •Expansion in advanced areas such as decentralized blockchain networks. All these points reinforced the idea that it was worthwhile work from an academic point of view and even from a commercial point of view. To understand the development of the work it is essential to understand the two fundamental problems that partial identities pose to us: ¿How can we associate a public key with a specific user? ¿How is Credential Verification Performed? At first we were not able to provide answers to these questions, so the first step was to carry out an exhaustive study of the competition in similar projects in order to draw conclusions. For this particular work at the end we opted to give a solution to the first of the questions since covering both was an excessive amount of research. Mainly we learned that this public-user key connection was formerly made through trusted PGP networks; however, there is a more attractive alternative: decentralized networks with blockchain. The other key point is that traditional CA help is going to be minimally needed so it’s not a big problem. The idea is as follows, once the public-user key problem has been solved, we can guarantee that communication is secure so the last step would be for the user to have a series of signed documents, each one verifying a credential. Then it would be enough to send only the desired certificate during the communication. Obtaining such signed documents would certainly mean having to go to a CA 52 3. Conclusiones or other trusted organization, however we consider this a minor problem compared to ensuring that the connection is secure thanks to the user-public key association. Taking into account everything indicated above, we move on to the development of the work itself, the two fundamental concepts that must be understood are: DID document: it is a standard that allows the identification of users (DID addresses) with a service (contact form, for example email). The idea is as follows: Let’s consider the size of a passport, the font style, the number of fields... All these parameters are a convention that the government of the country in question has imposed. We are facing a similar phenomenon, we need a document that identifies us but for ease of data processing it is imperative that all users use the same syntax. That’s the philosophy behind the concept of DID document. Decentralized network: we refer to networks that work through blockchain, that is: nobody is the absolute owner of the network but there are a series of verifiers from different organizations that support the network through “proof of work”. With these two concepts we can already understand the goal of what we want to implement for this work: we are going to create a decentralized network in which DID documents can be entered. In this way we allow us to solve the problem of relating public key with user and we ensure that nobody has absolute control of the medium. Such system would be a solution to the first part of the partial identities project, the second half being the verification of credentials which we leave as a possible future upgrade of the project. As of today there are already interesting projects that we can use as a base, our code is a modification of an open source blockchain system called Hyperledger Fabric in which we adapted a decentralized network that allowed car management to one that allows management of DID documents. Implementation consists of: Implementation Alter the chaincode written in Go language in such a way that the chain allows the management of DID documents. Create the javascript files that users will execute to perform operations on the chain. These files are the ones that make calls to the chaincode. The proyect is public through the link: https://github.com/pmartinhuertas/fabric-samples 3.2. Ampliación futura 53 3.2. Ampliación futura Lo que hemos implementado durante este trabajo no es más que una prueba de concepto que nos permita mostrar el interés y la validez del tema que hemos tratado. Esto nos da una enorme libertad en cuanto a todo tipo de ampliaciones que podemos hacerle al prototipo. En caso de que el lector desee seguir trabajando sobre el proyecto o simplemente tenga curiosidad sobre cuáles son los pasos siguientes para mejorar el prototipo, a continuación presentaremos un listado con los posibles objetivos más relevantes que no se han llegado a tratar. Permitir documentos DID con sintaxis general Recordemos cómo eran los documentos DID que permitíamos en nuestro prototipo observando una figura que ya presentamos. Figura 3.1: Estructura del documento DID en nuestro proyecto. Podemos fijarnos en que tan solo permitimos documentos DID básicos. Con esto nos referimos a que por ejemplo un documento DID según el estándar W3C puede tener más de un método de autenticación o más de un método de conexión, mientras que solo permitimos uno. Así que la tarea sería generalizar la sintaxis de estos documentos de manera que el sistema sea capaz de introducir documentos DID más complejos. Crear un protocolo de comunicación auxiliar para verificar credenciales Para este punto hay que entender qué problema resuelve nuestro prototipo. La red descentralizada con documentos DID nos permite establecer la conexión entre un usuario y una clave pública, es decir asociamos una dirección DID que actúa como seudónimo a un método de comunicación como por ejemplo una dirección de correo electrónico. Una vez resuelto el problema de identificar con quién nos estamos comunicando, es necesario tratar el problema de la verificación de credenciales. La solución que proponemos desde este trabajo es indicar una dirección IPv4/IPv6 en el campo service del documento DID e implementar un cliente-servidor para establecer una comunicación con el objetivo de que el usuario proporcione un certificado obtenido mediante una CA que le verifique un credencial en concreto. Un aspecto fundamental de esta solución es que toda la información sensible, es decir la que figura en los credenciales, se transmite en una comunicación punto a punto y además no se deja rastro de la misma en ninguna base de datos pública. Hacer uso de la base de datos del estado Tal y como comentamos en el apartado en el que estudiamos las características del proyecto Hyperledger Fabric, una de las ventajas clave era que nos proporcionaba una CouchDB. Se tratan de bases de datos que contienen los verificadores que mantienen el estado más reciente de la cadena de la red descentralizada. Actualmente cuando hacemos una búsqueda de un documento DID según su dirección en la cadena hacemos un recorrido lineal de la misma. Podemos ver como esta solución no es escalable conforme aumente de tamaño la cadena. Por ello la mejoría sería hacer uso de esta funcionalidad a la hora de resolver las transacciones del tipo query. 54 3. Conclusiones Redactar un documento que explique paso a paso el chaincode Este punto de mejora se centra principalmente en el usuario que carece de conocimientos de informática. Volviendo a la generación del entorno de nuestro proyecto, la red estaba instalada de tal manera que todos los usuarios que quisieran participar en el canal común tenían que aceptar el chaincode propuesto. A partir de ese momento las únicas operaciones que se podían realizar sobre las cadenas eran las implementadas en dicho chaincode, esto quiere decir que si se quisieran evitar diversos tipos de fraudes relacionados con una utilización indebida de la red, el usuario debe leer el chaincode para así ser conocedor de exactamente qué operaciones se pueden realizar. En el caso de usuarios con bajo dominio de la informática esta tarea puede resultar complicada por lo que recomendamos redactar un documento que explique ese fragmento de código para así demostrar la transparencia de la implementación. 3.3. Opinión personal 55 3.3. Opinión personal A pesar de que la idea troncal que subyace a este trabajo ha permanecido constante, las identidades parciales, hemos tenido un largo recorrido de cambios en el enfoque que hemos seguido. Personalmente creo que para entender en profundidad la opinión que voy a exponer es necesario que haga un repaso cronológico con los todos los grandes hitos por los que hemos pasado. Nos remontamos al mes de abril de 2019 en mitad del segundo cuatrimestre del curso 2018-2019, en ese momento hacía ya más de un año que tenía una sincera atracción por el tema de la ciberseguridad y la criptografía. Desde toda la información que buscaba por internet sobre los exploits más famosos de la actualidad hasta los relatos que me contaba mi padre en su trabajo como piloto en el ejército del aire en un departamento cercano al de ciberdefensa, sentí que la ciberseguridad era aquello a lo que me quería dedicar al menos en un futuro a medio plazo. Por ello tras reflexionar durante varias semanas, decidí mandar un correo el 18 de abril a Juan Carlos Fabero Jiménez pues me pareció un excelente profesor cuando me impartió clase de la asignatura “Redes”, la cual está relacionada con temas que se tratan en ciberseguridad. Todo esto desembocó en una reunión que tuvimos el lunes 29 de abril, dicha reunión fue mi primer contacto con el tema que iba a tratar pues la idea fue íntegra de Juan Carlos. La idea era clara: identidades parciales. Es decir buscar alguna forma de verificar credenciales por internet sin tener que proporcionar todos los datos asociados a una clave. El ejemplo que me hizo entender la problemática con la que estábamos tratando fue el de la FNMT (Fábrica Nacional de Moneda y Timbre), la cual actúa de CA de manera que permite asociar una clave pública con una serie de credenciales. La idea era permitir al usuario poseer una serie de credenciales propios y ser capaz de verificarlos para acceder a servicios de terceros a través de internet. La marcha del trabajo no prosiguió hasta octubre de 2019, sin embargo, ya durante los meses de verano y el comienzo del primer cuatrimestre de 2019-2020, me sentía interesado por ver cómo podíamos solucionar el problema, por lo que hice una serie de apuntes estudiando conceptos de criptografía de clave pública como RSA/DSA, hash criptográficos como SHA-1, sistemas criptográficos como GPG y lo que pensábamos que era más importante, certificados X.509. Indico que pensábamos que dichos certificados eran la pieza más importante puesto que la idea inicial de la fragmentación de credenciales era la modificación de la especificación de los mismos para adaptar esta nueva funcionalidad. Comenzando ya de lleno en octubre empezamos a reflexionar sobre cómo se haría dicha modificación, como ayuda Juan Carlos me prestó el libro “Cryptography and Network Security, Principles and Practice”. Sinceramente el libro me ayudó enormemente y lo recomendaría especialmente para alumnos que estén iniciándose en los temas de ciberseguridad, sin embargo, el libro me hizo entender una serie de dificultades graves que planteaban los certificados X.509. Al fin y al cabo se trata de una especificación de hace más de 20 años y no parecía lo suficientemente adaptable a lo que buscábamos pues soluciones del tipo tener una clave pública para cada credencial eran totalmente inviables. Dos semanas más tarde el 29 de octubre de 2019 surge la gran revelación que tuve para la realización del trabajo. Tras días buscando información sobre el tema, me encontré con el proyecto Rebooting Web of Trust. Conforme fui informándome más y más sobre el proyecto, me di cuenta de que era exactamente el problema que queríamos resolver. En un principio me surgió un sentimiento de preocupación pues la idea del trabajo era avanzar en algo que fuese útil y que no estuviese resuelto, sin embargo este sentimiento rápidamente desapareció cuando conocí que Rebooting Web of Trust era un proyecto extremadamente novedoso (Diciembre de 2015 hasta la actualidad). Esto quería decir que primero de todo estábamos ante un tema que de gran interés a nivel de investigación y segundo todavía no existía ninguna implementación comercial de los conceptos del proyecto por lo que era el momento perfecto para hacer una aportación. La clave que hacía diferir la filosofía con la que habíamos seguido hasta el momento es que ahora no nos apoyaríamos en una modificación del X.509, sino que nos apoyaríamos en redes descentralizadas blockchain. Sobrecogido por un sentimiento de pasión sobre el trabajo, envié un correo ese mismo día a Juan Carlos para reunirnos el jueves de esa misma semana y explicarle la nueva propuesta. Así comenzó la idea del trabajo tal y como se le da a conocer en este escrito al lector, pues la propuesta resultó ser un éxito. En ese momento era consciente de que el trabajo ya iba a ser más complicado de lo esperado porque en el grado de informática apenas se estudian conceptos de blockchain, pero mis ganas 56 3. Conclusiones de saber que habíamos encontrado un tema apasionante superaban cualquier temor de cómo seguir con el trabajo. El ritmo de trabajo constante comenzó con el segundo cuatrimestre en el cuál realizaríamos reuniones semanalmente en las que comentábamos todos los avances que había realizado durante la semana anterior. Empecé un largo recorrido de investigación de todas las herramientas que necesitábamos en el trabajo, aprendiendo cada vez más sobre temas de blockchain, estudiando el funcionamiento de los documentos DID que demostrarían ser fundamentales más tarde... A mitad del desarrollo del trabajo llegué al punto que me resultó más dificultoso con diferencia: tenía que hacer la implementación de la red descentralizada que nos sirviese como base para resolver el problema de las identidades parciales. Lo importante era que en vez de hacer un prototipo de red descentralizada por mi parte, tal y como me sugirió Juan Carlos era mucho más interesante usar algún proyecto open source que ya implementase una y modificarlo. A raíz de esto encontré el proyecto Hyperledger Fabric y con ello la parte más complicada del trabajo. La puesta en marcha de Hyperledger Fabric resultó se realmente difícil. Primero intenté hacer toda la instalación en un sistema operativo Windows pero después de un día entero probando sin éxito decidí instalar una máquina virtual e instalarlo sobre Ubuntu. Esto supuso un gran avance pues ya podía empezar a instalar las más de 4 herramientas distintas que requiere el proyecto, sin embargo, empecé a experimentar numerosos errores de ejecución pues dichas herramientas había que instalarlas con versiones específicas y no con las más modernas. Después de un fin de semana entero de pruebas sin parar fui al fin capaz de ejecutar el ejemplo “Building my First Network” que proporciona Hyperledger Fabric. Yo diría que a partir de aquí el trabajo fue a un ritmo ideal pues en este momento ya sabía exactamente qué tenía que hacer y además ya tenía la base para comenzar, por lo que lo que procedía ya no era más que una cuestión de trabajar las horas que hicieran falta para llevarlo a cabo. Esto concluye un resumen de todas las fases por las que ha pasado este trabajo de fin de grado desde su génesis. Sinceramente creo que ha sido una experiencia enriquecedora académicamente en una gran variedad de aspectos. Por un lado he aprendido en profundidad sobre temas muy novedosos de la ingeniería informática como son las redes blockchain, por otro lado mi dominio de conceptos de ciberseguridad se ha visto ampliamente incrementado. La verdad es que nunca pensé en un principio que aprendería tanto de este trabajo y al final acabé con la impresión de que me ha enseñado mucho más que lo que estudio en una asignatura usual. Me gustaría dedicar este último párrafo para agradecerle a Juan Carlos Fabero por su excelente labor como director. Desde un principio mostró un gran interés en el tema y esto provocaba que aumentase mi motivación por avanzarlo. Además no fue solo su gran interés, tal y como comenté, todas las semanas teníamos reuniones en las que hacíamos un seguimiento del contenido del TFG, esto me demostró que estaba realizando un extenso trabajo y que se preocupaba sinceramente por asegurar que la evolución del trabajo era la debería. Por todo ello, quiero agradecerle una vez más a Juan Carlos su labor, indicando que el nivel de la calidad en este trabajo no habría sido posible sin su aportación. Capítulo 4 Apéndices 4.1. Infraestructura de Clave Pública - PKI Las siglas PKI corresponde a Public Key Infraestructure, corresponde a un conjunto de políticas tanto software como hardware que se han de seguir para poder obtener una comunicación segura mediante el uso de certificados digitales. Los protocolos de encriptación que se usan (principalmente RSA y DSA), recordamos que se basan en un sistema asimétrico de clave pública y clave privada. Esto provoca la aparición de un problema: tener alguna forma de verificar que una clave pública concreta, realmente pertenece a la organización/persona a la que queremos enviar el mensaje; ya que, un tercer individuo malicioso podría proporcionar una clave pública distinta suplantando una identidad. Para ello es necesario: CA: Certificate Authority son las organizaciones que emiten los certificados digitales, las más grandes que comprenden un total de 75% de los certificados son Symantec, Comodo y GoDaddy. RA: Registration Authority su objetivo es el de promover el uso de un estándar que se ha escogido por convenio para facilitar las interacciones de la infraestructura. VA: Verificacion Authority, es decir una organización de confianza que se encargue de verificar que en efecto cada clave pública pertenece a la identidad correspondiente. Figura 4.1: Esquema con los procedimientos definidos en la infraestructura de clave pública.