UNIVERSIDAD DON BOSCO VICERRECTORÍA ACADÉMICA FACULTAD DE INGENIERÍA TRABAJO DE GRADUACIÓN PARA OPTAR AL GRADO DE Maestro en Seguridad y Gestión de Riesgos Informáticos PROYECTO Aplicación para gestionar certificados digitales como Autoridad Certificadora (AC) de acuerdo a la Ley de firma electrónica de El Salvador PRESENTADO POR Álvaro Hernán Zavala Ruballo Leonel Antonio Maye Menjívar ASESOR Dr. Francisco Rodríguez-Henríquez Antiguo Cuscatlán, La Libertad, El Salvador, Centro América Enero 2020 ii ÍNDICE GENERAL ÍNDICE GENERAL ................................................................................................... ii Introducción ........................................................................................................... viii Capitulo I. Planteamiento del Problema ................................................................ 11 1.1 Problema de investigación ....................................................................... 11 1.2 Antecedentes del problema ...................................................................... 11 1.3 Objetivos del proyecto .............................................................................. 13 Objetivo general .............................................................................................. 13 Objetivos específicos ...................................................................................... 13 1.4 Justificación del proyecto ......................................................................... 13 1.5 Delimitación del Proyecto ......................................................................... 14 Capitulo II. Estado del arte .................................................................................... 16 2.1 Criptografía .............................................................................................. 16 2.1.1 Objetivos de la criptografía ................................................................ 16 2.1.2 Definición de criptosistema ................................................................ 17 2.2 Criptografía simétrica ............................................................................... 18 2.2.1 AES ................................................................................................... 18 2.3 Criptografía asimétrica ............................................................................. 19 2.3.1 Algoritmo de curvas elípticas (ECC) .................................................. 20 2.4 Funciones resumen (hash) ....................................................................... 21 2.4.1 Huella Digital...................................................................................... 22 2.5 Firma Digital ............................................................................................. 22 2.6 Infraestructura de llave pública ................................................................ 25 2.6.2.1 Certificado digital ............................................................................ 29 2.6.2.2 Lista de certificados revocados (CRL) ............................................ 31 2.7 Usurpación de identidad ........................................................................... 32 2.8 Ley de Firma Electrónica de El Salvador ................................................. 33 2.8.1 Objeto de la ley .................................................................................. 33 2.8.2 Autoridad Competente ....................................................................... 34 2.8.3 Acreditación y prestación de los servicios de certificación ................ 35 2.8.4 De los certificados electrónicos ......................................................... 37 2.8.5 Derechos y obligaciones de los Usuarios .......................................... 39 iii Capitulo III. Metodología de la investigación ......................................................... 43 3.1 Tipo de investigación................................................................................ 43 3.2 Unidades de Análisis ................................................................................ 43 3.3 Variables y su medición ........................................................................... 44 3.3.1 Definición de variables ....................................................................... 44 3.3.1 Indicadores y su medición ................................................................. 45 3.3.2 Instrumentos de medición .................................................................. 46 3.4 Procesamiento y análisis de la información ............................................. 46 3.5 Cronograma de actividades ..................................................................... 48 Capitulo IV. Análisis y discusión de resultados ..................................................... 50 4.1 Variable: Requerimientos certificados digitales ........................................ 50 4.2 Variable: Tamaño de llaves para la firma digital ....................................... 52 4.3 Variable: Especificaciones técnicas firma digital. ..................................... 53 4.4 Requerimientos de la aplicación según La Ley de Firma Electrónica ...... 54 4.5 Procesos de una CA considerando el estándar NIST PKI 800-32 ........... 56 Infraestructura de Llave Pública (PKI) ............................................................ 56 Arquitectura PKI: Jerárquica ........................................................................... 57 Proceso, componentes y estructuras de una PKI ........................................... 58 Capitulo V. Propuesta técnica ............................................................................... 60 5.1 Roles Equipo de Trabajo .......................................................................... 60 5.2 Fase de Inicio ........................................................................................... 60 5.2.1 Visión del producto ............................................................................ 60 5.2.2 Historias de Usuario .......................................................................... 61 5.2.3 Pila del producto ................................................................................ 64 5.2.4 Prioridades de la Pila del producto. ................................................... 65 5.3 Fase de Desarrollo ................................................................................... 66 5.3.1 Definición de las Iteraciones. ............................................................. 66 5.3.2 Desarrollo de las Iteraciones planificadas ............................................. 67 5.3.2.1 Iteración 1 ....................................................................................... 67 5.3.2.2 Iteración 2 ....................................................................................... 84 5.3.2.3 Iteración 3 ....................................................................................... 93 5.4 Fase de Cierre ............................................................................................. 99 iv 5.4.1 Pruebas ................................................................................................. 99 5.4.1.1 Pruebas Iteración 1 ...................................................................... 100 5.4.1.2 Pruebas Iteración 2 ...................................................................... 101 5.4.1.3 Pruebas Iteración 3 ...................................................................... 102 5.4.2 Revisión de Iteraciones ........................................................................... 103 Capítulo VI. Discusión de seguridad y aplicabilidad ............................................ 105 6.1 Discusión de seguridad .............................................................................. 105 6.1.1 Posibles ataques.................................................................................. 105 6.1.2 Aspectos de seguridad implementados ............................................... 107 6.1.3 Aspectos de seguridad por implementar a futuro ................................ 111 6.2 Discusión de aplicabilidad .......................................................................... 112 Capítulo VII. Conclusiones y recomendaciones .................................................. 117 7.1 Conclusiones .......................................................................................... 117 7.2 Recomendaciones.................................................................................. 118 Bibliografía .......................................................................................................... 119 Anexos ................................................................................................................ 121 Anexo 1. Cronograma ...................................................................................... 121 Anexo 2. Hoja de anotaciones para especificaciones técnicas ........................ 121 Anexo 3. Cuadro comparativo de tamaños de llave ......................................... 122 Anexo 4. Hoja de anotaciones para análisis de requerimientos ....................... 122 Anexo 5. Hoja de análisis para procesos de una AC ....................................... 122 Índice de Tablas Tabla 1. Cuadro de definición de variables 45 Tabla 2. Cuadro de variables y su medición 46 Tabla 3. Cronograma de actividades del proyecto. 48 Tabla 4. Requerimientos certificado digital 51 Tabla 5. Comparación de fortaleza de llaves 52 Tabla 6. Especificaciones técnicas para ECDSA 53 Tabla 7. Equipo de trabajo para el desarrollo de las iteraciones 60 Tabla 8. Historia de usuario Diseño de base de datos y administración de usuarios y roles 62 v Tabla 9. Historia de usuario control de solicitudes de creación de certificados 62 Tabla 10. Historia de usuario generación de certificados para usuarios finales. 63 Tabla 11. Consulta y verificación de certificados 63 Tabla 12. Revocación de certificados 64 Tabla 13. Pila del producto para la aplicación 65 Tabla 14. Descripción de prioridades de la Pila del producto 66 Tabla 15. División de la Pila del producto en Iteraciones 67 Tabla 16. Pila de la Iteración 1 67 Tabla 17. Permisos asignados a cada rol. 69 Tabla 18. Pila de la Iteración 2 85 Tabla 19. Backlog del Sprint 3. 93 Tabla 20. Razones de revocación de un certificado. 95 Tabla 21. Formato matriz de pruebas 99 Tabla 22. Criterio de aceptación para las pruebas. 99 Tabla 23. Tabla de pruebas Iteración 1. 100 Tabla 24. Tabla de pruebas Iteración 2. 101 Tabla 25. Tabla de pruebas Iteración 3. 102 Tabla 26. Comparativa de llaves RSA y ECC 110 Índice de Figuras Fig 1. Gráfico de la curva elíptica secp256k1 (Nakamoto 2010) ........................... 21 Fig 2. Proceso de firma digital (NIST, Digital Signature Standard (DSS) 2013) .... 23 Fig 3. Ejemplo de jerarquía de PKI, RFC 4158 (IETF, RFC 4158 2018) ............... 30 Fig 4. Formato X.509 V3 ....................................................................................... 31 Fig 5. Infraestructura de llave pública .................................................................... 56 Fig 6. Arquitectura PKI Jerárquica ......................................................................... 57 Fig 7. Proceso entre componentes y estructuras de datos de una PKI ................. 58 Fig 8. Diagrama Entidad Relación usado por la aplicación. .................................. 68 Fig 9. Formulario de registro de usuario por un SA. .............................................. 70 Fig 10. Formulario de auto registro de usuarios finales. ........................................ 71 Fig 11. Interfaz de inicio de sesión. ....................................................................... 71 vi Fig 12. Página principal de la aplicación. .............................................................. 72 Fig 13. Fragmento de código de filtro de autorización. .......................................... 74 Fig 14. Página de acceso no autorizado. .............................................................. 74 Fig 15. Interfaz para consulta de usuarios. ........................................................... 74 Fig 16. Patrón de desarrollo MVC empleado......................................................... 75 Fig 17. Diagrama de clases para operaciones criptográficas ................................ 77 Fig 18. Interfaz para generación de CSR .............................................................. 78 Fig 19. Ejemplo de llave privada y CSR generada. ............................................... 79 Fig 20. Formulario de solicitud de certificado ........................................................ 80 Fig 21. Ejemplo de correo enviado por solicitud aceptada. ................................... 81 Fig 22. Interfaz de consulta de solicitudes de certificados. ................................... 82 Fig 23. Revisar solicitud CSR para aprobación o denegación .............................. 83 Fig 24. Solicitud de contraseña para usar llave privada de la AC. ........................ 84 Fig 25. Ejemplo de correo enviado incluyendo el archivo .crt del certificado ........ 84 Fig 26. Generación de llaves privada-pública y certificado de la AC. .................... 85 Fig 27. Proceso de generación y almacenamiento seguro de llave privada AC. ... 86 Fig 28. Aplicación para cifrador AES usado en llave privada AC. ......................... 86 Fig 29. Descifrado de la llave privada de la AC para firmar certificados emitidos. 87 Fig 30. Ejemplo del repositorio de certificados ...................................................... 88 Fig 31. Ejemplo de certificado generado por la aplicación. ................................... 88 Fig 32. Interfaz para consulta y descarga de certificados. .................................... 90 Fig 33. Descarga de certificado con validación de Catpcha .................................. 91 Fig 34. Verificación de la validez del certificado. ................................................... 92 Fig 35. renovación de un certificado. ..................................................................... 92 Fig 36. Pantalla para revocación de certificados. .................................................. 96 Fig 37. Generación de CRL. .................................................................................. 96 Fig 38. Consulta y descarga de CRL. .................................................................... 97 Fig 39. CRL generada en el sistema de archivos con extension .crl. .................... 98 Fig 40. Opción de revocar certificado. ................................................................... 98 Fig 41. Proceso de generación y almacenamiento seguro de llave privada. ....... 111 Fig 42. Descifrado de la llave privada ................................................................. 111 vii Fig 43. Certificado visto desde Chrome .............................................................. 113 Fig 44. Certificado visto desde Safari .................................................................. 114 Fig 45. Error incorporando TLSv1.3 a Apache 2.4.2 ........................................... 115 viii Introducción Los certificados de llave pública o certificados digitales son estructuras de datos que unen valores de llave pública a los sujetos. El enlace se confirma al hacer que una Autoridad Certificadora (AC o CA1) de confianza firme digitalmente cada certificado (IETF, RFC 5280 2018). Una AC es una entidad de confianza que gestiona los certificados digitales desde su emisión hasta su revocación, utilizando en ellos la firma electrónica, para lo cual se emplea la criptografía de llave pública, las tareas de emisión y revocación de certificados las puede instar el titular del certificado o cualquier tercero con interés legítimo ante la AC El presente trabajo propone una aplicación para la gestión de certificados digitales basándose en La Ley de firma electrónica de El Salvador, software que debe ser implementado por una AC. La investigación se desglosa de la siguiente forma: Capítulo I. Planteamiento del problema El primer capítulo contiene la delimitación y planteamiento del problema de investigación, los objetivos de la investigación y justificación. Capítulo II. Marco de la Investigación En este capítulo se describe el Estado del Arte de la base teórica que fundamenta el tema de investigación. Capítulo III. Metodología de la Investigación En dicho capítulo, se encuentra el tipo de investigación, unidades de análisis, variables y su medición. Capítulo IV. Análisis y discusión de resultados Se analizan los requerimientos técnicos funcionales que deben ser incorporados en la aplicación a desarrollar 1 Certificate Authority ix Capítulo IV. Propuesta técnica Presenta el desarrollo por fases, mediante la metodología Scrum, de la aplicación para la gestión de certificados digitales. Capítulo VI. Discusión de seguridad y aplicabilidad Se hace una discusión y recomendaciones de aspectos importantes de seguridad que la aplicación implementa, así como algunas áreas de aplicación. Capítulo IV. Conclusiones y recomendaciones Capítulo que contiene las conclusiones y recomendaciones de la investigación. 10 CAPÍTULO I PLANTEAMIENTO DEL PROBLEMA 11 Capitulo I. Planteamiento del Problema 1.1 Problema de investigación En El Salvador actualmente se están realizando esfuerzos para implementar la firma electrónica y como parte de esta tecnología se requiere de una infraestructura de llave pública (PKI)2, la cual deberá validar a los Prestadores de Servicios de Certificación (AC). Para una AC es necesario implementar el software que le permita gestionar los certificados digitales y realizar los procedimientos de seguridad para la ejecución con garantías de las operaciones criptográficas, como el cifrado, la firma digital, y el no repudio de transacciones electrónicas. 1.2 Antecedentes del problema La Ley de Firma Electrónica de El Salvador fue aprobada en 2015 (Cerén, Ley de Firma Electrónica 2015). El Ministerio de Economía fue designado como la Autoridad Certificadora Raíz o Root CA en inglés y en abril de 2016 entró en vigencia. En octubre de 2016 se crea el Reglamento de la Ley de Firma Electrónica (Cerén, Reglamento de la Ley de Firma Electrónica, 2016). A continuación, se forma el Comité Técnico Consultivo en julio 2017, con el objetivo de asesorar la implementación del proyecto, este está conformado por gobierno, empresa y universidades (MINEC 2017). Para la supervisión y control se crea la Unidad de Firma Electrónica en 2016, (STPP 2017) que será la autoridad registradora y acreditadora raíz, y la competente para la acreditación, control y vigilancia de los proveedores de los servicios de certificación 2 Public Key Infrastructure 12 electrónica y de almacenamiento de documentos electrónicos, de conformidad con la ley, su reglamento y las normas y reglamentos técnicos. La factura electrónica en El Salvador es un proyecto que ha sido aprobado y uno de los bloques principales para su implementación es la firma electrónica. Con este esfuerzo modernizador de América Latina, en el siglo XXI se ha implementado la factura electrónica, iniciando con Chile en 2003 y a mediados de 2017, se suman otras experiencias avanzadas en Argentina, Brasil, Ecuador, México, Perú y Uruguay. Actualmente, existen proyectos en proceso en varios países de la región latinoamericana, entre ellos: Costa Rica, Colombia, Guatemala, Panamá y Paraguay, y se ha manifestado la intención de desarrollar sistemas nacionales en Honduras, República Dominicana, Venezuela y por supuesto en El Salvador (BCR 2019). De acuerdo al Plan Estratégico Institucional 2015-2019 publicado en abril 2019, por el Ministerio de Hacienda de El Salvador, uno de los proyectos que se está llevando a cabo en el país es el de la Factura Electrónica, que obedece al objetivo estratégico de implementar una política tributaria progresiva que genere el cumplimiento voluntario de las obligaciones tributarias, mediante el fortalecimiento de los controles de la Administración Tributaria. les para su implementación es la firma electrónica (BCR 2019). Sobre las AC, la Ley de Firma Electrónica establece la equivalencia jurídica únicamente aquellas autoridades certificadoras que cumplan los requisitos técnicos emanados por la Unidad de Firma Electrónica y que se sometan a la evaluación para respaldar la competencia técnica y credibilidad de los entes acreditados. A 2020, se puede afirmar que se están realizando esfuerzos importantes para la implementación de la firma y factura electrónica, pero, aún no se cuenta hasta la fecha con una Infraestructura de Llave Pública proporcionada por el Ministerio de Economía, como AC Raíz, y por la limitación mencionada, tampoco existen Autoridades 13 Certificadoras acreditadas para brindar los servicios de expedición y revocación de certificados digitales. 1.3 Objetivos del proyecto Objetivo general Desarrollar aplicación para gestionar certificados digitales como Autoridad Certificadora (AC) de acuerdo a la Ley de firma electrónica de El Salvador. Objetivos específicos • Establecer los requerimientos de la aplicación de gestión de certificados. • Definir y aplicar los algoritmos criptográficos con las garantías de seguridad en la ejecución de las operaciones. • Crear módulos para la expedición y revocación de certificados. 1.4 Justificación del proyecto Uno de los principales desafíos a que se enfrentan los medios telemáticos es asegurar la identidad de las partes que intervienen en cualquier operación. La solución adoptada para garantizar la seguridad en el uso de medios electrónicos está basada en la criptografía. Los certificados digitales son un bloque importante en los esquemas de firma electrónica para garantizar el no repudio de operaciones electrónicas y están basados en la utilización de técnicas de criptografía asimétrica, en la que existe una llave pública a disposición de todo el mundo y que sirve para identificar al titular del certificado y una 14 llave privada que solamente conoce el titular del certificado y le sirve para firmar electrónicamente. Esta investigación busca proporcionar una aplicación para la gestión de certificados digitales para llevar a cabo los procedimientos de seguridad criptográficos de una AC y establecer una base fundamental de cómo debería funcionar en El Salvador, esto para ser tomada en cuenta por las entidades que deseen certificarse como prestadores de estos servicios. 1.5 Delimitación del Proyecto • El proyecto está enmarcado en un plazo de 6 meses. • Es aplicable únicamente considerando la Ley de Firma Electrónica de El Salvador. • El proyecto no abarca el establecimiento de políticas y procedimientos para registrarse y acreditarse como una AC ante el MINEC. • No se considera el manejo de pagos para la obtención de certificados, se deja para futuros proyectos. 15 CAPÍTULO II ESTADO DEL ARTE 16 Capitulo II. Estado del arte 2.1 Criptografía La criptografía utiliza técnicas matemáticas para codificar mensajes y hacerlos ininteligibles para receptores no autorizados. Es el estudio de técnicas matemáticas relacionadas con aspectos de seguridad de la información, tales como confidencialidad, integridad de datos, autenticación de entidades y autenticación de origen de datos (A. Menezes 1996). La criptografía no es el único medio para proporcionar seguridad de la información, sino más bien un conjunto de técnicas. 2.1.1 Objetivos de la criptografía 1. La confidencialidad es un servicio utilizado para mantener protegido el contenido de la información de todos menos aquellos autorizados para tenerlo (A. Menezes 1996). El secreto es un término sinónimo de confidencialidad y privacidad. Existen numerosos enfoques para proporcionar confidencialidad, desde protección física hasta algoritmos matemáticos que hacen que los datos sean ininteligibles. 2. La integridad de los datos es un servicio que aborda la alteración no autorizada de los datos (ISACA 2017). Para asegurar la integridad de los datos, se debe tener la capacidad de detectar la manipulación de datos por parte de personas no autorizadas. La manipulación de datos incluye cosas tales como inserción, eliminación y sustitución. 3. La autenticación es un servicio relacionado con la identificación. Esta función se aplica tanto a las entidades como a la información misma. Dos partes que inician una comunicación deben identificarse entre sí. La información entregada a través de un canal debe autenticarse en cuanto a su origen, fecha de origen, contenido 17 de datos, hora de envío, etc. Por estas razones, este aspecto de la criptografía generalmente se subdivide en dos clases principales: autenticación de entidad y autenticación de origen de datos. La autenticación del origen de datos proporciona implícitamente la integridad de los datos (porque si se modifica un mensaje, la fuente ha cambiado) (A. Menezes 1996). 4. El no repudio es un servicio que evita que una entidad niegue compromisos o acciones anteriores (ISACA 2017). Cuando surgen disputas debido a que una entidad niega que se hayan tomado ciertas acciones, es necesario un medio para resolver la situación. Por ejemplo, una entidad puede autorizar la compra de bienes por otra entidad y luego negar que se haya otorgado dicha autorización. Se necesita un procedimiento que involucre a un tercero de confianza para resolver la disputa. 2.1.2 Definición de criptosistema Un criptosistema es una quíntupla (P, C, K, E, D) donde las siguientes condiciones se cumplen (Stinson 1995): • P es el espacio de textos en claro. • C es el espacio de textos cifrados. • K es el espacio de llaves. • Para cada llave k ϵ K existe una función de cifrado ek ϵ E y su respectiva función de descifrado dk ϵ D. donde ek: P → C y dk: C → P y dk(ek(x)) = x para toda x ϵ P. La criptografía puede dividirse en un numero básico de herramientas criptográficas (primitivas) usadas para proveer seguridad entre ellas las involucradas en este proyecto se describen a continuación. 18 2.2 Criptografía simétrica La criptografía simétrica (también conocida como de llave secreta) es un método criptográfico monollave, esto quiere decir que se usa la misma llave para cifrar y descifrar. Esto supone un grave problema a la hora de realizar el intercambio entre el emisor y el receptor, dado que si una tercera persona estuviese escuchando el canal podría hacerse con la llave, siendo inútil el cifrado (Stalling 2011). Es importante que la llave sea difícil de adivinar y el método de cifrado empleado el adecuado. Hoy en día, con la capacidad computacional disponible, si se emplean los algoritmos adecuados, dependiendo del método de cifrado empleado se puede obtener una llave en cuestión de minutos-horas. 2.2.1 AES El algoritmo AES (Advanced Encryption Standard) también conocido como Rijndael fue el ganador del concurso convocado en el año 1997 por el NIST (Instituto Nacional de Normas y Tecnología) con objetivo de escoger un nuevo algoritmo de cifrado. En 2001 fue tomado como FIPS y en 2002 se transformó en un estándar efectivo. Desde el año 2006 es el algoritmo más popular empleado en criptografía simétrica (Stalling 2011). AES opera sobre una matriz de 4x4 bytes. Mediante un algoritmo se reordenan los distintos bytes de la matriz. El cifrado es de llave simétrica, por lo que la misma llave aplicada en el cifrado se aplica para el descifrado. Basado en El algoritmo Rijndael, al contrario que su predecesor DES, Rijndael es una red de sustitución permutación, no una red de Feistel. AES es rápido tanto en software como en hardware, es relativamente fácil de implementar, y requiere poca memoria (NIST, Advanced Encryption Standard 2001). El algoritmo AES funciona mediante una serie de bucles que se repiten. 10 ciclos para llaves de 128 bits, 12 para 192 y 14 para 256. 19 2.3 Criptografía asimétrica La criptografía asimétrica (también conocida como de llave pública) es un sistema que emplea un par de llaves. Este par de llaves pertenecen a la misma persona. Una es de dominio público y cualquiera puede tenerla y la otra es privada (Stalling 2011). El funcionamiento de este sistema es el siguiente: El remitente usa la llave pública del destinatario para cifrar un mensaje y sólo con la llave privada se podrá descifrar el mensaje. De esta forma se consigue que sólo el destinatario pueda acceder a la información. De la misma forma si el propietario usa su llave privada para cifrar un mensaje sólo se podrá descifrar con la llave pública. Pero, si todo el mundo puede tener acceso a la llave pública ¿Que utilidad tiene esto? Precisamente por esto es interesante el sistema. Usando la llave privada se demuestra la identidad, pues, en teoría, solo el poseedor de esa llave privada la puede usar. La mayor ventaja de este sistema es que la distribución de llaves es más fácil y segura que usando su contraparte que es la criptografía simétrica donde solo existe una llave secreta para cifrar y descifrar. Sin embargo, este sistema tiene varias desventajas (A. Menezes 1996): • Mayor tiempo de proceso en mismas condiciones respecto a llave simétrica. • Llaves más grandes que en sistemas simétricos. • El mensaje cifrado es más grande que el original. Actualmente para firma digital se utiliza criptografía asimétrica y se enfoca en algoritmos como: RSA y Curvas Elípticas. 20 2.3.1 Algoritmo de curvas elípticas (ECC)3 Algoritmo de curvas elípticas (ECC) es un término utilizado para describir un conjunto de herramientas criptográficas y protocolos cuya seguridad se basa en versiones especiales del problema del logaritmo discreto. No usa números módulo p en relación al algoritmo RSA (Stalling 2011). ECC se basa en conjuntos de números que están asociados con objetos matemáticos llamados curvas elípticas. ECC incluye una variedad de muchos esquemas criptográficos que fueron diseñados inicialmente para números modulares como el cifrado ElGamal y el algoritmo de firma digital. Se cree que el problema del logaritmo discreto es mucho más difícil cuando se aplica a puntos en una curva elíptica. Las llaves más cortas resultan en dos beneficios (Nakamoto 2010): • Facilidad de gestión de llaves • Computación eficiente Estos beneficios hacen que las variantes de esquema de cifrado basadas en curvas elípticas sean muy atractivas para aplicaciones donde los recursos informáticos están restringidos. A continuación, se muestra un ejemplo grafico de una curva elíptica de secp256k1 usada por la criptomoneda Bitcoin y2 = x3 + 7 sobre los números reales. 3 Elliptic Curve Cryptography 21 Fig 1. Gráfico de la curva elíptica secp256k1 (Nakamoto 2010) 2.4 Funciones resumen (hash) Una función de resumen (hash) es un algoritmo matemático que, con una entrada A, nos da una salida B. B se conoce como digesto o huella digital (A. Menezes 1996). Una función resumen puede ser cualquier algoritmo matemático, pero tiene que cumplir una serie de propiedades 1. Para una misma función hash, sea cual sea la longitud de la entrada A la salida B tiene que ser de un tamaño fijo. 2. Para cada A, B tiene que ser única. 3. Tiene que ser rápido y fácil de calcular. 4. No se puede volver a A desde B. 5. No puede presentar colisiones. Esto quiere decir que para dos A diferentes no se puede dar un mismo B. Observando las condiciones 1 y 2 vemos que esto es imposible en la función MD5 que nos da como resultado un hash de 128 bits. Esto quiere decir que como máximo 22 hay solo 2128 textos diferentes, lo cual, es falso. Se hace por tanto muy importante que las colisiones sean mínimas y que encontrarlas sea muy difícil. En el caso de funciones hash criptográficas se requiere de forma adicional que sean uniformes (para una A elegida aleatoriamente todos los valores hash son equiprobables) y con efecto avalancha (un cambio de un único bit en A supone una B completamente diferente). Podemos distinguir dos grupos de funciones: las que tienen como objetivo mantener la integridad de los mensajes (detección de modificaciones) y las que tienen como objetivo verificar el origen del mensaje (autenticación). 2.4.1 Huella Digital Un algoritmo de huella digital (función resumen) es un procedimiento que asigna un elemento de datos arbitrariamente grande (como un archivo informático) a una cadena de bits mucho más corta, su huella digital, que identifica de forma única los datos originales para todos los fines prácticos, como humanos las huellas dactilares identifican a las personas de manera única por ello de forma analógica podemos decir que la huella digital de un archivo lo identifica de manera única y cualquier variación, por pequeña que sea, en el documento original produce una huella digital distinta. Este es uno de los elementos más importantes en el esquema de firma digital. 2.5 Firma Digital La firma digital es el resultado de una transformación criptográfica de datos que, cuando se implementa correctamente, proporciona un mecanismo para verificar la autenticación de origen, la integridad de los datos y el no repudio del signatario (Cerén, Ley de Firma Electrónica 2015). En el mundo físico, es común usar firmas autógrafas en mensajes escritos a mano o escritos a máquina. Se usan para unir el signatario al mensaje. Y es común confundir el término firma digital con el simple escaneo de la firma autógrafa y su inserción en un 23 documento como imagen, esto no es considerado firma digital, ya que para ello debe proveer los mecanismos mencionados en el primer párrafo. Del mismo modo, una firma digital es una técnica que vincula a una persona/entidad con los datos digitales. Este enlace puede ser verificado independientemente por el receptor y por cualquier tercero. La firma digital es un valor criptográfico que se calcula a partir de los datos y una llave secreta conocida solo por el firmante. En el mundo real, el receptor del mensaje necesita la seguridad de que el mensaje pertenece al remitente y no debería poder rechazar el origen de ese mensaje. Este requisito es muy importante en las aplicaciones comerciales, ya que la probabilidad de una disputa sobre el intercambio de datos es muy alta. A continuación, se muestra una imagen que describe el proceso de firma digital. Fig 2. Proceso de firma digital (NIST, Digital Signature Standard (DSS) 2013) 24 Un algoritmo de firma digital incluye un proceso de generación de firma y un proceso de verificación de firma. Un signatario usa el proceso de generación para generar una firma digital en datos; un verificador utiliza el proceso de verificación para verificar la autenticidad de la firma (NIST, Digital Signature Standard (DSS) 2013). Cada firmante tiene una llave pública y privada y es el propietario de ese par de llaves. Como se muestra en la Figura 2, la llave privada se usa en el proceso de generación de firmas. El propietario del par de llaves es la única entidad autorizada para usar la llave privada para generar firmas digitales. Para evitar que otras entidades afirmen ser el propietario del par de llaves y usar la llave privada para generar firmas fraudulentas, la llave privada debe permanecer en secreto. Los algoritmos de firma digital aprobados por el NIST4 (RSA y ECC) están diseñados para evitar que un adversario que no sabe la llave privada del firmante genere la misma firma que el firmante en un mensaje diferente. En otras palabras, las firmas están diseñadas para que no puedan falsificarse. Se pueden usar varios términos alternativos para referirse al propietario del par de llaves o signatario. Una entidad que tiene la intención de generar firmas digitales en el futuro se puede denominar el signatario previsto. Antes de la verificación de un mensaje firmado, el firmante se denomina el signatario reclamante hasta que se pueda obtener una garantía adecuada de la identidad real del firmante. La llave pública se usa en el proceso de verificación de firma (vea la Figura 2). La llave pública no necesita mantenerse en secreto, pero se debe mantener su integridad. Cualquiera puede verificar un mensaje correctamente firmado utilizando la llave pública del signatario. Tanto para la generación de firma como para los procesos de verificación, el mensaje (es decir, los datos firmados) se convierten en una representación de longitud fija del 4 National Institute of Standard and Technology – Instituto Nacional de Estándares y Tecnología (NIST) 25 mensaje (huella digital) por medio de una función hash aprobada no “rota”. Tanto el mensaje original como la firma digital están disponibles para un verificador. Un verificador requiere la seguridad de que la llave pública que se utilizará para verificar una firma pertenece a la entidad que afirma haber generado una firma digital (es decir, el signatario reclamante). Es decir, un verificador requiere la seguridad de que el firmante es el propietario real del par de llaves público/privado utilizado para generar y verificar una firma digital. Se debe realizar una unión de la llave pública y la identidad de su propietario para proporcionar esta garantía, esto se logra de manera segura con lo especificado en el estándar RFC 3820 de PKI, de acuerdo con dicho estándar una AC, de confianza ante terceros, debe emitir un certificado digital donde avala el vínculo de la llave pública con su propietario. Un verificador también requiere la seguridad de que el propietario del par de llaves posee realmente la llave privada asociada con la llave pública, y que la llave pública es una llave matemáticamente correcta. Al obtener estas garantías, el verificador tiene la seguridad de que, si la firma digital se puede verificar correctamente utilizando la llave pública, la firma digital es válida (es decir, el propietario del par de llaves realmente firmó el mensaje). La validación de la firma digital incluye la verificación (matemática) de la firma digital y la obtención de las garantías adecuadas. 2.6 Infraestructura de llave pública Una infraestructura de llave pública (PKI) vincula las llaves públicas a las entidades, permite que otras entidades verifiquen los enlaces de las llaves públicas y proporciona los servicios necesarios para la gestión continua de las llaves en un sistema distribuido (NIST, Public Key Infrastructure 2001). 26 Es una combinación de hardware, software, y políticas y procedimientos de seguridad, que permiten la ejecución con garantías de operaciones criptográficas, como el cifrado, la firma digital, y el no repudio de transacciones electrónicas (IETF, RFC 3820 2018). 2.6.1 Componentes de una PKI PKI proporciona seguridad de llave pública. Proporciona la identificación de llaves públicas y su distribución. Una anatomía de PKI comprende los siguientes componentes: Autoridad Certificadora, Autoridad de Registro, Repositorio, Archivo y Usuarios (NIST, Public Key Infrastructure 2001). Autoridad Certificadora (AC) La autoridad de certificación, o AC, es el componente básico de la PKI. La AC es una colección de hardware, software y las personas que lo operan. La AC se conoce por dos atributos: su nombre y su llave pública. La AC realiza cuatro funciones básicas de PKI: 1. Emite certificados (es decir, los crea y los firma); 2. Mantiene información sobre el estado del certificado y emite CRL5; 3. Publica sus certificados y CRL actuales (por ejemplo, no vencidos), para que los usuarios puedan obtener la información que necesitan para implementar servicios de seguridad; 4. Y mantiene archivos de información de estado sobre los certificados vencidos que emitió. Estos requisitos pueden ser difíciles de satisfacer simultáneamente. Para cumplir con estos requisitos, la AC puede delegar ciertas funciones a los otros componentes de la infraestructura. 5 Certificate Revocation List 27 Una AC puede emitir certificados a los usuarios, a otras AC o ambas. Cuando una AC emite un certificado, afirma que el sujeto (la entidad nombrada en el certificado) tiene la clave privada que corresponde a la clave pública contenida en el certificado. Si la AC incluye información adicional en el certificado, la AC está afirmando que la información corresponde al tema también. Esta información adicional puede ser información de contacto (por ejemplo, una dirección de correo electrónico) o información de política (por ejemplo, los tipos de aplicaciones que se pueden realizar con esta clave pública). Cuando el sujeto del certificado es otra AC, el emisor está afirmando que los certificados emitidos por la otra AC son confiables. La AC inserta su nombre en cada certificado (y CRL) que genera, y los firma con su clave privada. Una vez que los usuarios establecen que confían en una AC (directamente o mediante una ruta de certificación) pueden confiar en los certificados emitidos por esa AC. Los usuarios pueden identificar fácilmente los certificados emitidos por esa AC comparando su nombre. Para asegurarse de que el certificado sea genuino, verifican la firma utilizando la clave pública de la AC. Como resultado, es importante que la AC brinde protección adecuada para su propia clave privada Autoridad de Registro (AR) Un AR (en inglés RA6) está diseñado para verificar el contenido del certificado para la AC. El contenido del certificado puede reflejar la información presentada por la entidad que solicita el certificado, como una licencia de conducir o un recibo de pago reciente. También pueden reflejar información proporcionada por un tercero. Por ejemplo, el límite de crédito asignado a una tarjeta de crédito refleja la información obtenida de las agencias de crédito. Un certificado puede reflejar datos del departamento de Recursos Humanos de la compañía, o una carta de un funcionario designado de la compañía. Por ejemplo, el certificado de Bob podría indicar que tiene autoridad de firma 6 Registration Authority 28 para contratos pequeños. La RARA agrega estas entradas y proporciona esta información a la AC. Al igual que la AC, la AR es una colección de hardware, software y la persona o personas que lo operan. A diferencia de una AC, una AR a menudo será operada por una sola persona. Cada AC mantendrá una lista de AR acreditadas; esa es una lista de ARs que se consideran confiables. La AC conoce un RA por un nombre y una clave pública. Al verificar la firma de la AR en un mensaje, la AC puede estar segura de que una AR acreditada proporcionó la información, y se puede confiar en ella. Como resultado, es importante que el AR proporcione protección adecuada para su propia clave privada Repositorio PKI Un repositorio es una base de datos de certificados digitales activos para un sistema de AC. El negocio principal del repositorio es proporcionar datos que permitan a los usuarios confirmar el estado de los certificados digitales para individuos y empresas que reciben mensajes firmados digitalmente, y además gestionar la actualización de certificados. Estos destinatarios de mensajes se denominan partes confiables. Las AC publican certificados y CRL en repositorios. Archivo (historial) Un archivo acepta la responsabilidad del almacenamiento a largo plazo de la información histórica en nombre de la AC. Un archivo afirma que la información era buena en el momento en que se recibió y que no se ha modificado mientras estaba en el archivo. La información proporcionada por la AC al archivo debe ser suficiente para determinar si la AC emitió un certificado tal como se especifica en el certificado y si es válido en ese momento. El archivo protege esa información a través de mecanismos técnicos y procedimientos apropiados mientras está bajo su cuidado. Si surge una disputa en una fecha posterior, la información se puede usar para verificar que la llave 29 privada asociada con el certificado se usó para firmar un documento. Esto permite la verificación de firmas en documentos antiguos (como testamentos) en una fecha posterior. Usuarios de la PKI Los usuarios de la PKI son organizaciones o individuos que usan la PKI, pero no emiten certificados. Confían en los otros componentes de la PKI para obtener certificados y para verificar los certificados de otras entidades con las que hacen negocios. Las entidades finales incluyen la parte que confía, que se basa en el certificado para conocer, con certeza, la llave pública de otra entidad; y el titular del certificado, que recibe un certificado y puede firmar documentos digitales. Se debe tener en cuenta que un individuo u organización puede ser una parte confiable y un titular de certificado para diversas aplicaciones. 2.6.2 Estructuras de datos de una PKI 2.6.2.1 Certificado digital Un certificado digital o como se le conoce en criptografía: certificado de llave pública es un documento electrónico usado para probar la propiedad de una llave pública, este incluye de acuerdo con el estándar X.509 del RFC 3280 (IETF, RFC 3280 2018) ciertas partes, entre ellas las más importantes: llave publica e identidad del propietario, firma digital de la AC que emite el certificado y periodo de validez. La AC es la entidad de confianza responsable de emitir y revocar certificados firmándolos con su llave privada, normalmente estas tienen un certificado raíz auto firmado o firmado por la autoridad raíz, en caso que haya una jerarquía de confianza, que la identifica como autoridad de certificación. 30 Fig 3. Ejemplo de jerarquía de PKI, RFC 4158 (IETF, RFC 4158 2018) La construcción de la ruta de certificación en una PKI jerárquica es un proceso directo que simplemente requiere que la parte que confía recupere sucesivamente certificados del emisor hasta un certificado que fue emitido por el ancla de confianza (la "AC raíz" en la Figura 3). El estándar RFC 4158 explica otras variaciones de la estructura (IETF, RFC 4158 2018). El certificado X.509 V3 (Figura 3) emitido a usuarios finales debe contar con los siguientes elementos de acuerdo con el estándar RFC 3280 (IETF, RFC 3820 2018) 31 Fig 4. Formato X.509 V3 2.6.2.2 Lista de certificados revocados (CRL) Los certificados contienen una fecha de vencimiento. Desafortunadamente, los datos en un certificado pueden volverse poco confiables antes de que llegue la fecha de 32 vencimiento. Los emisores de certificados necesitan un mecanismo para proporcionar una actualización de estado para los certificados que han emitido. Un mecanismo es la lista de revocación de certificación X.509 (CRL). Las CRL son el análogo PKI de la lista activa de tarjetas de crédito que los empleados de la tienda revisan antes de aceptar grandes transacciones con tarjeta de crédito. La CRL está protegida por una firma digital del emisor de la CRL. Si se puede verificar la firma, los usuarios de CRL saben que el contenido no ha sido alterado desde que se generó la firma. Las CRL contienen un conjunto de campos comunes y también pueden incluir un conjunto opcional de extensiones. 2.7 Usurpación de identidad La usurpación de la identidad, en firma digital, debe ser entendida como la suplantación del firmante por un impostor para obtener un beneficio injusto, y recibe cada vez más atención en materia de fraudes cometidos con la ayuda de las tecnologías de la información, la premisa para usurpar la identidad de un firmante es tener acceso a su llave privada. Las malas decisiones técnicas del criptosistema, así como el mal manejo de parte de los usuarios de su llave privada, pues normalmente el eslabón más débil en la seguridad de la información es la llamada “capa 8”, darán como resultado que la llave privada del firmante se vea comprometida y dar lugar a ataques de usurpación de identidad. Según el principio de Kerckhoffs el oponente conoce el algoritmo criptográfico utilizado, Por lo tanto, la seguridad del sistema debe estar basada en: • La calidad (fortaleza) del algoritmo • El tamaño del espacio de la llave (tamaño en bits de la llave) Mitigando lo más posible los errores de la “capa 8” y seleccionando algoritmos que provean las garantías de seguridad mínimas con respecto a la calidad y al tamaño de las llaves, y que las funciones resumen para el cálculo de las huellas digitales no entes “rotas” son decisiones claves. Debe mencionarse que la vulnerabilidad de la criptografía 33 empleada dependerá en gran medida de estas decisiones de seguridad donde los algoritmos como SHA-1 para cálculo de digestos o el RSA de 1024 bits son altamente frágiles a ataques de fuerza bruta, siendo esta la principal arma de un hacker. Ataque de fuerza bruta. Consiste en intentar todas las posibles llaves hasta dar con la correcta. Este tipo de ataque es factible según el número de posibles llaves lo cual suele venir dado por la longitud (tamaño) de la llave. Otras formas de vulnerar el criptosistema pueden venir de lo explicado a continuación Búsqueda de alguna debilidad o fallo. Esta debilidad suele provenir de: • Obsolescencia del algoritmo. Para ello es importante tener en cuenta los nuevos descubrimientos que pueden dejar un algoritmo obsoleto. Por ejemplo, un avance en factorización de números primos podría dejar obsoleto el algoritmo RSA o un avance en el cálculo de logaritmos discretos lo haría con ECC. Otro ejemplo sería el uso de ordenadores cuánticos que acelerarían mucho lo velocidad de computación • Un fallo en la implementación: Un ejemplo típico es el uso de generador de números aleatorios con debilidades como el ataque que realizaron Ian Goldberg y David Wagner al SSL de Netscape • Aplicación de técnicas de criptoanálisis. 2.8 Ley de Firma Electrónica de El Salvador A continuación, y de acuerdo con (Cerén, Ley de Firma Electrónica 2015) se establecen aquellas partes de la ley referentes o relacionados a la gestión de certificados por parte de una AC. 2.8.1 Objeto de la ley La ley tiene por objeto: 34 a) Equiparar la firma electrónica simple y firma electrónica certificada con la firma autógrafa; b) Otorgar y reconocer eficacia y valor jurídico a la firma electrónica certificada, a los mensajes de datos y a toda información en formato electrónico que se encuentren suscritos con una firma electrónica certificada, independientemente de su soporte material; c) Regular y fiscalizar lo relativo a los proveedores de servicios de certificación electrónica, certificados electrónicos y proveedores de servicios de almacenamiento de documentos electrónicos. 2.8.2 Autoridad Competente La Autoridad de Control y Vigilancia Art. 35.- Créase la Unidad de Firma Electrónica, como parte del Ministerio de Economía, el que en el texto de esta Ley podrá abreviarse MINEC. El ministro nombrará al funcionario que estará a cargo de esta Unidad, quien deberá reunir los requisitos que para tal efecto se establezcan en el reglamento de esta Ley. De la Unidad de Firma Electrónica Art. 36.- La Unidad de Firma Electrónica será la autoridad registradora y acreditadora raíz, y la competente para la acreditación, control y vigilancia de los proveedores de los servicios de certificación electrónica y de almacenamiento de documentos electrónicos, de conformidad con esta Ley, su reglamento y las normas y reglamentos técnicos. Competencias de la Unidad de Firma Electrónica Art. 37.- La Unidad de Firma Electrónica tendrá las siguientes competencias: 35 a) Elaborar las normas y los reglamentos técnicos que sean necesarios para la implementación de la presente Ley, en coordinación con el Organismo Salvadoreño de Reglamentación Técnica (OSARTEC) y el Organismo Salvadoreño de Normalización (OSN); b) Otorgar, registrar o revocar la acreditación a los proveedores de servicios de certificación y a los prestadores de servicios de almacenamiento de documentos electrónicos, una vez cumplidas las formalidades y requisitos de esta Ley, su reglamento y demás normas y reglamentos técnicos aplicables; c) Validar los certificados electrónicos emitidos a favor de los proveedores de servicios de certificación y de almacenamiento de documentos electrónicos; 2.8.3 Acreditación y prestación de los servicios de certificación El art 43 inciso a) de los requisitos generales para una AC menciona lo siguiente a) Contar con suficiente capacidad técnica para garantizar la seguridad, la calidad y la fiabilidad de los certificados emitidos, de conformidad a los requerimientos contenidos en las normas técnicas; Obligaciones de los Proveedores Art. 48.- Los proveedores de servicios de certificación tendrán las siguientes obligaciones: a) Adoptar las medidas necesarias para determinar la exactitud de los certificados electrónicos que proporcionen, la identidad y la calidad del signatario; b) Garantizar la validez, vigencia, legalidad y seguridad del certificado 36 electrónico que proporcione; c) Garantizar la adopción de las medidas necesarias para evitar la falsificación de certificados electrónicos y de las firmas electrónicas certificadas que proporcionen; d) Verificar la información suministrada por el signatario; e) Crear y mantener un archivo actualizado de los certificados emitidos en medios electrónicos, para su consulta por plazo indefinido; f) Garantizar a los usuarios los mecanismos necesarios para el ejercicio de los derechos de acceso, rectificación, cancelación y oposición; g) Sin perjuicio de otras obligaciones establecidas en la Ley de Protección al Consumidor, deberá informar a los interesados de sus servicios de certificación, utilizando un lenguaje comprensible, a través de su sitio de internet y a través de cualquier otra forma de acceso público, los términos precisos y condiciones para el uso del certificado electrónico y, en particular, de cualquier limitación sobre su responsabilidad, así como de los procedimientos especiales existentes para resolver cualquier controversia; h) Garantizar la autenticidad, integridad y confidencialidad de la información, y documentos relacionados con los servicios que proporcione. A tales efectos, deberán mantener un sistema de seguridad informática y respaldos confiables y seguros de dicha información, de conformidad a lo establecido en la presente Ley, su reglamento, y normas y reglamentos técnicos; i) Efectuar las notificaciones para informar a los signatarios y personas interesadas y las publicaciones necesarias, acerca del vencimiento, revocación, suspensión o cancelación de los certificados electrónicos que proporcione, así como de cualquier otro aspecto de relevancia para el público en general, en relación con los mismos; 37 j) Dar aviso a la Fiscalía General de la República, cuando en el desarrollo de sus actividades tenga indicios de la comisión de un delito; k) Renovar anualmente la fianza establecida en el Art 43, literal d) de esta Ley, previo a su vencimiento; y, l) Cumplir con las demás obligaciones establecidas en esta Ley, su reglamento, y demás normas y reglamentos técnicos. El incumplimiento de cualquiera de los requisitos anteriores dará lugar a las sanciones establecidas en la presente Ley. 2.8.4 De los certificados electrónicos Garantía de la Autoría de la Firma Electrónica Certificada Art. 57.- El certificado electrónico garantiza la autoría de la firma electrónica certificada, así como la autenticidad, integridad, confidencialidad y no repudiación del documento electrónico. Contenido del Certificado Electrónico Art. 58.- El certificado electrónico deberá contener al menos, la siguiente información: a) Identificación del titular del certificado electrónico, indicando su domicilio y dirección electrónica; b) Identificación del proveedor de servicios de certificación que proporciona el certificado electrónico, indicando su domicilio y dirección electrónica; c) Fecha de la acreditación y caducidad asignada al proveedor de servicios de certificación por la Unidad de Firma Electrónica; d) Fecha de emisión y expiración del certificado; e) Número de serie o de identificación del certificado; f) La firma electrónica certificada del prestador de servicios de certificación 38 que emitió el certificado; g) Datos de verificación de la firma, los cuales deben corresponder a la información de su creación y que están bajo el control del firmante; h) Cualquier información relativa a las limitaciones de uso, vigencia y responsabilidad a las que esté sometido el certificado electrónico; i) Indicación de la ruta de certificación; y, Si el certificado ha sido emitido por una persona que ha actuado en representación de una persona natural o jurídica; en tal caso, el certificado deberá incluir una indicación del documento legal, público, o privado autenticado, que acredite de forma fehaciente las facultades del firmante para actuar en nombre de la persona física o jurídica a la que representa. La falta de alguno de estos requisitos invalidará el certificado. Vigencia del Certificado Electrónico Art. 59.- El proveedor de servicios de certificación y el signatario, de mutuo acuerdo, determinarán el plazo de vigencia del certificado electrónico. Cancelación del Certificado Electrónico Art. 60.- El certificado electrónico de la firma electrónica certificada puede ser cancelado por resolución judicial, de conformidad con el ordenamiento legal. Asimismo, puede ser cancelado por resolución razonada emitida por el Ministerio de Economía a través de la Unidad de Firma Electrónica, en cualquiera de los supuestos siguientes: a) Que se compruebe que alguno de los datos del certificado electrónico proporcionado por el proveedor de servicios de certificación, es falso; b) Que sea violentado el sistema de seguridad del proveedor de servicios de certificación, y que afecte la integridad y confiabilidad del certificado; c) Que el signatario dé aviso al proveedor, de la destrucción o extravío del 39 certificado electrónico. En tal caso, el proveedor de servicios de certificación procederá inmediatamente a la cancelación del certificado; y, d) Por fallecimiento, o muerte presunta, previa resolución judicial. Para el caso de persona jurídica en el cese de sus actividades, por disolución Procedimiento para la Cancelación de un Certificado Electrónico Art. 61.- El Ministerio de Economía por medio de la Unidad de Firma Electrónica, previa denuncia del interesado o de oficio, ordenará audiencia por tres días hábiles al proveedor de servicios de certificación, y con lo que conteste o no, se abrirá a pruebas por ocho días hábiles, a fin de demostrar cualquiera de las situaciones consideradas en el artículo anterior; finalizado el término probatorio, la Unidad de Firma electrónica emitirá resolución razonada, en un plazo no mayor de diez días hábiles, para que determine si es procedente la cancelación del certificado que ampara la firma electrónica. Esta resolución admitirá recurso de revisión y será resuelto en el plazo de quince días hábiles, con la vista de autos. 2.8.5 Derechos y obligaciones de los Usuarios Art. 62.- Además de los derechos reconocidos por la Ley de Protección al Consumidor y cualquier otra normativa aplicable, los usuarios o titulares de los servicios regulados en esta Ley, tendrán los siguientes derechos, según sea el caso: a) A ser informados por los proveedores de servicios de certificación, de las características generales de los procedimientos de creación y de verificación de firma electrónica certificada, así como de las reglas sobre prácticas de certificación, y los demás que éstos se comprometan a seguir en la prestación de los servicios, lo que deberá realizarse de forma previa a la adquisición del servicio; b) A la confidencialidad en la información, en los supuestos en que los 40 proveedores de servicios de certificación, y de almacenamiento de documentos electrónicos decidan cesaren sus actividades; c) A ser informados, antes de la emisión de un certificado, de los precios de los servicios, incluyendo cargos adicionales y formas de pago, en su caso; de las condiciones precisas para la utilización de los servicios y de sus limitaciones de uso, y de los procedimientos de reclamación y de resolución de litigios; d) A que el prestador de servicios le proporcione la información sobre su domicilio en el país; e) A ser informado, al menos con noventa días de anticipación, por los prestadores de servicios de certificación, y almacenamiento de documentos electrónicos, para los efectos del cierre de actividades; f) A traspasar sus datos a otro prestador de servicios de certificación y de almacenamiento de documentos electrónicos, si así lo solicitan; g) A que el proveedor no proporcione u otorgue servicios no solicitados; deteriorar la calidad de los servicios contratados en calidad de inferioridad; o servicios adicionales cobrados no pactados; a no recibir publicidad comercial de ningún tipo por intermedio del proveedor, salvo autorización expresa del usuario en todos los casos señalados; y, h) La cancelación del certificado por petición del usuario o su representante legal. La violación a los derechos previstos en este artículo constituye infracción grave en los términos señalados en la Ley de Protección al Consumidor, y será sancionada como tal. La determinación de la infracción y la imposición de la sanción correspondiente será competencia del Tribunal Sancionador de la Defensoría del Consumidor, y de acuerdo con el procedimiento previsto en la Ley de Protección al Consumidor, en lo que fuere aplicable. 41 Obligaciones de los Usuarios Art. 63.- Los usuarios o titulares de firmas electrónicas certificadas, y de almacenamiento de documentos electrónicos, quedarán obligados en el momento de proporcionar los datos de su identidad personal u otras circunstancias objeto de certificación, a: a) Brindar declaraciones veraces y completas; b) Custodiar adecuadamente los mecanismos de seguridad del funcionamiento del sistema de certificación que le proporcione el prestador y actualizar sus datos en la medida que éstos vayan cambiando, so pena de responder por la indemnización de daños y perjuicios derivada del incumplimiento de estas obligaciones; y, c) Solicitar oportunamente la suspensión o revocación del certificado, ante cualquier circunstancia que pueda haber comprometido la privacidad de los datos de creación de firma electrónica certificada. 42 CAPÍTULO III METODOLOGÍA DE LA INVESTIGACIÓN 43 Capitulo III. Metodología de la investigación 3.1 Tipo de investigación La investigación a realizar para el presente trabajo es de tipo descriptiva. Este tipo de estudio busca descubrir el estado de las variables que intervienen dentro de esta, es decir se debe medir, recolectar o evaluar datos sobre diversos conceptos (variables), aspectos, dimensiones o componentes del proyecto a desarrollar. 3.2 Unidades de Análisis • Certificado digital X.509 v3. El formato a estudiar es el más común para los certificados de clave pública y está definido por X.509. Debido a que X.509 es muy general, el formato está aún más restringido por los perfiles definidos para ciertos casos de uso, como la Infraestructura de clave pública (X.509) como se define en RFC 5280. En sistemas de firma electrónica, el sujeto de un certificado suele ser una persona u organización. La versión X.509 v3 permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL y de la CA. • Algoritmo de firma digital de curva elíptica (ECDSA)7. El algoritmo estudiado es una modificación del algoritmo DSA que emplea operaciones sobre puntos de curvas elípticas en lugar de las exponenciaciones que usa DSA. La principal ventaja de este esquema es que requiere números de tamaños menores para brindar la misma seguridad que DSA o RSA. 7 Elliptic Curve Digital Signature Algorithm 44 • Ley de Firma Electrónica de El Salvador. Los elementos a estudiar en La Ley son todos aquellos relacionados con los requerimientos de los certificados y los procesos que debe realizar una AC en cuanto al ciclo de vida de estos certificados que son emitidos a usuarios finales. • Estándar NIST PKI. Las secciones a considerar son las relacionadas al funcionamiento de los componentes y estructuras de datos involucradas en una PKI. Se busca describir el flujo de procesos seguido. 3.3 Variables y su medición 3.3.1 Definición de variables Variable Definición conceptual Definición operacional Requerimientos Son declaraciones, en lenguaje natural y/o en diagramas, de los servicios que se espera que el software proporcione y de las restricciones bajo las cuales debe de funcionar. Son las especificaciones acerca de la delimitación y funcionalidad que ofrecerá el software de gestión de certificados para una AC considerando la Ley de Firma Electrónica de El Salvador. Especificaciones técnicas Documento o descripción de las normas, exigencias y procedimientos técnicos aplicados que debe reunir Son los requisitos técnicos que requiere el algoritmo ECDSA para garantizar la seguridad de las operaciones criptográficas. 45 un producto, proceso, servicio o sistema. Tamaños de llave El tamaño o longitud de la clave es el número de bits de una clave que utiliza un algoritmo criptográfico (por ejemplo, un cifrador). Tamaños en bits de las llaves seguras empleadas en el algoritmo ECDSA. Procesos de una AC Los procesos involucrados en la gestión de los certificados firmados. Esto incluye las tareas de creación, revocación y renovación de certificados por parte de la AC. La gestión del ciclo de vida de los certificados desde su solicitud hasta su revocación o renovación por caducidad. Tabla 1. Cuadro de definición de variables 3.3.1 Indicadores y su medición Este cuadro presenta nuevamente las variables en estudio con sus respectivos indicadores, los instrumentos de medición, la técnica a aplicar y a que unidad de análisis pertenecen. Unidad de análisis Variables Indicadores Técnicas a aplicar Instrumento de medición u observación Certificado Digital X.509 V3 Requerimientos Listado de requerimientos Observación Hoja de anotaciones (Anexo 2) ECDSA Especificaciones técnicas Listado de especificaciones técnicas Análisis documental Hoja de anotaciones (Anexo 2) 46 Tamaño de llaves Tamaños de llave de seguridad mínima en bits Análisis documental Cuadro comparativo (Anexo 3) Ley de firma electrónica de El Salvador + Estándar NIST PKI Requerimientos Listado de requerimientos Observación Hoja de anotaciones (Anexo 4) Procesos de una AC Diagrama de procesos Observación Hoja de anotaciones (Anexo 5) Tabla 2. Cuadro de variables y su medición 3.3.2 Instrumentos de medición • Hoja de anotaciones Documento donde se detallan las observaciones, notas, explicaciones u otros tipos de comentarios que deben tomarse en cuenta para describir las variables de la investigación. • Cuadro Comparativo Estrategia que permite identificar las semejanzas y diferencias de dos o más objetos o hechos. Una cuestión importante es que, luego de hacer el cuadro comparativo se enuncia la conclusión a la que se llegó. 3.4 Procesamiento y análisis de la información El proceso a seguir se describe a continuación. Recolección de información Primero se seleccionarán los documentos a analizar según las unidades de análisis definidas, luego se procederá a estudiar los apartados relacionas con las 47 variables y su medición llenando los instrumentos de medición respectivos hasta obtener los resultados por cada variable. Las técnicas empleadas serán análisis documental y observación Procesamiento de la información La información recopilada será analizada de acuerdo a su relevancia para el proyecto. De esta manera incluir únicamente aquellos resultados que son pertinentes y generan un aporte para la realización del proyecto. Análisis de la información De acuerdo a cada variable y su indicador se generan las conclusiones o resultados finales a ser tomados en cuenta para la realización del proyecto. Los resultados se muestran por unidad de análisis y sus variables en el capítulo IV de este documento. 48 3.5 Cronograma de actividades A continuación, se describe el cronograma de actividades para la realización del proyecto. Id. Nombre de tarea Comienzo Fin Duración 2020 jul. ago.may.abr. sep. nov.mar. jun.feb. oct. 1 9d10/2/20202/2/2020Elaboración de perfil del proyecto 2 8d25/2/202018/2/2020Revisión de bibliografía 1d9/3/20189/3/2018 Enviar anteproyecto (primeros 3 capítulos) 3 2d27/2/202026/2/2020 Capítulo I. Planteamiento del problema 12 1d22/11/202022/11/2020Entrega de artículo 10 9 7 5 4 8d6/3/202028/2/2020Capítulo II. Estado del arte 2d8/3/20207/3/2020 Capítulo III. Metodología de la investigación 45d15/5/20201/4/2020 Capítulo IV. Análisis y discusión de resultados 2d6/11/20205/11/2020 Capítulo VI. Conclusiones y recomendaciones 14d20/11/20207/11/2020Elaboración de artículo 11 1d22/11/202022/11/2020Entrega de proyecto final 8 157d4/11/20201/6/2020Capitulo V. Propuesta Técnica 6 Tabla 3. Cronograma de actividades del proyecto. 49 CAPÍTULO IV ANÁLISIS Y DISCUSIÓN DE RESULTADOS 50 Capitulo IV. Análisis y discusión de resultados A continuación, se presenta el desglose de la información recopilada y analizada para medir las variables planteadas en la investigación 4.1 Variable: Requerimientos certificados digitales Para establecer los requerimientos de un certificado digital se tomaron en cuenta dos fuentes: El Estándar RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) y La ley de firma electrónica del El Salvador. Ley de firma electrónica RFC 5280 1. Identificación del titular del certificado electrónico, indicando su domicilio y dirección electrónica Sujeto, (sujeto titular) expresado en notación DN (Distinguished Name), compuesto por CN (Common Name), OU (Organizational Unit), O (Organization), C (Country), STREET (Domicilio) e E (Email). Además, la ciudad y el estado. El sujeto puede ser una persona, un servidor o un servicio. 2. Identificación del proveedor de servicios de certificación que proporciona el certificado electrónico, indicando su domicilio y dirección electrónica; Emisor 3. Fecha de la acreditación y caducidad asignada al proveedor de servicios de certificación por la Unidad de Firma Electrónica No Aplica 4. Fecha de emisión y expiración del certificado Validez 51 5. Número de serie o de identificación del certificado Número de serie del certificado (debe ser único para cada certificado emitido por una misma CA) 6. La firma electrónica certificada del prestador de servicios de certificación que emitió el certificado • Firma digital del certificado 7. Datos de verificación de la firma, los cuales deben corresponder a la información de su creación y que están bajo el control del firmante • Información de clave pública del sujeto o Algoritmo de clave pública o Clave pública del sujeto 8. Cualquier información relativa a las limitaciones de uso, vigencia y responsabilidad a las que esté sometido el certificado electrónico • Versión • ID del algoritmo utilizado por el CA para firmar • Algoritmo usado para firmar el certificado 9. Indicación de la ruta de certificación; y Certificado de CA raíz 10. Si el certificado ha sido emitido por una persona que ha actuado en representación de una persona natural o jurídica; en tal caso, el certificado deberá incluir una indicación del documento legal, público, o privado autenticado, que acredite de forma fehaciente las facultades del firmante para actuar en nombre de la persona física o jurídica a la que representa No Aplica Tabla 4. Requerimientos certificado digital La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL y de la CA, etc.). Lo 52 anterior con el fin de incluir los campos que la ley menciona pero que el estándar básico no tiene. Por tabla anterior podemos concluir los campos que debe incluir el certificado y que son indispensables según la ley y sus equivalentes en el estándar X.509 V3 así como los campos que deben ser agregados. 4.2 Variable: Tamaño de llaves para la firma digital La fortaleza de un sistema criptográfico descansa en la calidad del algoritmo y el tamaño de las llaves. Para la elección del tamaño de llaves se considera el contenido en (NIST, Recommendation for key management 2016) del cual se obtiene el siguiente cuadro comparativo: Security Strength Symmetric key Algorithms FFC (e.g., DSA, D-H) IFC (e.g., RSA) ECC (e.g., ECDSA) <=80 2TDEA L=1024 N= 160 K= 1024 f=160-223 112 3TDEA L=2048 N= 224 K=2048 f=224-255 128 AES-128 L=3072 N= 256 K=3072 f=256-383 192 AES-192 L=7680 N= 384 K=7680 f=384-511 256 AES-256 L=15360 N= 512 K=15360 f=512+ Tabla 5. Comparación de fortaleza de llaves Tener en cuenta que las fortalezas de las claves de 192 y 256 bits identificadas para los algoritmos FFC e IFC (sombreadas en amarillo) no se incluyen actualmente en los estándares del NIST por razones de interoperabilidad y eficiencia. Además, tener en cuenta que las combinaciones de algoritmo / tamaño de clave que se han estimado en una potencia de seguridad máxima de menos de 112 53 bits (sombreada en naranja arriba) ya no están aprobadas para aplicar la protección criptográfica (por ejemplo, cifrar datos o generar una firma digital). Con el análisis de la tabla 2 se concluye cuáles son tamaños de llave seguros para la aplicación los cuales están en la zona sombreada verde. En la tabla 3 se plantean algoritmos y tamaños de llaves con base en la tabla 3. 4.3 Variable: Especificaciones técnicas firma digital. Posterior al análisis del algoritmo en (NIST, Digital Signature Standard (DSS) 2013) se obtiene el siguiente resultado: Descripción Especificación técnica Algoritmo de firma Elliptic Curve Digital Signature Algorithm (ECDSA) Curva utilizada Secp256r1 Función Hash para Huella Digital SHA3-256withECDSA Cifrador por bloques AES Tamaño de llave para AES 256 bits (32 bytes) Función Hash para cifrado de llave privada SHA3-256 Formato de exportación de llaves y certificados Privacy Enhaced Mail (PEM) Contraseñas >=12 caracteres Tabla 6. Especificaciones técnicas para ECDSA De acuerdo a los tamaños de llaves y algoritmos sugeridos por el NIST (National Institute of Standards and Technology) (NIST, Recommendation for key management 2016), (NIST, SHA3 standard 2015), (NIST, Digital Signature Standard (DSS) 2013) las especificaciones anteriores superan la seguridad mínima requerida en cada uno de ellos siendo como objetivo mínimo una seguridad de 128 bits. 54 4.4 Requerimientos de la aplicación según La Ley de Firma Electrónica A partir del análisis de la ley y los artículos referentes a los certificados digitales se sintetizan los siguientes requerimientos a ser implementados en la aplicación • Para la validación de ruta de certificación, la unidad de firma electrónica ejercerá como tal, este será el certificado auto firmado incluido para todas las CAs • Los certificados de otras CAs estarán firmados por la autoridad raíz. • Emitir certificados de acuerdo a los requerimientos de Tabla 2. • Las llaves deberán ser generadas por el solicitante para garantizar la confidencialidad de la llave privada, • El solicitante deberá presentar una CSR (Certificate Signing Request) para poder generarle el certificado correspondiente. • Los certificados con base a su fecha de vencimiento deberán entrar la categoría de certificados caducados, en caso contrario formarán parte de la categoría de certificados vigentes. • Para garantizar la privacidad de las llaves de firma de certificados de la CA, se debe implementar protocolo de almacenamiento seguro de llaves. • Implementar un formulario para suministrar y verificar la información del signatario, incluyendo la CSR presentada. • Crear y mantener un archivo actualizado de los certificados emitidos en medios electrónicos, para su consulta y verificación por plazo indefinido. Un usuario podría querer verificar la validez de un certificado en particular. • La aplicación debe permitir mecanismos de actualización y revocación (cancelación de certificados) por parte de la CA previa solicitud del usuario. • La revocación también puede darse de manera unilateral por parte de la CA si se comprueba alguna ilegalidad o vulneración del certificado, así como otros casos emitidos en la ley y deberá quedar registrada su justificación (datos falsos, vulneración los datos del proveedor, extravío o destrucción, fallecimiento, cese de actividades en una persona jurídica). 55 • Informar al usuario de un certificado a través de correo electrónico o La creación y modificación de certificados o La revocación de certificados o La suspensión de certificados o Vencimiento y renovación de certificados La revocación de un certificado consiste en anular su validez completamente antes de la fecha de caducidad, lo cual deja inservible para cualquier uso legal La suspensión de un certificado consiste en invalidar temporalmente un certificado, mientras se realizan investigaciones para determinar si se revoca o vuelve a tener efectos legales válidos. • Contar con un mecanismo de consulta eficiente de una Lista de Revocación de certificados (CRL8) para los usuarios de los certificados electrónicos y evitar cualquier tipo de suplantación y/o fraude. • El plazo de vigencia del certificado es de mutuo acuerdo entre el signatario y la CA, pero para efectos de esta aplicación, este será un parámetro configurable. Requerimientos de roles y perfiles Aunque la ley no explica exactamente qué medidas de seguridad implementar se consideran las siguientes: • Manejo de sesiones de usuario con caducidad por inactividad • Contraseñas de 12 caracteres (4 palabras aleatorias) almacenadas usando SHA3 • Manejo de roles y perfiles (Usuario, administrador, super administrador) • Envío de token por correo para activación de cuentas 8 Certificate Revocation List 56 4.5 Procesos de una CA considerando el estándar NIST PKI 800-32 Infraestructura de Llave Pública (PKI) Fig 5. Infraestructura de llave pública Componentes PKI Autoridad Certificadora (AC) Repositorio PKI • Archivo • Certificados • CRL Usuarios PKI Estructuras PKI Certificados de llave publica X.509 Lista de Revocación de Certificados (CRL) Arquitectura PKI Jerárquica 57 Arquitectura PKI: Jerárquica Fig 6. Arquitectura PKI Jerárquica Referencias Root CA: Autoridad Certificadora Raíz CA: Autoridad Certificadora EE: Entidad Final (End Entity) Root CA CA EE EE EE CA EE EE EE CA EE EE EE 58 Proceso, componentes y estructuras de una PKI Fig 7. Proceso entre componentes y estructuras de datos de una PKI Par de llaves Generadas por Usuario Llave pública Identificación del usuario Certificate Signing Request (CSR) Autoridad Certificadora (AC) • Emitir • Actualizar • Revocar • Suspender Certificado electrónico X509 V3 Envío Repositorio Cumple con funciones de: - Certificados - Archivo - CRL CRL Cert Cert raíz Cert AC 59 CAPÍTULO V PROPUESTA TÉCNICA 60 Capitulo V. Propuesta técnica Para el desarrollo del software, se utiliza como referencia la metodología de desarrollo de software ágil Scrum, y basándonos en algunos de sus artefactos como: Pila del producto, Pila de Iteraciones e Iteración (Sprint) (scrum.org 2020). Para ello se establecieron tres fases: Inicio, Desarrollo y Cierre. Además, se creado un nombre ficticio para la Autoridad Certificadora: eSignAC. 5.1 Roles Equipo de Trabajo En Scrum, el equipo se focaliza en construir software de calidad, la gestión se centra en definir cuáles son las características que debe tener el producto. El equipo entrega productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto. Equipo Scrum Rol Responsable Dueño del producto Universidad Don Bosco Dueño del proceso Francisco Rodríguez-Henríquez Equipo de desarrollo Leonel Maye Álvaro Zavala Tabla 7. Equipo de trabajo para el desarrollo de las iteraciones 5.2 Fase de Inicio 5.2.1 Visión del producto El producto final es una aplicación para gestionar el ciclo de vida de los certificados digitales, desde la solicitud (CSR) hasta su revocación o vencimiento, para una Autoridad Certificadora encargada de emitirlos a entidades finales, 61 siguiendo los estándares de seguridad mínimos en las operaciones criptográficas y de acuerdo con la Ley de Firma Electrónica de El Salvador. 5.2.2 Historias de Usuario Las historias de usuario son una representación simple de un requisito para el proyecto de software en este caso se definen con base a los requerimientos definidos en el apartado 4.4 (Requerimientos de la aplicación según La Ley de Firma Electrónica) de este documento. Las historias que se utilizarán son las siguientes: 1. Diseño de base de datos y administración de usuarios y roles. 2. Control de solicitudes de creación de certificados. 3. Generación de certificados para usuarios finales. 4. Consulta y verificación de certificados. 5. Revocación de certificados. Y se desglosan en las siguientes descripciones detalladas: Historia de usuario Número: 1 Usuario: Equipo de trabajo Nombre de la historia: Diseño de base de datos y administración de usuarios y roles. Prioridad en negocio: Alta Riesgo en desarrollo: Bajo Iteración asignada: 1 Programador responsable: Álvaro Zavala. Descripción: Se diseña la base de datos a emplear en la aplicación. Permite la creación, modificación, bloqueo, desbloqueo, asignación de roles y activación e inactivación de usuarios, así como su búsqueda y consulta. Incluye un auto registro de usuarios y manejo de la información de su perfil y restablecimiento de contraseñas. 62 Validación: Los usuarios serán capaces de registrarse o ser registrados y acceder a sus datos en la aplicación a través de un usuario y contraseña mostrando las opciones de acuerdo a su rol asignado. Tabla 8. Historia de usuario Diseño de base de datos y administración de usuarios y roles Historia de usuario Número: 2 Usuario: Equipo de trabajo Nombre de la historia: Control de solicitudes de creación de certificados. Prioridad en negocio: Alta Riesgo en desarrollo: Medio Iteración asignada: 1 Programador responsable: Álvaro Zavala. Descripción: Función para que los usuarios finales puedan: • Generar la solicitud de firma de certificados (CSR) • A partir de La CSR puedan solicitar el certificado La aplicación debe validar las CSR enviada para poder ser aceptada. Tanto los usuarios finales como los administradores deben poder consultar las CSR’s con base en estados y códigos, los usuarios finales solo tienen acceso a solicitudes propias Validación: • Los usuarios generan y envían solicitudes válidas. • Las solicitudes están disponibles para consulta Tabla 9. Historia de usuario control de solicitudes de creación de certificados Historia de usuario Número: 3 Usuario: Equipo de trabajo Nombre de la historia: Generación de certificados para usuarios finales. Prioridad en negocio: Alta Riesgo en desarrollo: Medio Iteración asignada: 2 Programador responsable: Leonel Maye. Descripción: 63 Función para que los usuarios administradores puedan: • Aprobar solicitudes de creación de certificados. • Denegar solicitudes de creación de certificados. La aplicación debe validar las extensiones a incluir en cada certificado y solicitar una contraseña para descifrar la llave privada de la AC y proceder a firmar el certificado. El certificado se genera, notifica al usuario y lo almacena en un repositorio de archivos y la base de datos. Validación: • Los administradores aprueban o deniegan las solicitudes para generar el certificado • Los certificados se generan y cumplen con el estándar X509 V3 y están firmados por la AC. Tabla 10. Historia de usuario generación de certificados para usuarios finales. Historia de usuario Número: 4 Usuario: Equipo de trabajo 1. Nombre de la historia: Consulta y verificación de certificados. Prioridad en negocio: Alta Riesgo en desarrollo: Medio Iteración asignada: 2 Programador responsable: Leonel Maye. Descripción: Función para que los usuarios puedan: • Consultar los certificados propios y de terceros en el repositorio y descargarlos • Verificar la validez de un certificado, con respecto a fecha de vencimiento, firma y revocación Validación: • Los usuarios consultan y descargan los certificados • Los usuarios verifican el estado de un certificado devolviendo si este certificado es válido o no. Tabla 11. Consulta y verificación de certificados 64 Historia de usuario Número: 5 Usuario: Equipo de trabajo Nombre de la historia: Revocación de certificados Prioridad en negocio: Alta Riesgo en desarrollo: Medio Iteración asignada: 3 Programador responsable: Leonel Maye y Álvaro Zavala. Descripción: Función para que Los usuarios finales puedan: • Solicitar la revocación de un certificado • Descargar el repositorio de certificados revocados (CRL) • Consultar los certificados revocados Los usuarios administradores puedan: • Revocar certificados con base en razones estandarizadas • Generar el repositorio de certificados revocados (CRL) • Consultar los certificados revocados Validación: • Los usuarios consultan y descargan los certificados • Los usuarios verifican el estado de un certificado devolviendo si este certificado es válido o no. Tabla 12. Revocación de certificados 5.2.3 Pila del producto Con base en las historias de usuario antes descritas, la Pila del producto es el conjunto de requerimientos funcionales y no funcionales, que debe cumplir el producto una vez entregado. No Descripción Responsable Estimación (Días) 1 Diseño de base de datos y administración de usuarios y roles Álvaro Zavala 15 65 2 Control de solicitudes de creación de certificados Álvaro Zavala 20 3 Generación de certificados para usuarios finales Leonel Maye 20 4 Consulta y verificación de certificados Leonel Maye 15 5 Revocación de certificados Leonel Maye y Álvaro Zavala 20 Tabla 13. Pila del producto para la aplicación 5.2.4 Prioridades de la Pila del producto. La estimación de prioridades de los requerimientos especificados en las historias de usuario se realizó utilizando la técnica de “Planning Poker” (para disponer de la estimación de tiempo requerido). Y en consenso con el equipo de trabajo para establecer la importancia de cada requerimiento. A continuación, se muestra en la siguiente tabla las prioridades enumeradas del 1 al 5, donde 1 es poco importante, 2 importante, 3 muy importante, 4 extrema importancia y 5 imprescindible. El orden de asignación se hace en función del requerimiento, es decir ha sido asignado en razón de la experiencia del equipo de trabajo respecto a los requerimientos presentados. Se han calificado con 5 (imprescindible), los requerimientos clave. Mientras que con 4 (extrema importancia) y 3(muy importante) a los requerimientos que tienen una escala menor de importancia. No se calificó ninguno con la calificación 1, 2 y 3, ya que ningún requerimiento está clasificado en esa escala. No Descripción Prioridad 1 Diseño de base de datos y administración de usuarios y roles 5 2 Control de solicitudes de creación de certificados 4 3 Generación de certificados para usuarios finales 5 4 Consulta y verificación de certificados 4 66 5 Revocación de certificados 5 Tabla 14. Descripción de prioridades de la Pila del producto 5.3 Fase de Desarrollo 5.3.1 Definición de las Iteraciones. A continuación, se definen las Iteraciones de cada elemento de la Pila del producto. ID Requerimiento Pila del producto Tarea de la Iteración 1 Diseño de base de datos y administración de usuarios y roles. Diseñar base de datos para la aplicación Creación y modificación de usuarios y asignación de roles. Registro de usuarios. Autenticación y autorización de usuarios Consulta de usuarios 2 Control de solicitudes de creación de certificados. Generar CSR Crear solicitud de creación de certificado Aprobar y denegar solicitudes Consultar solicitudes 3 Generación de certificados para usuarios finales. Generar y almacenar de manera segura llave privada de la AC. Descifrar llave privada para firmar certificados Generar el archivo del certificado, almacenarlo en un repositorio y la base de datos 4 Consultar y descargar certificados 67 Consulta y verificación de certificados. Verificar certificados Renovar certificados 5 Revocación de certificados. Solicitar revocar un certificado Generar CRL Descargar CRL (Punto de distribución) Revocar, suspender y modificar certificados Tabla 15. División de la Pila del producto en Iteraciones 5.3.2 Desarrollo de las Iteraciones planificadas 5.3.2.1 Iteración 1 A continuación, se presenta la Pila de la Iteración 1 que servirá para identificar las tareas en cada requerimiento que lo conforma. ID Requerimiento Pila del producto Tarea de la Iteración 1 Diseño de base de datos y administración de usuarios y roles. Diseñar base de datos para la aplicación Creación y modificación de usuarios y asignación de roles. Registro de usuarios. Autenticación y autorización de usuarios Consulta de usuarios 2 Control de solicitudes de creación de certificados. Generar CSR Crear solicitud de creación de certificado Consultar solicitudes Aprobar y denegar solicitudes Tabla 16. Pila de la Iteración 1 68 Tarea 1.1. Diseñar la base de datos para la aplicación La base de datos diseñada basada en los requerimientos de las secciones 4.4 y 4.5 de este documento es la siguiente: Fig 8. Diagrama Entidad Relación usado por la aplicación. 69 Tarea 1.2. Creación y modificación de usuarios y asignación de roles. Con base en las tablas menú, permiso, rol y usuario se creó una configuración de permisos sobre las diferentes opciones de la aplicación, para este caso se definieron tres roles: END_USER, ADMIN y SA (Super Admin). Los permisos para cada rol se describen a continuación: No. Permiso Id padre Roles 1 Perfil END_USER ADMIN SA 2 CSR END_USER ADMIN SA 3 Certificados END_USER ADMIN SA 4 CRL END_USER ADMIN SA 5 Usuarios SA 6 Mi Perfil 1 END_USER ADMIN SA 7 Cambiar Contraseña 1 END_USER ADMIN SA 8 Mis Certificados 1 END_USER 9 Crear CSR 2 END_USER 10 Solicitar certificado (CSR) 2 END_USER 11 Solicitudes pendientes (CSR) 2 ADMIN SA 12 Solicitudes enviadas (CSR) 2 END_USER 13 Historial de solicitudes (CSR) 2 ADMIN SA 14 Eliminar envío no procesado (CSR) 2 END_USER 15 Ver CSR 2 END_USER ADMIN SA 16 Aprobar o Denegar CSR 2 ADMIN SA 17 Renovar Certificado 3 END_USER 18 Descargar Certificado 3 END_USER ADMIN SA 19 Abrir Certificado 3 END_USER ADMIN SA 20 Solicitar Revocación 3 END_USER 21 Verificar Certificado 3 END_USER ADMIN SA 22 Repositorio de Certificados 3 END_USER ADMIN SA 23 Repositorio CRL 4 END_USER ADMIN SA 24 Solicitudes de revocación enviadas 4 END_USER 25 Generar CRL 4 ADMIN SA 26 Descargar CRL END_USER ADMIN SA 27 Solicitudes CRL Pendientes 4 ADMIN SA 28 Aprobar o Denegar Solicitudes CRL 4 ADMIN SA 29 Historial de solicitudes CRL Pendientes 4 ADMIN SA 30 Lista de usuarios (Modificar, Eliminar, Bloquear y Desactivar, Asignar rol) 5 SA 31 Registrar usuario 5 SA Tabla 17. Permisos asignados a cada rol. 70 Descripción de los roles • END_USER: Rol asignado a los usuarios finales de un certificado. • ADMIN: rol asignado para gestionar las operaciones de las CSR’s, Certificados y CRL. • SA: rol definido para realizar las operaciones de una ADMIN más las operaciones de gestión de usuarios. Para la creación, modificación, eliminación, bloqueo, desactivación y asignación de roles se creó el siguiente formulario: Fig 9. Formulario de registro de usuario por un SA. Tarea 1.3. Registro de usuarios. Para los usuarios finales (END_USER) se desarrolló el siguiente formulario de registro, el cual almacena las contraseñas con SHA-256 y una salt. Los usuarios y correos deben ser únicos. 71 Fig 10. Formulario de auto registro de usuarios finales. Tarea 1.4. Autenticación y autorización de usuarios Para la autenticación de usuarios se programó la siguiente interfaz, que válida también como nombre de usuario el correo registrado, adicionalmente cuenta con 5 intentos, posteriores a los cuales se pedirá un captcha, y posterior a 20 intentos el usuario se bloqueará. Fig 11. Interfaz de inicio de sesión. 72 Al iniciar sesión el usuario aterriza en la siguiente página, donde se muestra en el panel de la derecha, un menú desplegable con los permisos asignados al rol del usuario y en la esquina superior derecha se visualiza el nombre del usuario, usuario y opciones de perfil y cerrar sesión Fig 12. Página principal de la aplicación. En el caso de la autorización, esta se basa en la Tabla 15 de permisos de este documento, y para la validar tales permisos se hace uso de un filtro web de Java, una variable de sesión que almacena los permisos para el usuario logueado 73 y una variable con los permisos que no necesitan inicio de sesión, denegando aquellos permisos no asignados. El siguiente código es un extracto del filtro usado: public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { httpRequest = (HttpServletRequest) request; httpResponse = (HttpServletResponse) response; … HttpSession s = httpRequest.getSession(); String urlDenegacion = httpRequest.getContextPath()+"/no_autorizado/denegado"; String[] urlPermitidas = { "/users/sign_in", "/logout.jsp", "/users/Login", "/", "/users/activar", "/certs/download_cert", "/csr/download_privkey", "/users/reset_pass", "/users/set_newpass", "/crl/download_eSignCRL", "/css/style.css", "/js/main.js", "/certs/descargar.jsp", "/botdetectcaptcha" }; boolean isLoggedIn = (s.getAttribute("usuario") != null); try { System.out.println("URI:"+httpRequest.getRequestURI()); if (isLoggedIn){ if (httpRequest.getRequestURI().equals(urlDenegacion)) chain.doFilter(request, response); boolean go = false; List permisos = (List)s.getAttribute("permisos"); if (permisos!=null) for (Menu m: permisos){ if (httpRequest.getRequestURI().equals(m.getUrl()==null?"":httpRequest.getCo ntextPath()+m.getUrl())){ go=true; }else{ } } for (String url: urlPermitidas){ if (httpRequest.getRequestURI().equals(httpRequest.getContextPath()+url)){ go=true; } } 74 … if (go){ chain.doFilter(request, response); }else{ httpResponse.sendRedirect(urlDenegacion); } } else{ chain.doF