Sesión celebrada el 3 de Noviembre de 2014

• Grupo Modificación de resultados: 
•  Pregunta 1: ¿Qué tipo de modificación se puede realizar en una votación tipo Referendum? 
  • Si es una votación de tipo Si/No hay poca modificación que se pueda aplicar sobre los resultados. Se podrían aplicar ponderaciones por población/ciudad por ejemplo para dar más valor a votos de zonas con menos representación. Para aplicar estas modificaciones habría que conocer más datos del votante además del voterid.
•  Grupo Verificación: 
  •  Pregunta 1: ¿Cómo se gestionan las claves para descifrar y  cifrar? ¿Se utiliza la misma base de datos del resto del sistema o una  aparte? 
    • se utiliza un sistema de clave pública/privada. Las claves son gestionadas por las autoridades que son entidades independientes entre sí, que ejecuta el election-orchestra [1]. Para cada votación (y pregunta de una votación), cada autoridad genera un par de claves publica/privada, y las llaves públicas se juntan para generar la clave conjunta, con la que se cifran los votos. Para descifrar los votos, se hace un procedimiento primero de anonimización (mediante una mixnet) y luego se descifran los votos anonimizados. Como cada autoridad tiene una parte de la clave, tienen que colaborar todas en el mixin y descifrado.
    • El proceso es más complicado que lo que he detallado arriba. Está un poco más detallado, con referencias bibliográficas en la documentación técnica de por ejemplo la última votación que hicimos [2] (ver punto 4 del pdf)
  •  Pregunta 2: ¿Se utiliza algún algoritmo específico para cifrar o descifrar?
    • Todo esto está detallado en el pdf [2] en el punto 4. Es importante recalcar que no sólo se han de cifrar los votos, sino por ejemplo también se añade una ZKP (zero knowledge proof) del plaintext, tal y como se detalla en el pdf, para hacer el sistema CCA2-secure. Por otra parte, tampoco sólo se descifran los votos, sino que se hace primero un procedimiento de mezclado de los votos para anonimizarlos, y luego procedimiento de descifrado, y además se aportan pruebas matemáticamente verificables de que el proceso es correcto.
•  Grupo Cabina de voto:  
  •  Pregunta 1: ¿Cómo se cifran los votos? 
    • Los votos se cifran con el algoritmo Elgamal, usando como clave la clave conjunta generada por las autoridades para la votación. 
    • Además del cifrado, hay un paso previo de codificación de la papeleta en números cifrables. Habrá que convertir las opciones en un número que será lo que se cifre, por ejemplo si hay tres opciones, la primera opción podría ser 001, la segunda podría ser 002 y la tercera podría ser 003. La conversión de opciones a números puede ser una convención para cada votación. Además hay que tener en cuenta que algunos números no se pueden cifrar con este algoritmo, por lo que la representación de los votos tendrá que tener estas cosas en cuenta.
    • El código de cifrado de votos se ejecuta por javascript en la cabina de votación, y está aquí: <a href="https://github.com/agoravoting/agora-core-view/tree/master/crypto">https://github.com/agoravoting/agora-core-view/tree/master/crypto</a>
    • Es importante recalcar que como los votos están cifrados con una clave pública conjunta generada por las autoridades, cuando el servidor de AgoraVoting recibe los votos cifrados, ni siquiera nosotros somos capaces de averiguar su contenido. El voto es secreto. Y ni siquiera las autoridades desvelan el secreto del voto al hacer el recuento (a menos que todas sean corruptas y compinchadas) porque sólo descifran los votos una vez han sido anonimizados. 
  •  Pregunta 2: ¿De qué forma identifica la cabina de voto al usuario logueado? 
    • En un principio la cabina de votación no tiene por qué diferenciar usuarios. En realidad los usuarios son identificados por la url que contiene el id del votante y un hmac único que evita que nadie no autorizado se invente una url para votar por otra persona. El hmac se genera usando una clave secreta compartida entre la cabina de votación y el sistema de autenticación.
    • Hay más información sobre la integración en el documento de integración con podemos [3]. 
  •  Pregunta 3: ¿Qué lenguaje de programación usan? 
    • usamos muchos. el ballotbox está en Go. la cabina, en javascript. Election-orchestra en python. Y verificatum, que es la mixnet que utilizamos, escrita por un reputado criptógrafo sueco, cuya mixnet ha sido usada por ejemplo en las elecciones generales de Noruega del año pasado, en Java. El agora-verifier tiene algo de código bash, también usa java e incluso algo de scala.
  •  Pregunta 4: ¿Tienen los diferentes subsistemas divididos o trabajan en un mismo proyecto? 
    • Si, cada parte está en un repositorio diferente en github [4]
      
      
•  Grupo creación y administración de censos:  
  •  Pregunta 1: Se dijo en la presentación que un usuario podía  votar las veces que quisiera y solo valía el ultimo voto. ¿Cuál es el  proceso para ello?
    • esto es así en la última implementación (agora v3) pero es configurable el número de veces. El proceso es sencillo: desde la app de podemos (que es donde se ha usado) el usuario se autentica, y luego es redirigido a la cabina de votación con unos credenciales de votos, que finalmente usa para emitir su voto. Esos credenciales incluyen un identificador de votante (que no revela nada de información censal) que se utiliza para sobreescribir el voto si emite más de uno.
    • osea, cada voto cifrado es almacenado junto a un id de votante, si ese votante vota otra vez, se sobreecribe el voto cifrado en la base de datos.
  •  Pregunta 2: En cuanto a la gestión de censos, ¿se crea un censo automáticamente cuando creamos una nueva votación? 
    • En la última versión de agora (v3), ahora mismo la gestión del censo es externa. La forma en que se integra el sistema de autenticación/censo con agora voting está descrito en  [5]. 
    • Al ser los subsistemas independientes, se puede utilizar el mismo censo para diferentes votaciones o incluso diferentes censos para la misma votación. El censo se usa para identificar univocamente a un usuario generando un id único por usuario y enlazando con la cabina de votación a través del enlace con la información detallada en [3].
  •  Pregunta 3: ¿Un mismo censo puede pertenecer a varias votaciones? o por el contrario, cada votación tiene un censo asignado 
    • como hemos dicho arriba, el censo es externo y por tanto versátil. El censo puede ser abierto, e incluso pueden invalidarse votos de votantes que hayan sido invalidados (por ejemplo si se ha detectado un problema con dicho votante) a la hora de generar un dump de los votos de los que se hará el recuento.
  •  Pregunta 4: En el caso de querer crear dos votaciones con el mismo censo, ¿cómo se hace? 
    • como hemos dicho arriba, el censo es externo y por tanto versátil.
    • La única diferencia entre votaciones diferentes es la generación del link a la cabina de votación para redirigir tras la autenticación, por lo que incluso se puede usar un mismo formulario web donde se pida usuario/contrasela y un desplegable con la votación y se usa la misma base de datos, pero se genera el link para una votación diferente, usando el id de votación y la clave compartida entre el sistema de autenticación y la cabina de votación.
• 
  
•  Grupo Autenticación: 
  •  Pregunta 1: Actualmente, nuestro sistema de verificación de la  autenticidad del usuario logueado consiste en almacenar una cookie con  un hash md5 generado a partir de los credenciales del usuario. Si  alguien copiara esa cookie, podría suplantar a dicho usuario. ¿Utiliza  Agora Voting algún método para evitar esta tipo de amenazas? 
    • No. La  autenticación es gestionada externamente. Los credenciales que utiliza agora-voting para votar son generados externamente y temporales por seguridad. El detalle de cómo se generan esos credenciales está en [5], para mitigar estos problemas se usa un timestamp con un periodo corto de tiempo de tal forma que si alguien copia esta cookie, sólo sea válida durante ese corto periodo de tiempo y así se limita el problema de suplantación.
  •  Pregunta 2: Actualmente, los usuarios en nuestro sistema sólo  tienen un nombre de usuario y una contraseña. ¿De qué datos de usuarios  se dispone en Agora Voting? 
    • En la v3, por ahora el censo es manejado externamente. No obstante, hemos usado de todo: dni-e, certificado de la FNMT, dnis escaneados, incluso hemos usado sistemas mixtos de voto presencial en papel y voto electrónico con un censo único de votantes que se generaba a medida que votaban, de manera que los votantes en papel eran registrados mediante una app móvil por los operadores de la urna para evitar duplicados en varias urnas o en papel y voto electrónico.  Intentamos ser lo más flexibles posibles para adaptarnso a cada caso.
      
      
  • Grupo Frontend de resultados:
    • Pregunta 1: ¿Cuántos repositorios se usan en Agora Voting?
      • no los hemos contado, pero para la versión 3:
        • agora-api (el ballotbox, backend que recibe los votos y lanza el recuento)
        • agora-core-view (la cabina de votación)
        • election-orchestra (software que ejecutan las autoridades para automatizar el lanzamiento de creación de claves publica/privada y realizar los recuentos)
        • verificatum (mixnet que realmente hace el recuento y crea las claves, gestionado por election-orchestra en las autoridades)
        • agora-verifier (software que sirve para que un tercero pueda verificar un recuento)
        • agora-tally (software que interpreta el formato de los votos de ágora y que hace uso de openstv para generar los resultados de la votación)
        • openstv (libraría que soporta diferentes sistema de voto para hacer recuentos de votos)
        • agora-results (sistema flexible que hace uso de agora-tally para generar resultados un poco más complejos, por ejemplo aplicando criterios de paridad, eliminando candidatos que se hayan retirado, etc)
        • election-orchestra-puppet (sirve para desplegar election-orchestra más fácilmente)
      • además de éstos, hay algunos más antiguos, y algunos más en desarrollo. Además, también usamos librerías externas como la Stanford Javascript Crypto Library por ejemplo.
    • Pregunta 2: ¿Cómo se realiza la comunicación entre los subsistemas?
      • Depende, entre librería, mediante su api. No hemos aun tenido suficiente tiempo como para documentarlo todo como nos gustaría, es un trabajo que queda pendiente. Collaborations are welcome.
      • Principalmente a través de una API http con peticiones y respuestas JSON.
    • Pregunta 3: ¿Qué suceso determina la creación de una nueva rama?
      • Teóricamente se debería crear una nueva rama siempre que se implemente una nueva funcionalidad, para mantener la rama master como estable, pero a día de hoy no seguimos ese procedimiento para agilizar los cambios en votaciones en producción. Aún no hemos sacado una versión v3 como tal, pero ya se ha usado en varias votaciones.
        
        

--
[1] <a href="https://github.com/agoravoting/election-orchestra">https://github.com/agoravoting/election-orchestra</a>
[2] <a href="https://vota.podemos.info/doc/tech_overview_1016.pdf">https://vota.podemos.info/doc/tech_overview_1016.pdf</a>
[3] <a href="https://github.com/agoravoting/agora-core-view/blob/master/INTEGRATION.md#4-los-servidores-de-podemos-recibe-la-petici%C3%B3n-y-devuelve-los-credenciales-solicitados">https://github.com/agoravoting/agora-core-view/blob/master/INTEGRATION.md#4-los-servidores-de-podemos-recibe-la-petici%C3%B3n-y-devuelve-los-credenciales-solicitados</a>
[4] <a href="https://github.com/agoravoting/">https://github.com/agoravoting/</a>
[5] <a href="https://github.com/agoravoting/agora-core-view/blob/master/INTEGRATION.md">https://github.com/agoravoting/agora-core-view/blob/master/INTEGRATION.md</a>