Repositorio Institucional de Documentos

Desarrollo de un sistema de recuento distribuido de una e-votación Antonio Martínez Jiménez Director: Joan Piles Ponente: José Luis Salazar email: [email protected] Zaragoza, Agosto de 2011 Agradecimientos: A mis padres por aguantarme tantos años, a mi hermana por enseñarme la buena vida, a los que han estado conmigo ...y estarán. “Security is not a product, but a process” Bruce Schneier. Índice 1. Introducción 1 1.1 Motivación 1 1.2 Objetivos y requisitos 1 1.3 Estructura de la memoria 2 2. Análisis 4 2.1 Diseño previo 4 2.2 Preámbulo 5 2.3 Requisitos 7 2.4 Estudio de la aplicación y su entorno 8 2.5 Cambios a realizar 10 3. Diseño del Sistema 20 3.1 Diagrama de estructura 20 3.2 Diagrama de casos de uso 21 3.3 Diagrama de estados de una votación 23 3.4 Diagrama de flujo de datos 24 3.5 Ciclo de vida del proyecto 28 4. Desarrollo, evaluación y resultados 30 4.1 Desarrollo 30 4.2 Sistema de pruebas 32 5. Conclusiones y Futuro 36 Bibliografía 38 Anexo I: Problemas encontrados 41 Anexo II: Resultado de las pruebas 45 Anexo III: Tecnologías utilizadas 55 Anexo IV: Horas invertidas y presupuesto 60 Anexo V: Sistema de copias de seguridad y sistema de almacenamiento 63 Anexo VI: Manuales de usuario e Instalación 66 Anexo VII: Estructura de la Base de datos 102 Anexo VIII: Estructura del XML 105 Índice de tablas Tabla 1: Comparativa de lenguajes 8 Tabla 2: Código Javascript para refrescar una página 15 Tabla 3: Estructura del fichero de compromisarios 18 Tabla 4: Paso de parámetros 31 Tabla 5: Establecimiento de conexión con el servlet 31 Tabla 6: Recogida de parámetros 31 Tabla 7: Sistema de pruebas de caja blanca - PRIORadmin 33 Tabla 8: Sistema de pruebas de caja negra - PRIORadmin 33 Tabla 9: Sistema de pruebas de caja blanca - generadorClaves 34 Tabla 10: Sistema de pruebas de caja negra - generadorClaves 34 Tabla 11: Sistema de pruebas de caja blanca - recuento 34 Tabla 12: Sistema de pruebas de caja negra - recuento 35 Tabla A.1: Comando para firmar un applet 44 Tabla A.2: Encode Type para utilizar FileUpload 44 Tabla A.3: Tratamiento de datos con FileUpload 44 Tabla A.4: Tratamiento de datos con FileUpload II 44 Tabla A.5 Resultados del test de caja blanca - PRIORadmin 47 Tabla A.6 Resultados del test de caja blanca - generadorClaves 50 Tabla A.7 Resultados del test de caja blanca - recuento 53 Tabla A.8 Resultados del test de caja negra - PRIORadmin 53 Tabla A.9 Resultados del test de caja negra - generadorClaves 54 Tabla A.10 Resultados del test de caja negra - recuento 54 Tabla A.11: Total de horas invertidas 61 Tabla A.12: Tabla de precios/hora 62 Tabla A.13: Precio de las horas invertidas en el software 62 Índice de figuras Imagen 1: Sistema síncrono de reunión de compromisarios 13 Imagen 2: Sistema asíncrono para la reunión de compromisarios 14 Imagen 3: Sistema final de sincronización utilizado 16 Imagen 4: Relación estructural de la tabla compromisarios 17 Imagen 5: Estructura de la base de datos 21 Imagen 6: Casos de uso del Administrador 22 Imagen 7: Casos de uso del Compromisario 22 Imagen 8: Casos de uso del Votante 23 Imagen 9: Diagrama de estados/Ciclo de vida de una votación 23 Imagen 10: DFD Nivel 0 25 Imagen 11: DFD Nivel 1 25 Imagen 12: DFD Nivel 2 - PRIORadmin 26 Imagen 13: DFD Nivel 2 - generadorClaves 27 Imagen 14: DFD Nivel 2 - recuento 27 Imagen 15: Modelo de ciclo de vida del proyecto 28 Imagen A.1: Estructura de conexiones 43 Imagen A.2: Grafo de estructura de PRIORadmin 46 Imagen A.3: Grafo de estructura de generadorClaves 48 Imagen A.4: Grafo de estructura de recuento 51 Imagen A.5: Diagrama de Gantt 61 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación 1. Introducción La democracia es el sistema de gobierno cuya soberanía reside en el pueblo. El pueblo, mediante elecciones, decide quién le gobernará. Con el desarrollo de las tecnologías de la información y la comunicación en los últimos años, se ha desarrollado un nuevo concepto en el ámbito de la política: la e-democracia. La e-democracia tiene como finalidad el acercamiento de los ciudadanos y su participación en los procesos democráticos. La edemocracia tiene un contexto muy extenso; desde el uso de las redes sociales para escuchar las opiniones de las ciudadanos hasta el uso de sistemas de votación electrónica. Este proyecto se va a centrar en el desarrollo de un sistema de voto electrónico. A partir de un sistema ya diseñado y en funcionamiento, que utiliza un sistema de clave única RSA1 se propone modificar el sistema para que se utilice un sistema de clave distribuida. Para ello, será necesario el estudio de las distintas posibilidades que ofrece la criptografía distribuida, así como modificar la estructura de datos existente para adecuarla a nuestro propósito. Será necesario a su vez el estudio y desarrollo de un sistema por el que todos los compromisarios de las votaciones puedan acceder a participar en el descifrado las votaciones. No se han puesto impedimentos en cuanto a tecnologías ni herramientas a utilizar, dejando al proyectista realizar un estudio y elegir en función del sistema a diseñar. Resumiendo, este proyecto consta de distintas fases. Primeramente será necesario hacer un estudio del sistema existente, así como una investigación de algoritmos de clave distribuida y elegir el que mejor se adapte a los requisitos. Al tratarse de un sistema distribuido, será necesario estudiar un sistema de sincronización u optar por un sistema asíncrono. Finalmente, una vez elegidos todos estos sistemas, se procederá al desarrollo de un software que se encargará de todo el proceso de votación electrónica. 1.1 Motivación Como ya se ha dicho, el desarrollo de las comunicaciones (ya no sólo físicas (móviles, tablets,...) sino también software (twitter, facebook, …)) en los últimos años está fomentando que el ciudadano esté cada vez más informado y pueda a su vez dar su opinión o mostrar sus intereses/preocupaciones en los campos que le interesen. Un campo que incumbe a todo el mundo es la política. Cada vez es mayor el interés que muestran los políticos por los medios de divulgación online y su presencia ha aumentado considerablemente gracias a las redes sociales, donde pueden escuchar a los ciudadanos y tratar con ellos directamente, siendo totalmente imposible hacer esto de otra manera. En resumidas cuentas, estamos ante un nuevo mundo lleno de posibilidades, en el que cualquier persona puede participar en las elecciones que toman los políticos sobre nuestro futuro, siempre y cuando, tenga a su alcance las herramientas necesarias. Por otro lado, los sistemas son cada vez más atacados por piratas informáticos con la intención de obtener datos sensibles que poder vender o con los que poder chantajear a las empresas; esto hace que sea necesario el diseño de un sistema robusto y la utilización de cifrados para evitar el filtrado de la información sensible. Ante estas premisas, surge la necesidad de un sistema de voto electrónico, accesible a todo el mundo y con un cifrado que ofrezca suficiente seguridad a los usuarios que lo utilicen. 1.2 Objetivos y requisitos El objetivo final de este proyecto es el desarrollo de un sistema de votación electrónica con una clave 1RSA: Sistema criptográfico de clave pública más utilizado en la actualidad; sirve tanto para cifrar como para realizar una firma digital. 1 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación distribuida que sea accesible a la mayor cantidad de personas posibles. A pesar de que los sistemas de votación electrónica ya se han puesto en uso en varios países, ha habido gran cantidad de problemas en muchos casos; desde fallos en las máquinas de votación hasta problemas de seguridad que permitían “escuchar” los votos emitidos. Partiendo de la base de un sistema de votaciones creado por Joan Piles y en funcionamiento en la actualidad, se propone la “actualización” o la creación desde cero de un sistema que cumpla los mismos requisitos. Estos requisitos incluyen, sobretodo, que sea accesible a la mayor cantidad de gente posible; y a su vez, se deben garantizar las mismas características que tendría un voto en papel. Este sistema actual utiliza para el cifrado de los votos el algoritmo RSA. Este sistema es seguro (ya que no se ha encontrado ningún algoritmo en tiempo polinómico para la factorización de enteros largos), pero el principal defecto del sistema es que la clave reside únicamente en una persona física, con lo cual, una votación podría quedar inutilizada y sería necesario volver a realizarla en caso de que únicamente una persona/computador fuese vulnerado. Así pues, la actualización que se pide es cambiar el algoritmo de cifrado por otro que sea distribuido; un sistema de cifrado de umbral (más adelante hablaremos de las mejoras que implican este tipo de algoritmos). Uno de los requisitos del sistema a implantar es el hecho de que queremos evitar que la clave secreta sea conocida; es decir, la clave secreta no debe reunirse en ninguna fase de la votación. En resumen, se va a desarrollar un software que sea capaz de generar votaciones, realizar votaciones, cifrarlas y posteriormente descifrarlas. El desarrollo de este software seguirá los pasos básicos del diseño de software: análisis, diseño, implementación, pruebas (unitarias) e integración y pruebas (de integración). En este sistema se debe incluir un sistema de cifrado umbral, por lo que se valorarán distintos tipos de cifrado y se elegirá el más apropiado. Por último, al tratarse de un sistema distribuido, será necesario implementar alguna medida de sincronización o algún sistema por el cual se pueda saber si la parte distribuida del sistema ha terminado o no. Al final del desarrollo del proyecto se presentará un software capaz de satisfacer los requisitos que se piden, así como un manual de usuario en el que se incluye la instalación y la configuración de los ordenadores para el uso de la aplicación (además del uso de la propia aplicación en sí). Se generará también un documento técnico (esta memoria) en el que se mostrarán todos los pasos que se han seguido hasta la finalización del proyecto y se explicará en detalle los pasos seguidos para cumplir los requisitos más críticos; dicho documento incluirá también información de las tecnologías y herramientas utilizadas en caso de que otra persona tenga la necesidad de diseñar una nueva funcionalidad al sistema. 1.3 Estructura de la memoria A continuación se procederá a explicar brevemente en que consisten los capítulos sucesivos de esta memoria. El primer punto que se tratará a continuación es el análisis de requisitos; se ha pedido que se añada un sistema de clave distribuida a un sistema ya en uso. Se debe realizar un estudio de las opciones que el sistema ofrece para cumplir los mismos requerimientos y tener las mismas funcionalidades. A su vez, se aprovechará este punto para averiguar cómo se realizan las operaciones y si es posible mejorarlas de alguna manera, ya que, cómo suele decirse: “El hombre inteligente aprende de sus errores; el hombre sabio aprende de los errores de otros”. Una vez extraídos los requisitos, se procederá al análisis de los mismos, para conocer las características que deberá poseer el software. Una vez realizado el análisis, en el siguiente apartado se procede a hablar del diseño del sistema; ya se sabe lo que debe hacerse y lo que tiene que cumplir, en este apartado se hablará de cómo lo hace. Se presentarán los diagramas que engloban el funcionamiento del software, así como la estructura de datos y el 2 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación ciclo de vida de una votación. El cuarto capítulo se centra en la fase de desarrollo o implementación del software. Aquí se hablará sobre las decisiones técnica: elección de lenguaje, entorno, … También será aquí donde se presenten las pruebas del sistema que se van a realizar. El último capítulo es el más personal. Aquí será donde se mostrarán las conclusiones tras haber desarrollado todo el sistema. Será aquí donde, tras volver la vista atrás, se mirará hacia el futuro y se plantearán problemas. Esta memoria cuenta también con varios anexos, donde se incluye información no relacionada con el desarrollo del sistema pero que se ha considerado oportuno incluir ya sea por su carácter didáctico o por ser información adicional necesaria para el cliente o realizar futuras mejoras. Esto incluye los resultados de las pruebas así como una descripción de las tecnologías utilizadas. Como se trata de un sistema abierto al público, se hace necesaria la inclusión de un manual de usuario para aquellos poco familiarizados con el uso de ordenadores. 3 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 2. Análisis Como ya hemos avanzado, este punto está orientado a hablar sobre los requerimientos, qué debe cumplir nuestro sistema y qué problemas puede suponer el cumplirlos. Para ello primero se analizará el software existente para extraer más información sobre las funcionalidades del mismo. También se realizará una breve descripción de las votaciones en papel, ya que el sistema a diseñar debe ser capaz de reproducirlas en la medida de lo posible (uno de los requisitos es que sea lo más general posible, lo cual implica que sea lo más accesible y que las votaciones sean lo más flexibles posible. 2.1 Diseño previo Se va a describir, sin entrar en detalles, las características del sistema de partida, indicando las herramientas que utiliza, las características más importantes en cuanto a los votos y por último, algunas de las características de la estructura de datos. 2.1.1 Aspectos técnicos En vista de que el software que se va a realizar para este proyecto tiene este sistema como punto de partida, la elección del lenguaje y plataforma serán analizados para observar si es necesaria una reestructuración completa o si basta con modificar solamente las partes que sufran cambios. •Se utiliza el lenguaje Java para la generación de código en el cliente (applets) y también para hacer los cálculos en el servidor (servlets). •Base de datos MySQL para la estructura de datos. •HTML, CSS y Javascript para las páginas web (de éste y los dos puntos anteriores se recoge que la aplicación es vía web). •Cifrado RSA clásico (una clave pública y una privada). Con esto queda definido el entorno técnico de la aplicación. 2.1.2 Aspectos estructurales La estructura de datos está plenamente almacenada en una base de datos en el servidor web. Allí se almacenan tanto las votaciones como los votantes. Las principales tablas de la base de datos son: •votaciones: En ella se almacenan las opciones de votación, así como el método de autenticación. •censos: Se almacena los votantes que puedan votar en cada votación, así como un identificador del grupo al que pertenecen (en el punto 3.1.3 se explica la utilidad de los grupos). •votos_cifrados: Se almacena el voto cifrado, una firma del mismo y la votación a la que pertenece. •votos_claro: Similar a la tabla anterior, pero el voto está sin cifrar. El resto de tablas del sistema (para la autenticación o estructuración de grupos, rondas,etc; así como otras opciones de las votaciones), pueden observarse Anexo VII. 2.1.3 Características del sistema En este punto se va a hablar de las características de la votación que ofrece el sistema: 4 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación cifrado habituales con un emisor y un receptor no sirven. Si se quiere comunicar un mensaje a varias personas a la vez, con un sistema tradicional, el primero en leer el mensaje tendrá una exclusiva hasta que el resto lo lean o incluso habrá que cifrarlo varias veces, uno para cada receptor. Además, con los sistemas tradicionales, la clave privada es única y un simple ataque puede desarticular todo el sistema de cifrado volviéndolo inseguro. Así es como nacen los sistemas de cifrado umbral, que, como su nombre indica, se basa en cifrar/descifrar cuando se ha llegado a un umbral. Este tipo de sistemas se basa en no tener una única clave (descrito por [Sha79]), sino en tener varias claves que juntas se encarguen del descifrado de los mensajes. El mensaje se cifra con una clave pública (como es habitual), pero la clave secreta correspondiente está distribuida entre distintas personas. Así pues, si el número de partes es n, se denominará un sistema de umbral (k, n) a aquel que necesite k partes de las n para descifrar el mensaje original. Se han propuesto varias versiones umbral para distintos esquemas criptográficos, por ser en los que más se ha trabajado nuestra decisión estará entre RSA y El-Gamal. En cuestiones de seguridad, tanto RSA como El-Gamal se pueden considerar seguros. RSA ofrece seguridad en tanto que no se puedan factorizar enteros en tiempo polinómico; El-Gamal, por su parte, utiliza logaritmos discretos, que en la actualidad tiene un costo de computación subexponencial. Existen varios estudios realizados para la distribución de una clave secreta entre n compromisarios. No obstante, lo que se busca en este proyecto es que no exista una clave privada que sea almacenada o utilizada para generar el resto, sino que a partir de varias claves, se generen la clave privada y las participaciones de la clave secreta. Para ello se seguirá el algoritmo descrito por [Ped91], que permite una distribución de este tipo para el algoritmo de El-Gamal [EG95]. Los pasos para la distribución de claves según Pedersen adaptados ya a nuestro sistema serían: 1) Se necesitan dos primos grandes, p y q, tales que q divide a p – 1. 2) Generar g, tal que g Є Gq. g ε Gq <==> gq = 1 (mod p) 3) Pi (el compromisario i) elige aleatoriamente xi Є Zq y calcula hi = gxi. 4) El servidor recoge los hi y calcula h mod p. h = Πn i= 1 hi (mod p) Nota: Ahora se tiene acceso a la clave pública, pero para acceder a la clave secreta: x = Σni=1 xi (mod q) es necesario que todos los compromisarios trabajen juntos. 5) Pi elige un polinomio al azar tal que fi(z) Є Zq(z) de grado k – 1 y tal que fi(0) = xi mod q. fi(z) = fi0 + fi1z + … + fi,k-1zk-1 6) Pi manda sij = fi(j) a cada Pj (en nuestro sistema, para evitar comunicación entre compromisarios, todo estará centralizado y se mandará al servidor central, que será el encargado de distribuirlos a los Pj) para j = 1, …, n y guarda para sí sii. 7) Cada Pi calcula su participación si como: si = Σnj=1 sji (mod q) 11 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Este algoritmo permite que cada compromisario tendrá su participación de manera secreta y la generación de una clave pública sin conocer la clave secreta. Para el cifrado de datos, no habrá que hacer ningún cambio en el algoritmo de El-Gamal original, puesto que la clave pública sigue siendo única. El resultado del cifrado El-Gamal: C(m) = (a, b) A la hora de realizar el descifrado, sigue vigente la norma de que no debe reunirse la clave secreta, por lo que se deberá trabajar con descifrados parciales. El descifrado El-Gamal se realiza como sigue: Donde: M = mensaje descifrado b = 2ª parte de la tupla del cifrado a = 1ª parte de la tupla del cifrado x = clave secreta No obstante, no podemos reunir la clave secreta, pero sí que podemos hacer: siendo cada una de las xi las claves parciales de los compromisarios. Éstas claves parciales dependerán de los compromisarios que se hayan reunido (no es lo mismo que se reúnan los compromisarios 1 y 2 que los compromisarios 1 y 3) y para calcularlas será necesario realizar una interpolación de Lagrange ([Lee2003] y [Pab04]). Con este cambio en el sistema de cifrado, tendremos que hacer varios cambios en la estructura de la base de datos. Los números q y g (módulo y generador) son necesarios tanto para la generación de participaciones como para el cifrado (y descifrado) de datos, por lo que es necesario almacenarlo en la base de datos. También es necesario añadir a nuestra estructura los parámetros del umbral (k y n). Se necesita a su vez tener un registro de los compromisarios de cada votación, por lo que estos nuevos datos se tendrán que incluir en la base de datos. Para ello crearemos una nueva tabla en la que se refleje qué compromisarios pertenecen a cada votación y cuantas participaciones (o partes) de la clave privada poseen. Además de eso, el módulo PRIORadmin, tendrá que ser enteramente reconstruido, ya que con este sistema son necesarias la inclusión de nuevos parámetros a la hora de crear una votación, que también pueden ser modificados posteriormente si fuese necesario. El módulo PRIORrecuento también queda inutilizado pues el método de descifrado también cambia por completo. Será necesario aquí implantar una medida de sincronización entre los compromisarios (punto 2.5.2). Por último, será necesaria la creación de un nuevo módulo, que genere las claves privadas y la pública. 12 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación 2.5.2 Sincronización de compromisarios Estamos ante un sistema distribuido y por ello, cada compromisario puede acceder a nuestro sistema cuando quiera. Para la creación de la clave pública es necesario que los n compromisarios de una votación estén presentes a la vez o asegurarnos de alguna manera de que todos se han conectado y generado su parte de la clave. Por un lado, si permitimos que un compromisario conecte cuando quiera, generará su Ski (partición de la clave privada) y su correspondiente hi (parte de la clave pública). Podría almacenarse este hi a la espera de recibir el resto de hj, pero esto supondría dos problemas: •Podría darse el caso de que alguno de los compromisarios no se conectase nunca, dejando información inútil en la base de datos •El compromisario no sabría si la clave pública ha sido generada. Por estas razones se va a optar por obligar a los n compromisarios a conectarse todos al mismo tiempo. En este caso podemos diseñar tanto un sistema síncrono como uno asíncrono. Un sistema síncrono sería un sistema totalmente automático, en el que todo se produjese a la vez, es decir, se espera a que todos los compromisarios estén conectados al servidor y mediante una señal síncrona enviada por el servidor, comienza el proceso de generación de claves. Algo así: Imagen 1: Sistema síncrono de reunión de compromisarios Por contra, un sistema asíncrono es un sistema en el que hasta que no recibe el servidor una petición por parte de uno de los compromisarios, no le dice que empiece. Podríamos empezar desde el primer intento de conexión por parte de un compromisario o esperar a haber recibido peticiones de los n compromisarios para mandar la primera señal de “Begin”: 13 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Imagen 2: Sistema asíncrono para la reunión de compromisarios Para este sistema se deben tener en cuenta las siguientes consideraciones: •Deben estar conectados todos los compromisarios. •No se puede obligar a los compromisarios a estar continuamente actualizando su navegador a la espera de reunir a los compromisarios. •Se debe verificar que el compromisario está “on” en su ordenador para verificar que sabe si la creación de claves ha sido exitosa o no. Además, puede darse el caso de que si todo es automático, un fallo en la red o en el ordenador (fallo de electricidad) supondría que el compromisario no conoce el resultado de la operación. Por estos motivos, la automatización de todo el sistema no es una opción válida para nuestros intereses. El principal problema de los sistemas síncronos es que se quedan bloqueados hasta que se recibe una respuesta del receptor. El hecho de reunir a los compromisarios puede tener una gran longitud temporal, por lo que sería necesario establecer un “timeout”10 alto; esto puede llegar a suponer un problema cuando se pierda la conexión entre el compromisario y el servidor. El sistema asíncrono, en cambio, tiene la desventaja de que es necesario que todos los compromisarios estén intentando establecer conexión cada poco tiempo para acceder al sistema y que la generación de las claves sea exitosa. Por lo cual, ninguna de los dos sistemas se adecua a nuestras necesidades, así que se propone lo siguiente: 1) Para la reunión de compromisarios se creará un sistema asíncrono que simule ser síncrono. Es decir, aprovechando que el sistema que se utiliza es web, se puede activar la opción de autorefresh e/o introducir un código javascript que actualice la página hasta que los compromisarios estén reunidos. El código sería el siguiente: 10 Timeout: Indicador de tiempo máximo que debe esperar un proceso para conectarse antes de abortar una tarea. Un timeout demasiado pequeño puede hacer suponer que se haya perdido conexión cuando realmente no ha sido así; por el contrario, un timeout excesivamente alto, puede hacer que el servidor espere un compromisario con el que se ha perdido contacto. 14 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación <script language='javascript'> setInterval('location.reload();', "60000"); </script> Tabla 2: Código Javascript para refrescar una página 2) El servidor, al recibir las peticiones periódicamente, puede, de esta manera, llevar la cuenta de los compromisarios conectados en cada momento y así las posibilidades de empezar a generar las claves para posteriormente tener que anular la creación de claves se minimiza. 3) Una vez reunidos todos los compromisarios, se iniciará la aplicación generador de claves, pero hasta que el usuario no acepte la operación no comenzará la ejecución. 4) Una vez finalizada la operación, se enviarán las hi al servidor y el navegador ejecutará un script similar para conocer el resultado de la operación. 5) El servidor a su vez, una vez reunidos todos los compromisarios, lanzará un timeout para saber si todos han finalizado correctamente. En caso de que alguno de los compromisarios envíe su hi fuera de tiempo, se detectará como enviado fuera de tiempo y el hi será ignorado. Si ha recibido todas las particiones, generará la clave pública. 15 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Imagen 3: Sistema final de sincronización utilizado Por lo tanto, con un protocolo de sincronización como el previo se consigue un control casi total por parte del servidor, evitándose que se generen claves innecesarias (salvo en el caso de que uno de los compromisarios falle en el transcurso de la generación de su clave) y se cumplen todos los requerimientos solicitados. Por otra parte, para el descifrado de las votaciones, el proceso será similar, pero en vez de hacer los cálculos sobre n, se harán sobre k. 2.5.3 Cambios en la estructura de datos El sistema de votaciones va a cambiar; a pesar de que el cambio que se produzca será transparente para el usuario, tanto para los compromisarios como para los administradores de las votaciones, la manera de hacer su trabajo será distinta. El administrador tendrá que facilitar más datos a la hora de crear la votación ya que al cambiar el algoritmo de cifrado y pasar a un algoritmo de umbral en lugar de un sistema habitual de clave pública-privada serán nuevas variables a almacenar. 16 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación A los compromisarios sólo les afectará de cara al interfaz; anteriormente había un único compromisario que era quien se encargaba del descifrado; en el sistema que se va a implantar, al ser varios, tendrá que esperar a que se reúnan todos, pero esto no afecta a la estructura de datos. En cambio, el hecho de introducir varios compromisarios en el sistema sí que afecta al almacenamiento de información (y por tanto a la estructura de datos), ya que es necesario almacenar los compromisarios de cada votación: Imagen 4: Relación estructural de la tabla compromisarios Un compromisario puede serlo de 1 a n votaciones; a su vez, una votación puede tener de 1 a m compromisarios. Los campos de esta nueva tabla serán. •userID: varchar. Primary Key. Es el identificador de nuestro compromisario. Podría ser el DNI o un nick. •IDvotacion: integer. Primary Key. Este campo es el ID de la votación de la cual será compromisario. Es una clave primaria conjunta. •password: varchar. Puede ser nulo. Será un hash de la contraseña. •numParticiones: integer. No puede ser nulo. Será el número de participaciones de la clave secreta que posee un compromisario. Se ha permitido que un compromisario tenga más de una participación. Se deja que sean los administradores de las votaciones quienes gestionen ésto. Los cambios más importantes en la tabla de votaciones son: •k: integer. No nulo. Es el número k mínimo de compromisarios para descifrar la votación. •n: integer. No nulo. Es el número n de participaciones. •PuKey: varchar. Puede ser nulo. Será la clave pública. Se almacena como varchar. Se permite que sea nulo porque en el momento de la creación de la votación aun no se habrán reunido los compromisarios para crear las claves. •p, q, g: varchar. No pueden ser nulos. Estos tres campos son necesarios para la generación de claves y el posterior cifrado y descifrado. Son públicos y pueden ser almacenados. •length: integer. No nulo. Será la longitud de la clave; es necesario guardarla para poder informar a los compromisarios de la longitud de la clave a crear. •timeoutreunir, timeoutdescifrar: integer. No nulo. Como su propio nombre indica, son los timeouts para reunir la clave pública y para descifrar la votación. Estos timeouts serán introducidos por el administrador de la votación, lo cual, aunque libra a los administradores del sistema de culpa, es posible que el administrador de la votación peque por exceso o por defecto con estos tiempos, con lo que eso conlleva. Por último, se ha realizado una última modificación en la estructura de datos. En este caso referente al cifrado de las votaciones. En el antiguo sistema se utilizaba, como ya se ha mencionado, un cifrado RSA, el cual hace una transformación: C(m) → m' es decir, devuelve en un solo bloque el mensaje cifrado. En cambio, con el cifrado El-Gamal: 17 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación C(m) → (a, b) el cifrado se convierte en una tupla (a, b) con el cifrado dividido en dos. Podría optarse por dejar la base de datos tal y como está y almacenar ambas partes juntas, separadas por algún carácter no numérico, o bien crear dos campos en la base de datos. No obstante, como para realizar el descifrado parcial sólo es necesaria la parte “a” del mensaje cifrado, no es necesario obtener la tupla entera de la base de datos y luego separarla. En costes de eficiencia, es mejor guardarla en dos campos separados, por lo que a la tabla “votos_cifrados” habrá que añadir el campo: •voto_cifrado_b: blob. Que representará la parte “b” de la tupla. 2.5.4 Módulo PRIORadmin Como ya hemos introducido anteriormente, el hecho de cambiar una votación con un único compromisario a n compromisarios implica un cambio en los datos a introducir para crear una votación (y por tanto, también hay que poder modificarla). Los nuevos parámetros a introducir serán: •El número n de compromisarios. •El número k, factor de reconstrucción. •La longitud de la clave. Se le darán varias opciones a elegir, desde una sencilla contraseña de longitud 1024 hasta 4096 (esto podría ser fácilmente ampliable). •Los timeout. Aunque el administrador de las votaciones no tiene por que entender este concepto, no es tampoco labor de los administradores decidir el tiempo que se dará para el cálculo de claves y descifrados. La unidad del timeout son segundos. •Los compromisarios de la votación. Para esto, se utilizará un proceso similar al que se utiliza para recoger a los votantes. Se le pedirá al administrador que guarde en un fichero los datos de los compromisarios de la siguiente manera: Identificador Participaciones MD5(password) Tabla 3: Estructura del fichero de compromisarios El identificador, como hemos indicado antes puede ser tanto un nick, como el DNI, etc Debe ser único, ya que dos personas con un mismo identificador tendría acceso el uno a las votaciones del otro (obviamente, si alguien es compromisario de dos o más votaciones, se debe introducir el mismo identificador y en el menú le aparecerán todas las votaciones posibles). El password, por su parte, pedimos que se suba el MD5 del mismo para que los administradores del sistema no tengan acceso a las contraseñas en claro. Por último, respecto al número de participaciones, no se imponen restricciones, a excepción de que el número de participaciones totales debe ser igual al número n facilitado anteriormente. Eso serían los cambios externos (de cara a los usuarios del sistema) que se visualizarán. Internamente, los cambios a realizar incluyen todas las comprobaciones pertinentes: 1) k y n deben ser positivos, con k ≤ n. 2) La suma de participaciones del fichero de compromisarios debe coincidir con n. 3) La longitud de la clave es un entero positivo. 4) Los timeouts deben ser positivos. Por otro lado, una vez hechas estas comprobaciones, se procederá a generar los número g, p y q de acuerdo a lo descrito en el apartado 2.5.1 18 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Para más detalles sobre el diseño, tanto de este módulo como de los siguientes, consultar los puntos 3.2, 3.3 y 3.4. 2.5.5 Módulo PRIORrecuento Este módulo queda totalmente inútil. En el modelo antiguo, su única función era loguear al compromisario y éste solicitaba al servidor los votos cifrados para hacer el descifrado con su clave secreta, guardada en un archivo. El módulo actual, al autenticar al compromisario y tras haber elegido la votación a descifrar, realiza un mecanismo de sincronización similar al descrito en el punto 2.5.2 (con la salvedad de que en este proceso de la votación hay que esperar la reunión de k participaciones en vez de las n. Posteriormente se pide al usuario que introduzca la ruta en la que tiene almacenada/s su/s partición/es y se procede a realizar un descifrado parcial que será enviado al servidor, que, una vez reunidas las k particiones, procederá al descifrado. Para distinguir el módulo antiguo del que se va a implantar con el sistema actual, se realizará un cambio en el nombre del módulo que realiza el recuento. 2.5.6 Módulo generadorClaves Este módulo, inexistente en el sistema previo, se encarga de autenticar y sincronizar a los compromisarios tal y como se describe en el punto 2.5.2. Una vez reunidos los compromisarios, se ejecutan los algoritmos vistos en el punto 2.5.1 para el reparto de claves. 2.5.7 Módulo PRIOR El módulo PRIOR es el módulo encargado de realizar los votos. Se encarga de identificar a los votantes, gestionar las opciones de votación y emitir el voto. En su funcionamiento actual, sólo se encarga de realizar cifrado en las votaciones mediante el uso de DNIe, así que el módulo ha sido modificado para cifrar los tres tipos de votaciones, añadiendo el cifrado a las votaciones abiertas y con autenticación por base de datos y modificando el modo de votación (RSA en el sistema antiguo) por el algoritmo que se utiliza actualmente. Aparte de esto, se incluirá una firma hash para las votaciones de tipo “abierta” y “base de datos”, ya que las votaciones por DNIe incluyen firma propia. Este módulo no ha sufrido más cambios y los cambios a realizar no suponen un cambio de su diseño y/o estructura. 2.5.8 Cifrado de participaciones Cada compromisario tiene una participación. Esta participación debe guardarse en un lugar seguro. Obviamente, no podemos obligar a un compromisario a acceder siempre desde el mismo ordenador, por lo que es necesario que el propio compromisario tenga acceso a estas participaciones para poder disponer de ellas cuando sea necesario. Esto hace que sea necesario guardar las participaciones en un archivo que conozca el compromisario. No obstante, una mala decisión sería llamar siempre a las participaciones con el mismo nombre, ya que un compromisario puede tener participaciones de más de una votación. Es por ello que a la hora de generar las participaciones se ofrece al usuario la opción de elegir una ruta y nombre de archivo para guardar la participación de la votación. Además de esto, las participaciones son parte de la clave secreta, por lo que hay que hacer especial hincapié en su seguridad. Para ello se cifra el archivo mediante al algoritmo AES (también conocido como Rijndael) con una longitud de clave de 128 bits, el cual se considera seguro. 19 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 3. Diseño del sistema En el punto anterior se han visto los requerimientos del sistema a implantar. Esto es lo que se denomina análisis del sistema a diseñar, lo cual incluye el análisis de requisitos y el estudio de las distintas opciones. Una vez que ya se ha especificado qué se debe hacer, en este punto se procede a indicar cómo debe hacerse. Existen en la actualidad gran cantidad de diagramas diferentes para el modelado de sistemas. Muchos están directamente orientados a sistemas no web, mientras que otros quedan muy lejos de nuestra aproximación. UML (Unified Modeling Language) es el estándar más seguido en el campo de la ingeniería de sistemas para el diseño de software. UML contempla gran cantidad de diagramas que se pueden separar en tres categorías: 1. Diagrama de estructura. Cómo su nombre indica, refleja la estructura del sistema; la información presente. En este caso, la estructura del sistema, el esqueleto que da forma a la aplicación es la base de datos. Para nuestro sistema, se hará un diagrama de estructura de la base de datos. 2. Diagrama de comportamiento. Estos diagramas sirven para enfatizar como se comporta el sistema desarrollado. Suelen utilizarse para describir las funcionalidades del software. Para satisfacer este tipo de diagramas se presentarán los casos de uso de la aplicación. 3. Diagramas de interacción. Este tipo de diagramas se utiliza para mostrar el control del sistema y el flujo de la información. Para nuestro software se ha considerado oportuno realizar un diagrama de flujo de datos de la aplicación, así como un diagrama de estados por los que pasa una votación (para que quede claro el funcionamiento de las votaciones). Para hacer un reflejo claro del sistema que se pretende diseñar, se ha pensado que era necesario al menos: •Diagrama de estructura •Diagrama de casos de uso •Diagrama de estados de una votación •Diagrama de flujo de datos Por último, el punto final de este capítulo será para el ciclo de vida del proyecto. 3.1 Diagrama de estructura Este proyecto web está basado en módulos independientes. La estructura que está detrás de estos módulos independientes es la base de datos en la que se refleja toda la información y a la que acceden y modifican estos módulos. La base de datos es el esqueleto que da forma a la aplicación web, relacionando unos módulos con otros. 20 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Imagen 13: DFD Nivel 2 - generadorClaves Al igual que en el diagrama anterior, el estado 2.6 hace referencia a la salida, sea un error o un simplemente un mensaje de que todo ha sido correcto. Los “Datos generación Skj” son los datos que genera el compromisario i para el resto de compromisarios. Los “datos generar Ski” son los datos que han generado el resto de compromisarios para generar la participación de i. La parte de sincronización entre compromisarios corresponde al estado 2.2, mientras que el 2.3 correspondería a la ejecución de un applet de Java en la máquina del cliente, ejecución que continúa en los estados 2.4 y 2.5. Imagen 14: DFD Nivel 2 - recuento 27 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 3.5 Ciclo de vida del proyecto Todo software tiene un ciclo de vida; desde el comienzo del análisis hasta su retirada del mercado/sistema. Más concretamente, este punto se va a centrar en el Ciclo de vida del desarrollo de este software; el posterior mantenimiento y actualizaciones quedan fueran del ámbito del proyecto. Existen una gran cantidad de metodologías para el desarrollo de software, desde el método clásico hasta algunos más complejos como podrían ser el espiral o el incremental. La finalidad de este punto no es hacer un estudio sobre las ventajas y desventajas de estos modelos, por lo que a continuación se va a indicar el modelo elegido para este proyecto y los motivos por los que se ha elegido. El método elegido para el desarrollo de este proyecto ha sido un desarrollado en cascada mejorado. Imagen 15: Modelo de ciclo de vida del proyecto El modelo en cascada es el más utilizado dada su sencillez, puesto que es una visión del desarrollo de software por etapas. El modelo en cascada es iterativo y no admite ciclos, por lo que los requisitos se fijan al principio del proyecto y no se permite cambiarlos. Es por esto por lo que surgió el modelo en cascada mejorado, que se ve en la imagen anterior. Como puede observarse, este modelo sí que admite ciclos, permitiendo pasar de una etapa final a una anterior para que el proyecto pueda ser modificado. Así pues, con esta realimentación entre fases evitamos en gran medida el principal defecto del desarrollo en cascada. Con este modelo, se permite también el tener un software que se pueda enseñar al cliente y si se exige alguna modificación, volver a una etapa más temprana del desarrollo y realizar dicha modificación. Los principales inconvenientes de este modelo son que de cara a proyectos de gran envergadura, la revisión puede ser larga, laboriosa e incluso compleja; obviamente, este proyecto no es un proyecto de tal magnitud, por lo que este inconveniente no nos concierne y para una revisión se adapta perfectamente a nuestras necesidades. La libertad que ofrece este modelo de poder realimentar fases tempranas una vez el proyecto esté avanzado no supone sólo una ventaja, sino que puede convertirse en un inconveniente si el cliente no tiene una idea clara de lo que quiere/necesita o si, con cada prototipo cambia algún detalle; cambiar cada uno de estos detalles supone una vuelta a las fases de análisis o diseño, con lo que supone modificar las fases siguientes y repetir todas las pruebas, haciendo que el proyecto pueda alargarse más de lo esperado. Por otro lado, ya se han comentado algunas de las ventajas que posee este modelo. Otra de las principales ventajas que ofrece el modelo es su secuenciación; a pesar de que esto no siempre se considera una ventaja; el hecho de separar las fases de análisis y diseño permite que se documenten por separado (lo mismo se aplica a la implementación y a las pruebas) por lo que de cara a futuras revisiones, el proyecto 28 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación estará bien documentado y permitirá que las modificaciones sean más sencillas. Este modelo es a su vez fácil de entender por personas no versadas en el desarrollo de software, por lo que se le puede mostrar al cliente y explicarle cuando podrá ver resultados. Por último, su sencillez a la hora de implantar el modelo permite que se utilice el tiempo que se tardarían en implantar otros modelos al propio desarrollo del proyecto. Todos estos motivos son los que han impulsado a seguir este modelo, sencillo pero práctico, para la realización de este software. 29 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 4. Desarrollo, evaluación y resultados Este capítulo se centra en las fases intermedias del modelo en cascada: implementación y pruebas. En el primer punto se hablará más técnicamente del proyecto, centrándose en bibliotecas utilizadas durante la implementación, comunicación cliente-servidor y lenguajes utilizados. El segundo punto presentará el sistema de pruebas que se ha seguido, no así los resultados, que deberán consultarse en el Anexo II. 4.1 Desarrollo Se ha explicado ya en el diseño con bastante nivel de detalle qué va a realizarse en los módulos. En este punto se van a comentar los aspectos técnicos más relevantes del proyecto, así como algunas decisiones de carácter técnico. En uno de los apartados se hablará de los lenguajes utilizados, pero será solamente una breve introducción; para más detalle a este respecto, consultar el Anexo III. 4.1.1 Bibliotecas En este apartado se van a mencionar las bibliotecas utilizadas que hayan tenido un papel más importante en el desarrollo del proyecto o bien aquellas cuya funcionalidad sea específica. •Mysql-connector: Java necesita siempre de drivers para conectarse a las bases de datos. En este proyecto se utiliza una base MySQL, por lo que se necesita este tipo de conector. Se utiliza JDBC para conectar con la base de datos por su sencillez frente a ODBC. •FileUpload: Para el paso de los censos y de los compromisarios se utiliza un fichero como se ha indicado en el punto 3. Para ello se ha utilizado este package, el cual permite subir ficheros al servidor y tratarlos. •BiSlider: Este package es utilizado en PRIORapplet para el tratado y el dibujado de valores entre dos rangos. •Jama: Ésta es una librería matemática, está centrada en el álgebra y es muy utilizada para la construcción y manipulación de matrices. En la bibliografía se puede encontrar más información sobre estas bibliotecas. 4.1.2 Cliente-servidor Existen muchas maneras de implementar una comunicación en una arquitectura cliente-servidor. Desde un sencillo socket11 hasta conexiones de streaming. Al estar centrando todo el sistema en torno al web, se decidió que lo más apropiado era utilizar las herramientas que ofrece HTTP12 para el flujo de datos, ya que HTTP permite el envío de datos además de las peticiones. Para el paso de parámetros por HTTP existen los métodos GET y POST. La gran mayoría usa POST puesto que ofrece muchas más ventajas; en este proyecto se va a utilizar porque se pretende pasar una gran cantidad de información y GET tiene un límite de información para servir mientras que POST no. Para el paso de parámetros, se construye una cadena de caracteres, en el que se indica el nombre que se le da al parámetro, seguido del signo igual y el valor del mismo; los parámetros se separan por el carácter 11 Socket designa un concepto abstracto por el cual dos programas pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada. 12 Hypertext Transfer Protocol o HTTP es el protocolo usado en cada transacción de la World Wide Web. Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. 30 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación '&'. Un ejemplo de este tipo de cadenas sería: user=administrador&id=357&publica=124163436.... Tabla 4: Paso de parámetros A la hora de efectuar la conexión, el código sería: URL url = new URL(“http://www.ejemplo.com”); URLConnection conn = url.openConnection(); conn.setDoOutput(true); conn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream()); wr.write(datos); Tabla 5: Establecimiento de conexión con el servlet Se abre una conexión con la URL deseada; se informa que va a haber salida de datos, el formato de codificación y por último, en una variable de tipo OutputStream se vuelcan los datos. “datos” obviamente, es una variable de tipo String en la que están los parámetros que queremos pasar. En nuestro caso, la URL será la de un servlet. Esta petición, llegará a un servlet, que procesará la petición. Para obtener los datos, basta con hacer: String usuario =request.getParameter(“user”); Tabla 6: Recogida de parámetros siendo “user” uno de los campos de la cadena recibida. 4.1.3 Lenguajes En este proyecto se han utilizado varios lenguajes; por un lado aquellos necesarios para la visualización de páginas web, los denominados lenguajes de lado cliente. Por el otro, para generar webs dinámicas y realizar operaciones en el servidor se necesita un lenguaje de lado servidor. Las características del lado servidor se han mencionado ya en la fase de diseño, informando de que iba a ser Java el lenguaje a utilizar para este propósito. No obstante, no se ha explicado claramente la función de los servlets y su funcionamiento. Los servlets son programas residentes en el servidos; archivos .class compilados que esperan a ser llamados para ejecutar su código. Estas llamadas se ejecutan desde el cliente y se permite el paso de parámetros por GET y POST. El uso de servlets va ligado al código jsp, que permite la generación de código Java a través de scripts en documentos HTML. De esta manera, las páginas webs generadas para el proyecto han sido escritas en formato jsp. Se utiliza el código Java para generar webs dinámicas, haciendo las comprobaciones pertinentes y lanzando consultas SQL y la información se presenta en formato HTML. HTML es un lenguaje descriptivo que permite estructurar y dotar de información y contenidos a una página web. Su estructura se basa en etiquetas de comienzo y fin (<HTML></HTML>) que dotan de alguna característica a la información que contienen. Admite también la escritura de texto y la inserción de imágenes. No obstante, al tratarse de un lenguaje descriptivo, no posee dinamismo y es muy limitado. 31 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Es recomendado en ámbitos web la separación de la estructura y los estilos. Esta separación hace que los cambios en la estructura no afecten a la unidad de la página web y viceversa. Esta separación se realiza mediante el uso de hojas de estilo CSS13 las cuales muestran, dada una etiqueta o tipo las características de color, tamaño,... Estas hojas de estilo ahorran la repetición de código, facilitan la comprensión del código HTML y permite alternar entre distintas hojas de estilo si se necesitase. Por último, para dotar de dinamismo a las páginas webs, en ciertos aspectos ha sido necesaria la inclusión de código Javascript, lenguaje interpretado por los navegadores webs. La función es este lenguaje es esa, dotar de dinamismo a las páginas webs y permite el acceso a variables del navegador y del sistema operativo, aunque estas no se han utilizado en este proyecto. 4.1.4 Cifrado Java posee una biblioteca propia para operaciones de cifrado. Ofrece varios cifrados así como distintas opciones de padding (relleno) para los cifrados. No obstante, el cifrado El-Gamal no está contemplado en esta biblioteca. No obstante, existe la biblioteca bouncy-castle, una biblioteca abierta que complementa los defectos de la biblioteca Cipher de Java. Por otro lado, la configuración por defecto de Java sólo permite claves de una longitud de 128 bits. Esto es debido a que en algunos países esta es la longitud máxima de cifrado establecida por la ley. Esta longitud es irrisoria a día de hoy y por ello Java ofrece nuevos archivos con políticas distintas que permiten eliminar esta restricción. No obstante, a pesar de encontrar estas soluciones, el cifrado que ofrece bouncy-castle sólo es utilizable para el cifrado El-Gamal clásico y no sirve para nuestro caso en el que tenemos varias participaciones, ya que al realizar los descifrados parciales, el resultado obtenido sería: y al intentar eliminar esta cantidad sobrante, el resultado que se obtiene sería incorrecto debido al padding que se le añade. Por estas razones, se ha optado por realizar una implementación manual del cifrado, añadiendo un padding aleatorio para cada voto. El descifrado también se realizada de manera manual. A la hora de descifrar sólo se pasa al compromisario la parte “a” del voto, preservando la parte “b” en el servidor (lo cual hace todavía más complejo el descifrado por parte de un tercero del voto). 4.2 Sistema de pruebas Las pruebas son uno de los puntos más importantes en el desarrollo de software. Siendo como es que se trata de un sistema orientado a web, accesible a todo el mundo, las pruebas toman un carácter aún más importante si cabe. Las pruebas deben asegurarse no sólo de que todo funcione correctamente, si no de que no haya funcionalidades erróneas; es decir, un uso del software orientado a su mal funcionamiento intentando obtener información del sistema. La mayoría de los ataques web suelen ser de esta manera, buscando cadenas de caracteres erróneas que muestren información. Es por ello por lo que se propone el siguiente plan de pruebas: •Un sistema de caja blanca, que se encargue de realizar pruebas estructurales para la verificación del correcto funcionamiento. 13 Cascading Style Sheets (o CSS) es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML. 32 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación •Un sistema de caja negra que verifique la entrada/salida de datos Antes de continuar, se quiere aclarar que la prueba exhaustiva es imposible. No se puede exponer un sistema a todas las situaciones posibles desde ningún punto de vista, ya sea humano, económico o matemático. Se realizarán pruebas unitarias; de cada uno de los 3 módulos por separado y cuando todo el software esté terminado, se harán pruebas de integración para verificar el correcto funcionamiento del sistema en su conjunto. Cabe destacar que es necesaria una cierta secuencia en la realización de las pruebas unitarias de los módulos; es decir, no se podrá hacer un recuento con las participaciones si antes no se ha implementado y probado la creación de particiones. A continuación se muestran los Planes de prueba que se van a seguir. Habrá dos por módulo, uno orientado a las pruebas de caja blanca y otro a las pruebas de caja negra; se hace esto para un mejor seguimiento de las mismas. El Plan de pruebas incluye una descripción de las pruebas a realizar, el número de repeticiones que se efectuará la prueba y el entorno de ejecución. Nombre PRIORadmin – Caja blanca Descripción Se someterá al módulo PRIORadmin a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Repeticiones 50 Autor Antonio Martínez Tabla 7: Sistema de pruebas de caja blanca - PRIORadmin Nombre PRIORadmin – Caja negra Descripción Se someterá al módulo PRIORadmin a una serie de pruebas de entrada salida. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará el resultado con todos los datos válidos. Posteriormente, se ejecutarán pruebas con datos inválidos. Cada vez un dato distinto o en grupos de dos. Repeticiones 100 Autor Antonio Martínez Tabla 8: Sistema de pruebas de caja negra - PRIORadmin 33 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Nombre generadorClaves – Caja blanca Descripción Se someterá al módulo generadorClaves a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Se probarán también fallos en la red para observar el funcionamiento del sistema Repeticiones 50 Autor Antonio Martínez Tabla 9: Sistema de pruebas de caja blanca - generadorClaves Nombre generadorClaves – Caja negra Descripción Se someterá al módulo generadorClaves a una serie de pruebas de entrada salida. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará el resultado con todos los datos válidos. Posteriormente, se ejecutarán pruebas con datos inválidos. Cada vez un dato distinto o en grupos de dos. Repeticiones 100 Autor Antonio Martínez Tabla 10: Sistema de pruebas de caja negra - generadorClaves Nombre recuento – Caja blanca Descripción Se someterá al módulo recuento a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Se probarán también fallos en la red para observar el funcionamiento del sistema Repeticiones 50 Autor Antonio Martínez Tabla 11: Sistema de pruebas de caja blanca - recuento 34 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Nombre recuento – Caja negra Descripción Se someterá al módulo recuento a una serie de pruebas de entrada salida. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará el resultado con todos los datos válidos. Posteriormente, se ejecutarán pruebas con datos inválidos. Cada vez un dato distinto o en grupos de dos. Repeticiones 100 Autor Antonio Martínez Tabla 12: Sistema de pruebas de caja negra - recuento 35 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 5. Conclusiones y trabajo futuro Hasta aquí se ha visto como se ha desarrollado el proyecto. Ahora es tiempo de hacer una retrospectiva y valorar, tanto en el ámbito del proyecto como fuera de él, que ventajas ha aportado, no sólo a la comunidad informática, sino qué beneficios he obtenido yo como desarrollador del mismo. Primeramente, ¿se han cumplido los objetivos impuestos? He desarrollado un sistema de votación electrónica con un cifrado El-Gamal distribuido. Además, se ha desarrollado de tal forma que la clave secreta no es conocida en ningún momento. Para ello ha sido necesario desarrollar un sistema de sincronización para asegurar la implicación de los k o n compromisarios necesarios para el cifrado umbral. Las participaciones de los compromisarios se guardan cifradas de manera que no pueden ser leídas fácilmente por un usuario malicioso. Además, el programa ha sido desarrollado de tal manera que la manipulación de los datos por parte de los usuarios es mínima, evitando que se puedan producir fallos por entrada de datos ya sea de manera accidental o intencionada; una ventaja añadida de este punto es el hecho de que a los usuarios de a pie no suele interesarles cómo funcionan las cosas, sino que buscan directamente el resultado (por ejemplo, pocos usuarios se leen las Condiciones de uso y muchos son los que instalan los programas en las rutas por defecto; al usuario común sólo le interesa saber cuál es y dónde está el archivo con su participación). En el ámbito académico, este proyecto ha supuesto un enriquecimiento en el desarrollo de proyectos de tamaño medio; he tenido que desempeñar el papel de director, analista, diseñador, implementador y tester. Otra de las ventajas del desarrollo del proyecto es el hecho de que a lo largo de la carrera faltan asignaturas en las que sea necesaria una memoria tan detallada y completa como ésta; para mí ha supuesto un reto escribir una memoria que yo considero estructurada y completa sobre un software diseñado por mí para que sea leída por personas de distintas especialidades e intentar que todas las características sean entendidas por todas estas personas. Además, uno de los aspectos más atractivos del proyecto ha sido el hecho de realizarlo mediante servicios web, una rama que prácticamente no se trata en la carrera y que considero fundamental para la labor de un ingeniero informático vista las ofertas de empleo actuales. El hecho de tratar con un sistema distribuido también ha supuesto para mí una agradable experiencia, ya que en la actualidad, la gran mayoría de sistemas tiene que estar orientado a este tipo de comunicación. Estamos en la era de la comunicación y hemos de comunicarnos con varias personas, no sólo con una persona o de manera individual. He desarrollado un sistema de votación electrónico con la idea de agilizar los procesos democráticos; las ventajas que ofrece la e-democracia son inmensas, ya he hablado de ello, y ahora que están de moda los “indignados” y el movimiento de “democracia real ya”, podría ofrecer una solución el hecho de integrar soluciones de este tipo a los problemas que ellos plantean. Por último, he de decir que para mí, el aspecto más importante del proyecto ha sido trabajar con algoritmos criptográficos. Ya he hablado en la introducción de este aspecto; todo el mundo tiene información que desea ocultar y por tanto, existe gente que quiere hacerse con esa información; por ello es necesario el desarrollo e implantación de nuevos sistemas de seguridad y algoritmos para ocultar datos. No obstante, este proyecto no es un proyecto cerrado y pueden implantarse algunas mejoras; yo destacaría: •El sistema que he desarrollado no tiene soporte para móvil; a día de hoy, los llamados smartphones o los tablets son usados a diario y este tipo de aplicaciones deberían poder ejecutarse desde estos dispositivos; por desgracia, ni Android ni iOS soportan el uso de de 36 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación por lo que toda la información pasa por el servidor central. Debido al problema expuesto en el punto anterior, debe tenerse cuidado con la información que se pasa; no debe, no sólo no reconstruirse la clave secreta sino que el servidor central no debe tener acceso a las participaciones o a la capacidad de reconstruirlas, Debido a que cada uno de los compromisarios, al generar las participaciones, genera una “parte” para cada compromisario (incluyéndose a sí mismo), lo que hace es guardarse su propia “parte” sin enviarla al servidor central; de esta manera, el servidor central no puede reconstruir las participaciones de cada compromisario, a pesar de tener todas las demás. •Sincronización: Si bien no es el tema central del proyecto, se trabaja con sistemas distribuidos. Durante el diseño del sistema se ha decidido que todos los compromisarios debían estar reunidos al mismo tiempo para generar las claves y que al menos debía haber k para el descifrado; ya se ha explicado que para esto era necesario sincronizarlos de alguna manera y en el punto 3.3.2 se explica en detalle este algoritmo. Nosotros buscamos que nuestro software sea lo más eficiente posible en cuanto a coste computacional, por lo que se pretende eliminar las operaciones innecesarias, es decir, que si se ha perdido contacto con algún compromisario, no se hagan las operaciones sucesivas. Para ello se ha diseñado el sistema de tal forma que las operaciones se realizan por bloques: primero se crearán las partes de la clave parcial, el segundo paso será la creación del polinomio y las partes correspondientes a cada compromisario y por último, en un último “bloque” se procederá a crear la partición y guardarla. Si alguno de estos bloques falla, la creación de las claves no será considerada válida. De esta manera, si se pierde la comunicación en el primer paso, los pasos siguientes no serán realizados evitando los cálculos en las máquinas de los compromisarios. •Firma de Applets: Se ha necesitado acceder a información almacenada en el ordenador del usuario. Para poder elegir la ruta donde se guardarán las participaciones de la votación es necesario acceder a dicha información y esto no puede hacerse de cualquier manera. Es necesario que el applet que acceda a dicha información lleve una firma del autor para garantizar que es íntegro. Una vez firmado el applet, al usuario le saldrá un aviso y podrá aceptar o rechazar que acceda a su información. La firma de un applet se realiza mediante el comando: $JavaHome/bin: jarsigner $rutaApplet/MiApplet.jar key Tabla A.1: Comando para firmar un applet •Desarrollo web: El desarrollo de páginas y aplicaciones web es muy diferente al desarrollo de aplicaciones. Las páginas web van a ser visualizadas a través de un navegador, en distintos Sistemas Operativos y con distintas resoluciones de pantalla. El lenguaje HTML tiene una gran cantidad de etiquetas y atributos, pero no todos son aceptados por todos los navegadores o son procesados de la misma manera. Como una de las finalidades del proyecto es ser lo más abierto posible es necesario que la visualización sea correcta y funcional en la mayor parte de navegadores posibles; para ello ha sido necesario seguir los estándares dictados por el W3C para las tecnologías web. •FileUpload: Se ha explicado anteriormente que se pasaba la información del censo y de los compromisarios a través de un fichero. Este fichero era tratado con la biblioteca FileUpload. Habitualmente, el paso de parámetros a través de un formulario web se realiza con la codificación “application/x-www-form-urlencoded“, sin embargo, esta codificación no es aceptada por FileUpload y por tanto, es necesario cambiar la codificación del formulario mediante el atributo “enctype”: <form name="addvotation"enctype="multipart/form-data"> Tabla A.2: Encode Type para utilizar FileUpload 43 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Esta manera de codificación hace que todos los campos del formulario se pasen como un conjunto y sea necesario tratarlos antes de poder acceder a su contenido: FileItemFactory factory = new DiskFileItemFactory(); ServletFileUpload upload = new ServletFileUpload(factory); List items = upload.parseRequest(request); Iterator iter = items.iterator(); Tabla A.3: Tratamiento de datos con FileUpload Los valores del iterator pueden ser accedidos: FileItem item = (FileItem) iter.next(); item.isFormField() Tabla A.4: Tratamiento de datos con FileUpload II Y con la función “isFormField” diferenciamos los datos del formulario del contenido del fichero. 44 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Anexo II: Resultado de Pruebas Se van a mostrar los resultados de caja blanca y caja negra. Se ha de indicar que las pruebas se han realizado con las siguientes máquinas: Servidor1: Intel Centrino Duo 1,73Ghz 2GB de RAM Windows XP SP 3 nVidia GeForce Go 7300 Apache Tomcat 6.0.26 MySQL 5.1.41 Servidor 2: AMD Athlon™ II X2 220 2,8 Ghz 4GB de RAM Windows 7 32 bits Apache Tomcat 6.0.26 MySQL 5.1.41 Cliente 1: Intel Centrino Duo 1,73Ghz 2GB de RAM Windows XP SP 3 nVidia GeForce Go 7300 Cliente 2: AMD Athlon™ II X2 220 2,8 Ghz 4GB de RAM Windows 7 32 bits Cliente 3: Intel Core I3 4GB de RAM Windows 7 Home 64 bits GeForce GTX 590 Cliente 4: Intel Core 2 Quad 2,40 Ghz 3GB de RAM Windows Vista nVidia GeForce 8400GS Primero se harán todos los resultados de las pruebas de caja blanca. Primero se mostrará el plan de pruebas, seguido del grafo con todos los posibles estados (para evitar mostrar demasiada información en la 45 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación imagen y que el grafo sea claro se han obviado las comparaciones y simplemente se indica que se hacen comprobaciones respecto a una variable). Finalmente los resultados, que se van a mostrar mediante tablas, con los siguientes campos: •Camino: Camino del grado que se ha seguido. •Valor: Aquí se indicará que variable es la que se va a comprobar o qué se va a comprobar; el resto de variables que no se mencionen se introducirán con datos correctos. •Resultado: Porcentaje de aciertos. •Fallo: Si se ha producido un fallo, se pondrá aquí el motivo y el fallo producido. Nombre PRIORadmin – Caja blanca Descripción Se someterá al módulo PRIORadmin a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Repeticiones 50 Autor Antonio Martínez El grafo de la aplicación sería: Imagen A.2: Grafo de estructura de PRIORadmin 46 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Resultados: Camino Valores Resultado Fallo Camino 1-2-9 Fichero con el censo incorrecto 100% acierto Camino 1-2-9 Fichero con los compromisarios incorrecto 100% acierto Camino 1-2-3-9 Rondas >99 Rondas <= 0 100% acierto Camino 1-2-3-4-9 N > 99 N <= 0 100% acierto Camino 1-2-3-4-9 N != Particiones de los compromisarios 100% acierto Camino 1-2-3-4-5-9 K > 99 K <= 0 100% acierto Camino 1-2-3-4-5-9 K > N 100% acierto Camino 1-2-3-4-5-6-9 Fechas inválidas 100% acierto Camino 1-2-3-4-5-6-7-9 Timeouts <= 0 100% acierto Camino 1-2-3-4-5-6-7-8-10 Todos los datos correctos 100% acierto Tabla A.5 Resultados del test de caja blanca - PRIORadmin Ahora mostraremos los resultados del test de caja blanca de generadorClaves. El test de pruebas descrito en: Nombre generadorClaves – Caja blanca Descripción Se someterá al módulo generadorClaves a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Se probarán también fallos en la red para observar el funcionamiento del sistema Repeticiones 50 Autor Antonio Martínez El grafo del código sería: 47 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Imagen A.3: Grafo de estructura de generadorClaves Y la tabla de resultados: Camino Valores Resultado Fallos Camino 1-2-17-18 Imposible introducir una votación incorrecta - - Camino 1-2-3-17-18 La instrucción SQL se crea correctamente; no se puede comprobar este camino - - Camino 1-2-3-4-17-18 Se intenta generar claves para una votación mientras hay otra en curso 100% acierto 48 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Camino Valores Resultado Fallos Camino 1-2-3-4-5-17-18 Durante la ejecución del programa comprobar si existe algún fallo al excluir compromisarios fuera de tiempo 100% acierto Camino 1-2-3-4-5-6-8-9-...-16-18 (Pasar 0 veces por el bucle) No hay cambios en los valores; actualizar en el momento en el que están todos reunidos 100% acierto Camino 1-2-3-4-5-6-7-3-4-5-6-8- 9-...-16-18 (Pasar 1 vez por el bucle) No hay cambios en los valores; actualizar una vez antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-7-3-4-...-16- 18 (Pasar n vez por el bucle) No hay cambios en los valores; actualizar varias veces antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-9-17 Durante la ejecución del programa comprobar si existe algún fallo al excluir compromisarios fuera de tiempo 100% acierto Camino 1-2-3-4-5-6-8-9- 10-12-13-17 Durante la ejecución del programa comprobar si existe algún fallo al excluir compromisarios fuera de tiempo 100% acierto Camino 1-2-3-4-5-6-8-9- 10-11-12-13-14-16-18 (Pasar 0 veces) No hay cambios en los valores; actualizar en el momento en el que están todos reunidos 98% acierto Se perdió comunicación con el servidor en 1 ocasión Camino 1-2-3-4-5-6-8-9- 10-11-9-10-...-12-13-14- 16-18 (Pasar 1 vez) No hay cambios en los valores; actualizar una vez antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-9- 10-11-9-10-...-12-13-14- 16-18 (Pasar n veces) No hay cambios en los valores; actualizar varias veces antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-9- 10-12-13-14-15-13-...-16- 18 (Pasar 0 veces) No hay cambios en los valores; actualizar en el momento en el que están todos reunidos 100% acierto 49 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Camino Valores Resultado Fallos Camino 1-2-3-4-5-6-8-9- 10-12-13-14-15-13-...-16- 18 (Pasar 1 vez) No hay cambios en los valores; actualizar una vez antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-9- 10-12-13-14-15-13-...-16- 18 (Pasar n veces) No hay cambios en los valores; actualizar varias veces antes de que se reúnan los valores 100% acierto Tabla A.6 Resultados del test de caja blanca - generadorClaves Para terminar las pruebas de caja blanca, procedemos a realizar las pruebas del módulo recuento: Nombre recuento – Caja blanca Descripción Se someterá al módulo recuento a una serie de pruebas estructurales, orientada a verificar que funciona correctamente. Entorno Abierto. El módulo se encuentra en el servidor y es visible. Será un entorno como el definitivo. Descripción en detalle Se probará cada camino del algoritmo. Cada condición será probada y se introducirán datos para cada camino. En cuanto a los bucles, se introducirán datos para pasar 0, 1 y n veces. Se probarán también fallos en la red para observar el funcionamiento del sistema Repeticiones 50 Autor Antonio Martínez El grafo de transiciones sería como sigue: 50 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Imagen A.4: Grafo de estructura de recuento Y los resultados de las pruebas: 51 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Camino Valores Resultado Fallos Camino 1-2-14-15 Imposible introducir una votación incorrecta - - Camino 1-2-3-14-15 La instrucción SQL se crea correctamente; no se puede comprobar este camino - - Camino 1-2-3-4-14-15 Se intenta generar claves para una votación mientras hay otra en curso 100% acierto Camino 1-2-3-4-5-14-15 Durante la ejecución del programa comprobar si existe algún fallo al excluir compromisarios fuera de tiempo 100% acierto Camino 1-2-3-4-5-6-8-9-...-13-15 (Pasar 0 veces por el bucle) No hay cambios en los valores; actualizar en el momento en el que están todos reunidos 100% acierto Camino 1-2-3-4-5-6-7-3-4-5-6-8- 9-...-13-15 (Pasar 1 vez por el bucle) No hay cambios en los valores; actualizar una vez antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-7-3-4-...-13- 15 (Pasar n vez por el bucle) No hay cambios en los valores; actualizar varias veces antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-14-15 Introducir un archivo con identificador incorrecto o modificado 100% acierto Camino 1-2-3-4-5-6-8-9- 14-15 Intentar descifrar un voto corrupto - Es imposible verificar si un voto es corrupto o no sin ver el resultado del descifrado Camino 1-2-3-4-5-6-8-9- 10-11-13-15 (Pasar 0 veces) No hay cambios en los valores; actualizar en el momento en el que están todos reunidos 100% acierto Camino 1-2-3-4-5-6-8-9- 10-11-12-10-11-13-15 (Pasar 1 vez) No hay cambios en los valores; actualizar una vez antes de que se reúnan los valores 100% acierto Camino 1-2-3-4-5-6-8-9- 10-11-12-10-...-11-13-15 (Pasar n veces) No hay cambios en los valores; actualizar varias veces antes de que se reúnan los valores 100% acierto 52 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación errores producidos en la comunicación. •DropBox: DropBox es un sistema de almacenamiento de archivos en la nube. Este servicio permite a los usuarios almacenar y sincronizar archivos en línea y entre ordenadores, así como compartir archivos y carpetas con otros. Existe versión gratuita y de pago. A pesar de que DropBox ofrece varias funcionalidades, en este proyecto se ha utilizado este software para la realización de copias de seguridad. Para ello, la versión gratuita del servicio es más que suficiente. Se ha guardado tanto copias de seguridad semanales del código, como de la documentación, guardadas por separado en distintas carpetas para una mayor claridad. Se ha optado también por utilizar este servicio por la automatización del proceso y porque la transferencia se realiza usando una transferencia SSL con un cifrado AES de 256 bits. 59 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Anexo IV: Horas invertidas y presupuesto Este anexo pretende mostrar las horas invertidas en la realización del proyecto. Primeramente se mostrarán las horas invertidas en las distintas fases, así como una breve explicación de en qué consiste cada fase. Posteriormente, aunque este proyecto tiene un carácter investigador y no es un programa que se vaya a vender a un cliente, se procederá a hacer un estudio del presupuesto (excluyendo las horas dedicadas a la investigación). Fases del Proyecto: 1. Investigación: Esta fase se ha dedicado a la búsqueda de documentos técnicos (papers de aquí en adelante) que realizasen o explicasen de una manera teórica lo que se pretende programar. Lo primero que se buscó fue un paper que crease una clave pública sin conocer la clave privada. Finalmente se encontró el paper de Pedersen que se ha utilizado para crear la clave pública utilizando varias claves privadas. Posteriormente se procedió a buscar papers sobre votaciones electrónicas seguras. También fue necesario informarse sobre las votaciones y su extrapolación a un sistema electrónico; qué problemas puede acarrear esto. También se aprovechó este punto para investigar sistemas ya diseñados y puestos en funcionamiento con anterioridad con intención de hacer un aprendizaje proactivo (aprender de los fallos de otros). Uno de los puntos más complejos fue la investigación sobre como realizar el descifrado, ya que no se menciona nada al respecto en el paper de Pedersen (hace referencia a otro paper, al de Desmedt) que tampoco menciona nada al respecto. Finalmente, tras varias reuniones con el criptógrafo de la Universidad de Zaragoza, José Luis Salazar, se logró averiguar que era necesario hacer una interpolación de Lagrange para obtener las participaciones correctas a la hora de descifrar. 2. Aprendizaje/Formación: Si bien es cierto que la programación Java no es algo nuevo para el desarrollador, la forma de programar applets y servlets, así como la manera de comunicarse entre ellos es algo nuevo por lo que ha habido que invertir muchas horas en la formación. Los lenguajes HTML, CSS y Javascript tampoco han sido parte de la formación por lo que ha sido necesario invertir horas también en formarse en este aspecto. Por último, a pesar de haber recibido conocimientos en cifrados y aritmética modular, las matemáticas utilizadas para este proyecto han necesitado de un repaso y cierto estudio sobre los algoritmos de cifrado utilizados, así como un estudio para conocer la seguridad que ofrecían las soluciones propuestas (cómo de seguro es un sistema de cifrado umbral k-n). 3. Reuniones: Estas reuniones incluyen aquellas reuniones con el director del proyecto (Joan Piles) como con el ponente (José Luis Salazar) para conocer los requisitos de la aplicación, así como aquellas reuniones realizadas para llevar un control de la evolución del proyecto. También se incluyen en este tiempo las reuniones para solventar las dudas surgidas durante el desarrollo del proyecto. 4. Análisis: Aquellas horas dedicadas al análisis de los requisitos. Esto incluye un estudio de cómo abordar los problemas que puedan surgir, así como las horas dedicadas al estudio de la aplicación existente en busca de nuevos requisitos. 60 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación 5. Diseño: Desarrollo de los diagramas que modelen el software a programar. 6. Programación: Horas dedicada exclusivamente al desarrollo de la aplicación. 7. Pruebas y depuración: Horas dedicadas a testear el software y reparar los fallos obtenidos. Este punto debe volver a empezarse de cero si se ha detectado algún fallo; es decir, en caso de realizar alguna modificación en el código para arreglar algún fallo es necesario volver a realizar todas las pruebas. 8. Documentación: Horas dedicadas a reunir toda la documentación realizada y reunirla en los documentos de la memoria y anexos. A continuación se muestra una tabla con las horas invertidas en cada fase (nota: las horas han sido redondeadas). Fase Horas Investigación 160 Aprendizaje/Formación 20 Reuniones 180 Análisis 170 Diseño 120 Programación 120 Pruebas y depuración 50 Documentación 50 Total 870 Tabla A.11: Total de horas invertidas A continuación se va a mostrar un diagrama de Gantt: Imagen A.5: Diagrama de Gantt Este es el diagrama de Gantt del proyecto una vez finalizado. Se puede observar de manera bastante clara que los módulos se han programado de manera independiente. La documentación no se fue recopilando hasta el final del proyecto. Por su parte, las pruebas tienen una carga muy superior en los últimos meses que en el resto del tiempo; esto es debido a que no es hasta la finalización de todos los módulos que no se puede realizar las pruebas de que los descifrados son correctos y es en este punto cuando se realizan las pruebas de integración del sistema. En esta segunda parte del anexo se va a proceder a calcular el presupuesto del proyecto. Si bien ya hemos indicado que es un proyecto de carácter investigador más que para vender a un cliente, se cree oportuno la inclusión de este apartado, pues el proyecto no deja de ser, al fin y al cabo, el desarrollo de una 61 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación aplicación software. Para el cálculo del presupuesto se han eliminado las horas dedicadas a investigación y aprendizaje y las horas dedicadas a las reuniones se contarán como reuniones con el cliente que nos pide desarrollar el software, siendo tomadas como horas dedicadas al análisis de requisitos. Función Precio(€/hora) Analista 40 Diseñador 35 Programador 25 Tabla A.12: Tabla de precios/hora Así pues, el presupuesto por el desarrollo de la aplicación sería: Fase Precio (€/hora) Horas Total Reuniones 40 20 800 Análisis 40 170 6800 Diseño 35 120 4200 Implementación 25 120 3000 Pruebas y Depuración 25 50 1250 Documentación 40 50 2000 Total 530 18050 Tabla A.13: Precio de las horas invertidas en el software Si bien este no es el precio final. A este precio, debe sumarse el precio del servidor físico, en caso de querer que sea la propia compañía desarrolladora quien lo adquiera, así como el precio de las licencias y de instalación del sistema. En cuanto al precio de las licencias, todo ha sido desarrollado mediante herramientas libres y OpenSource, por lo que esto no conllevaría un coste adicional. 62 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Anexo V: Sistema de copias de seguridad y sistema de almacenamiento Todo proyecto es susceptible de sufrir una pérdida de información. Pueden ocurrir fallos en los ordenadores de los desarrolladores o perderse los papeles que contienen información sobre el proyecto. Las computadoras son también susceptibles de sufrir fallos y con ello, perder toda la información que contienen (fallos eléctricos, sobrecalentamientos, exceso de humedad....). Es por ello que siempre es necesario realizar copias de seguridad (llamados Backups) de la información. Existen muchas herramientas (de pago y gratuitas) que realizan este tipo de tareas, permitiendo al usuario olvidarse de hacerlas manualmente. Antes de empezar con los backups se debe hacer una pregunta: ¿qué información desea guardarse? La respuesta depende de la cantidad de información a guardar, así como de la criticidad de la misma. Para el proyecto que nos ocupa se considera que toda información es crítica, pues quiere hacerse una retrospectiva y un estudio de la evolución del proyecto para aprender de los problemas encontrados (debido a la falta de experiencia en este tipo de proyectos) por parte del alumno. Así pues, la información a guardar será: 1. Correos intercambiados con el cliente (director/ponente). 2. Actas o resúmenes de las reuniones con el cliente (director/ponente). 3. Documentos relacionados con el análisis y el diseño. 4. Módulos. 5. Documentación final. Una vez que sabemos qué información nos interesa guardar, vamos a analizar dónde y cómo pueden hacerse las copias de seguridad. 1. Los resúmenes de las reuniones y los correos mandados y recibidos guardados en la cuenta de correo que se mandan/reciben. No obstante, un hackeo de la cuenta o un fallo en el servicio (temporal) puede suponer un retraso, por lo que se considera necesario guardar una copia extra de estos correos. La redundancia es una de las principales herramientas de seguridad. Así pues, para este proyecto se pondrá una cuenta de correo auxiliar en la que se guardará una copia de todos los correos. A la hora de enviar los correos, se enviará con copia oculta a dicha dirección. Al enviarse como copia oculta, al cliente le será imposible saber que el correo está siendo guardado, así que al recibir el correo deberá ser reenviado a dicha dirección. Podría también optarse por añadir la dirección del proyecto como copia en vez de copia oculta, pero en ese caso, habría que cerciorarse en cada correo de si el cliente ha contestado a todas las direcciones añadidas o sólo al emisor; como suele decirse, “si quieres que algo salga bien, hazlo tú mismo”. Para añadir más claridad a los correos, de manera que se sepa que todos los correos pertenecen al proyecto, se añadirá al principio del asunto del correo la frase “PFC:” seguida del asunto del mismo. 2. Respecto a las reuniones, se guardará un documento de texto con la fecha de la reunión que contenga el resumen de la misma. Debe añadirse en la cabecera del documento los asistentes a la reunión, la fecha y la duración de la misma. Las actas de las reuniones se guardarán en el ordenador del analista, dentro de la carpeta referente al proyecto, en una subcarpeta denominada “$PFCHome/actas”. Respecto a las copias de seguridad, se guardarán en la misma cuenta de email que se ha comentado 63 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación en el punto anterior. Se mandará un correo con el documento adjunto y cuyo asunto será: “PFC: Reunión” seguido de la fecha en la que se haya realizado la reunión. 3. Para los documentos de análisis y diseño (diagramas, notas, documento de requisitos,...) no se dictamina ningún “estándar” a seguir. Sin embargo para que no se encuentren los documentos mezclados, se propone que los documentos se guarden en el ordenador del analista, en una subcarpeta denominada “$PFCHome/análisis”. Como en este punto hay documentos de diversa índole (imágenes, documentos de texto, hojas de cálculo,...) no se ha pensado ningún tipo de organización para conocer el orden o el contenido y se deja al analista que se encargue de esto. Respecto a las copias de seguridad, se explicará tras terminar de enunciar el modo de almacenamiento de los módulos y la documentación. 4. Sobre los módulos que definen el sistema, serán guardados en el ordenador del programador (ya que será él el único encargado de modificar estos módulos. Cada módulo deberá guardarse en una carpeta independiente dentro del home del proyecto. Se pensó en la utilización de seguir algún estándar de calidad y realizar alguna consultoría, pero se consideró que aplicar una consultoría en profundidad sobre la calidad de programación era demasiado para un proyecto tan pequeño y las consultorías de calidad ofrecidas para este tipo de proyectos eran demasiado inútiles (al fin y al cabo, será el propio estudiante quien realice la consultoría y se puede manipular para que satisfaga las condiciones). Lo que sí se pide es que el código esté bien documentado. Toda función debe tener un comentario que explique qué operación realiza (no se pide que se haga de manera formal) y cada vez que se vaya a operar algún dato, se haga un comentario con qué se está haciendo. Se hablará de los backup de los módulos después de hablar de la estructura de la documentación. 5. Por último, la documentación. Cada nueva versión tendrá un número distinto; así, la primera versión de un documento será “nombreDocumento_v01” y el número irá aumentando con cada nueva versión. Una versión implica una modificación del documento. Si la modificación incluye nueva información pero no ha modificado nada de lo anteriormente escrito, se considera que la versión es la misma. La documentación tendrá su propia carpeta dentro del home del proyecto y en ella se incluirán todos los documentos que se consideren oportunos para la realización de la memoria final y del manual de usuario. Para las copias de seguridad de los puntos 3, 4 y 5 se va a utilizar el servicio gratuito de DropBox. DropBox es un servicio que ofrece un software para el almacenamiento en la nube. Sirve también para la sincronización entre 2 o más ordenadores de la información almacenada en este servicio. Para el almacenamiento en la nube se sigue el mismo esquema de carpetas que se ha seguido para realizar el almacenamiento en el ordenador con una salvedad. Cada copia de seguridad irá dentro de una carpeta con la fecha de la copia de seguridad. Las copias de seguridad se harán con carácter semanal, al comienzo de cada semana (siempre que no sea festivo y se disponga de conexión a Internet). Se quiere añadir una tercera vía redundante para las copias de seguridad de estos tres puntos. Se dispone de acceso físico a un ordenador que será utilizado como almacén de dicha información. El primer Lunes de cada mes se efectuará la copia de seguridad no sólo a través de DropBox, sino que mediante un pendrive se realizará una copia en dicho ordenador, siguiendo las directrices marcadas en el punto anterior. 64 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Será en este ordenador donde se guardarán todas las bibliotecas e instaladores de programas que se han utilizado para el desarrollo de este proyecto. 65 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Anexo VI: Manuales de usuario e Instalación Manual de Instalación Windows 1 Introducción El presente documento tiene como objeto describir la instalación del sistema de voto electrónico PRIOR. Puesto que se trata de una aplicación que puede correr en entornos muy diversos, ya que los únicos requerimientos que presenta son Java 6 y Tomcat 6, y de hecho probablemente convivirá con otras aplicaciones ya instaladas, es imposible cubrir todas las posibilidades que presenta (por ejemplo, sistemas Windows, Linux, entornos de hosting compartido, etc...). A continuación se explica la instalación del software en un servidor Windows, no obstante, podría realizarse en otros sistemas operativos. 2 Instalación del sistema base •Por un lado, es necesario descargarse el instalador de Java 6 desde la web oficial de Java: http://www.java.com/es/download/ •A continuación se procede a instalar MySQL. En este proyecto se ha utilizado el paquete xampp, que instala el gestor FTP filezilla (entre otros programas). El programa es gratuito y puede descargarse de: http://www.apachefriends.org/es/xampp.html •Se descarga el contenedor de servlets, Tomcat, desde la web oficial. Durante el diseño del software se ha utilizado Tomcat 6.0.26: http://tomcat.apache.org/download-60.cgi 3 Configuración del sistema •Creación de un usuario en la base de datos para la modificación de las votaciones. Consultar Apéndice A.1. •Carga de la estructura de tablas de la base de datos que se proporciona en una archivo SQL aparte. Puede hacerse mediante alguna herramienta gráfica o web, o a través de la línea de comandos como se muestra en el apéndice A.2. •Creación manual del primer administrador. En caso de hacerse a través de línea de comandos, puede verse un ejemplo en el apéndice A.3. De otra manera, puede realizarse a través del gestor PhpMyAdmin incluido en el producto xampp. 4 Configuración de Tomcat •Eliminación (si se desea, pero es algo altamente recomendado) de las aplicaciones por defecto mediante rm -fr /opt/tomcat/webapps/*. •Obtención de los certificados en formato PKCS#12. En el caso de un servidor de 66 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación producción, deberán obtenerse de una tercera parte confiable autorizada a emitirlos (obteniendo probablemente la clave y el certificado por separado, y teniendo que integrarlos posteriormente). En el caso de querer utilizar un certificado autofimado, mirar en el apéndice B.1. Se puede ubicar en cualquier lugar, pero en el ejemplo estará en /opt/tomcat/server.p12. •Obtención del conjunto de certificados de DNI electrónico y su inclusión en una KeyStore de Java. Se proporciona dicho archivo ya creado, que habrá que ubicar en su lugar correspondiente (en este caso, como ejemplo, en /opt/tomcat/.truststore). En caso de ser necesario recrearlo, se recomienda acudir a la documentación de Java tras bajar los distintos certificados de CA del DNI-e. Tomcat sólo aceptará certificados firmados por alguna de las autoridades presentes en este archivo. •Configuración del tomcat para que utilice el certificado de servidor creado. Hay que editar el archivo /opt/tomcat/conf/server.xml, en concreto añadiendo la siguiente entrada, en la que se puede cambiar también el puerto de escucha: <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/opt/tomcat/server.p12" keystoreType="PKCS12" keystorePass="ab..12..cd..34" truststoreType="jks" truststoreFile="/opt/tomcat/.truststore" truststorePass="changeit"/> •Es aconsejable también desactivar el conector de HTTP estándar, para asegurar el uso de https: <!--<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />--> 5 Instalación de las aplicaciones •Se detiene el servicio de tomcat. •Se copian los archivos mysql-connector-java-5.1.6-bin.jar y MultiAccessValve.jar a la carpeta lib de la instalación de tomcat (por ejemplo, $tomcatHome/lib/). •Se copian los archivos PRIOR.war, PRIORadmin.war, generadorClaves.war y recuento.war a la carpeta webapps de tomcat (por ejemplo, $tomcatHome/webapps/). •Se inicia el servicio de tomcat. •En este momento, si se han utilizado los nombres de usuario, nombres de base de datos, y claves por defecto (los puestos como ejemplo en los apéndices, excepto la clave, que por motivos de seguridad no se incluye en el presente documento) ya tendremos el sistema funcional. Apéndice A: Configuración de la base de datos 67 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación A.1 Creación del usuario y base de datos # Creación de clave para el administrador, si no la tuviera /usr/bin/mysqladmin -u root password 'ab..12..cd..34' # Creación de un usuario y base de datos mysql --user=root --password=ab..12..cd..34 << __EOF__ CREATE USER 'PRIOR'@'localhost' IDENTIFIED BY 'ab..12..cd..34'; CREATE DATABASE PRIOR; GRANT ALL ON PRIOR.* TO 'PRIOR'@'localhost'; FLUSH PRIVILEGES; __EOF__ A.2 Creación de la estructura de tablas mysql --user=PRIOR --password=ab..12..cd..34 PRIOR < PRIOR.sql A.3 Creación del primer administrador mysql --user=PRIOR --password=ab..12..cd..34 PRIOR << __EOF__ INSERT INTO Administradores(userid,password,rol) VALUES("prior",MD5("ab..12..cd..34"),"admin"); __EOF__ Apéndice B: Emisión de certificados B.1 Certificados de servidor web # Generación de la clave privada openssl genrsa -out server.key 2048 # Petición de certificado openssl req -new -key server.key -out server.csr # Autofirma del certificado openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt # Creación del contenedor PKCS#12, eligiendo una clave que luego habrá que configurar. # La clave para tomcat por defecto es "changeit",así que no es aconsejable su uso. openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt Apéndice C: Personalización de las aplicaciones C.1 Archivos de configuración de las aplicaciones Una vez instaladas las aplicaciones, cada una de ellas tiene un archivo de configuración XML en /opt/tomcat/webapps/<appp>/WEB-INF/web.xml que se puede modificar para ajustar los parámetros que sean necesario. Los parámetros propios de las aplicaciones (muchos se repiten en varios sitios, una vez por cada servlet, otra común para los JSP) se encuentran entre etiquetas <init-param> o <context-param> y son los siguientes: •dbDriverName: Nombre del driver con el que conectar a la base de datos (se recomienda no cambiarlo, puesto que aunque en principio no se usan extensiones específicas de MySQL no 68 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación En este punto, tenemos las opciones de crear una nueva votación, eliminar una existente o modificar. 2.1 Creación de una nueva votación Deberán rellenarse todos los campos (excepto el de descripción, que es opcional (aunque recomendable)). •Descripción de la votación: Es el identificador por el que conoceremos a la votación. •Número de rondas: En caso de que la votación posea más de una ronda, habremos de indicarlo en este punto. •Número de compromisarios: Es el número n de partes a partir de las cuales se creará la clave pública. •Longitud de la clave: Es la longitud en bits que tendrá la clave de la votación. Cuanto mayor sea, más tiempo tardará en calcularse (aunque también implicará que la seguridad es mayor). •Datos de la consulta y Configuración de la consulta: Estos dos campos son los que configuran la votación en sí y utilizan un sistema XML explicado en la documentación oficial del proyecto. Para generar de una manera agradable al usuario sin que tenga que teclear el código se ofrece un botón que lanza un generador de votaciones a través de un applet de Java: 75 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación El funcionamiento del generador es bastante sencillo. El que se muestra es el interfaz inicial. Se desea calcular la “Meta final”. Tiene varias opciones, pueden crearse hijos dándole al botón derecho en la meta (o en un hijo en el que se quieran crear nuevos hijos) y pulsando el botón “Insertar”. Esto nos mostrará una nueva ventana donde insertar las opciones: 76 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Una vez creados los hijos (en caso de ser necesario), es necesario añadir alternativas a la votación, que será lo que se valore en las hojas del árbol. Esto lo haremos mediante el uso del comando “Alternativas”, dándole al botón derecho en la “Meta final”: Nuevamente aparecerá una nueva ventana, donde podremos añadir y editar las alternativas existentes: 77 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Y con esto finaliza el uso del generador de votaciones. •Censo de usuarios: El censo de usuarios es para las votaciones que necesiten autenticación. Como el censo puede ser bastante extenso, la inserción de los votantes se hará a través de un archivo editado en texto plano, de la siguiente manera: Identificador Grupo MD5 de la clave El identificador puede ser un nombre cualquiera o el DNI del usuario (depende del tipo de autenticación que requiera la votación. Los votantes se asignarán a un grupo (esto es debido a que un grupo puede tener más peso que otro). Se pide que la clave se pase como MD5 para que ni el sistema ni el administrador tenga acceso a las claves de los usuarios. Todos los campos irán separados por un tabulador y los votantes irán uno por cada línea. Vemos un ejemplo del archivo: 78 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Apretando el botón saldrá un navegador para elegir el archivo: •El listado de compromisarios sufre un proceso similar al de los votantes: Identificador Participaciones MD5 de la clave El identificador puede ser un nombre cualquiera o el DNI del usuario (depende del tipo de autenticación que requiera la votación. Participaciones es el número de participaciones que posee un compromisario (no hay problema en que tenga más de una; supone una reducción en la seguridad, pero se deja a elección del administrador de la votación. Se pide que la clave se pase como MD5 para que ni el sistema ni el administrador tenga acceso a las claves de los usuarios. 79 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Todos los campos irán separados por un tabulador y los compromisarios irán uno por cada línea. Vemos un ejemplo del archivo: Y con esto, quedaría cerrado el primer paso para crear una votación: Pulsando el botón “Seguir” pasaremos al siguiente paso: 80 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación En este punto se mostrará la información que hemos introducido en el paso anterior para asegurarnos de que todo es correcto. Al comienzo se añade una línea informando de cuántos votantes y compromisarios han sido procesados. Debajo podremos rellenar la información sobre las fechas de las rondas, el factor de reconstrucción (cuantos compromisarios hacen falta para descifrar la votación) y los timeout que se ofrecen para dar por perdido a un compromisario (esto se hace por si algún compromisario, actuando maliciosamente o por error pierde la conexión con el servidor se aborten los procesos de generación de claves y de recuento). Dándole al botón “Seguir” se finalizará la operación. NOTA: Este paso puede costar varios minutos (para claves de longitud 2048 o superiores). Tenga paciencia. Una vez finalizado el proceso, nos saldrá una pantalla como la siguiente: 81 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 2.2 Borrar una votación Desde el menú inicial del Administrador de Votaciones, existe un menú desplegable que nos muestra las votaciones existentes, podemos elegir cualquiera de ellas: Una vez seleccionada, dándole al botón “Borrar”, se procederá a eliminar la votación. Si la operación es exitosa, aparecerá el siguiente mensaje: 82 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación 2.3 Modificar una votación Elegir una votación para modificar es similar al proceso para eliminar una. Se elige la votación a través de un menú desplegable y se pulsa el botón “Modificar”. Esto nos llevará a una nueva pantalla, donde se cargarán los datos de la votación elegida: pudiendo modificar todos los campos y añadir o eliminar las rondas. Una vez finalizada la modificación, pulsando el botón “Actualizar” se insertarán los nuevos datos de la votación y aparecerá una pantalla indicando que la operación ha sido exitosa. 83 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación 3 Compromisario Los papeles de un compromisario en esta aplicación son dos. El primero será generar la clave de la votación y el segundo será aportar su participación secreta para descifrar los votos. Para ejecutar estos sistemas es necesario: •Que el compromisario tenga activado Javascript en su navegador. •Que permita las ventanas emergentes del host. •Que tenga instalada la máquina virtual de java. 3.1 GeneradorClaves Este es el módulo que se utiliza para generar las claves de una votación creada por el administrador. Es necesario que todos los compromisarios estén reunidos para realizar esta operación. El hecho de reunir a los compromisarios es transparente al usuario. Se accede a través de: https://myHost/generadorClaves Antes de cargar la página, nos pedirá autenticación: 84 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Una vez aceptemos, habremos finalizado el proceso de generación de la clave y tendremos en el archivo indicado nuestra participación: 3.2 Recuento Este módulo es para realizar el descifrado de las votaciones. Es necesario que se reúnan tantas participaciones como el factor de reconstrucción indicado a la hora de generar la votación. Se accede a través de: https://myHost/recuento El proceso de logueo es exactamente igual al apartado anterior. Al final llegaremos a la siguiente pantalla: 91 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Sólo aparecerán las rondas que hayan finalizado (y de votaciones que hayan sido inicializadas, obviamente). Cuando pulsemos el botón “Recuento” llegaremos a la fase de sincronización. Esta fase de sincronización es exactamente igual a las del generador de claves. Cuando estén reunidas las participaciones se ejecutará un applet con el siguiente interfaz: 92 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Pulsando en “...” nos saldrá un cuadro de diálogo que nos permitirá seleccionar el archivo donde está nuestra participación: Una vez seleccionado y enviado, se mostrará en el cuadro de texto anterior la ruta del archivo: 93 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Pulsaremos el botón enviar y esperaremos a que nos salga una ventana de aviso indicando que el paso 1 de 2 ha finalizado: Cuando aceptemos, llegaremos a la segunda fase de sincronización: 94 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Cuando estén reunidos, se ejecutará el 2º paso del descifrado, que puede llevar algunos minutos. Finalmente, aparecerá el siguiente mensaje: Cuando se acepte este mensaje, nos llevará a un último paso, que esperará a que todos los compromisarios hayan aportado su parte del descifrado hasta que cuando estén todos mostrará el siguiente mensaje: 95 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Y con esto, queda finalizado el proceso de descifrado. 4 Votante El votante accede a la aplicación a través de : https://myHost/PRIOR Esto hace mostrar un menú desplegable con todas las votaciones que tienen alguna ronda activa y que han sido inicializadas: Si elegimos una votación que requiera autenticación, nos saldrá un cuadro de texto para autenticarnos: 96 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación Si la votación es abierta o si la autenticación ha sido exitosa, aparecerá el árbol de la votación: Para poder emitir el voto hemos de valorar todos los nodos. Si un nodo tiene hijos, se valorará cual de los hijos tiene más valor mientras que si es una hoja, se valorarán las alternativas. Hasta que no se hayan valorado todos los nodos (un nodo ha sido valorado si cambia de color; inicialmente es turquesa). Para valorar un nodo haremos doble click en él y nos aparecerá una ventana emergente: 97 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Para valorar la opción debemos mover el indicador de la barra horizontal hacia uno de los extremos o bien tildar el cuadro de arriba a la izquierda: Una vez le demos al botón de aceptar, si se ha dado el valor correctamente, nos saldrá una ventana advirtiendo de la consistencia. Podemos aceptarla sin ningún problema: 98 Antonio Martínez Jiménez Desarrollo de un sistema de recuento distribuido de una e-votación En este caso hemos votado a un nodo con hijos, se puede observar como cambiaría de color y se desplegarían los hijos del nodo: Ahora podremos votar a sus hijos, que son nodos hoja y por tanto valoraremos las alternativas de la votación en vez de dar peso a uno de los hijos como en el caso anterior: 99 Antonio Martínez Jiménez _______________________________________________________Desarrollo de un sistema distribuido de una e-votación Cuando todos los nodos hayan sido valorados nuestra ventana debería ser algo de la siguiente manera: Ahora ya podremos validar el voto mediante el botón “Votar” (en caso de no haber rellenado todos los nodos, dará un fallo y no permitirá emitir el voto). Si el usuario está usando los navegadores Mozilla Firefox o Google Chrome es posible que vuelva a pedir la contraseña del votante: 100