¿Meter las autorizaciones en el voto encriptado?

[al.r...@gmail.com]

Hola, mando esto a la lista porque quiero que me quede claro si esto se esta haciendo ya o no, que creo que no.

Casi toda la critica que se ha hecho al proceso de voto de Podemos en lo que Agora atañe es que era necesario confiar en la polling station, porque habia la posibilidad de stuffing.

Usease, una vez el votante ha mandado su identidad de voto, se podria votar en su nombre, tirar su voto real a la basura y o bien perder el hash en la esperanza de que no lo verifique, o bien incluso mandarle el hash del voto falso. 

El problema se minimiza localmente si el hash lo genera el javascript y por tanto no la polling station. No se si se hace asi, pero aunque lo hiciera es un apaño local.

La solucion mas obvia es que la polling station nunca reciba la autorizacion, y que esta viaje encriptada. Si se quiere minimizar la recepcion de votos no autorizados, se puede tener dos autorizaciones, una desencriptada para que la polling station decida si recibe o no el voto, y otra encriptada que viaja dentro del voto.

¿Esta implementada esta solucion, o al menos en algun sitio en el roadmap?

Entiendo que exige añadir una nueva clave, pero no una nueva autoridad: el poseedor obvio de la nueva clave es el agente censal. Cuando se envia el voto, la fecha y la autorizacio de voto se encapsulan con el voto mismo y todo esto se encripta con la nueva "clave censal". Cuando terminan las votaciones y una vez estan los ficheros de votos, o al menos sus sha256, en posesion de varios agentes, se revela la clave censal y se pueden descartar los votos invalidos y, mirando la fecha, los obsoletos.

A partir de ahi el sistema de mixing sigue tal cual, garantizando la anonimidad.

¿Me pierdo algo? ¿Se ha hecho asi y simplemente se ha explicado mal en los documentos? 

Saludos,

Alejandro

[Félix Robles]

Yo lo que he entendido del protocolo HMAC es que se hace el hash de la clave secreta más el mensaje. Los usuarios no tienen clave secreta por lo que quien tiene que generar el hash no son ellos sino el servidor de Podemos. Al menos eso es lo que he entendido yo, luego ya pueden rectificar eso los desarrolladores si me equivoco.

En otras palabras, esto sirve para que el servidor de Podemos pueda autenticar el mensaje del usuario, pero no al revés.

--
You received this message because you are subscribed to the Google Groups "Ágora Voting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agora-voting...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[al.r...@gmail.com]

Pues quizas es un problema de que los documentos no se explican bien. Porque despues de estas semanas yo el proceso que he entendido es que el login en Podemos sirve para que este emita una identificacion unica que autoriza al votante en esa eleccion, y que con esa identificacion se le redirige al servidor de votacion y ya no se le vielve a ver el pelo en el de Podemos.

Y se me hace raro que algo tenga que ocurrir forzosamente en el servidor, salvo una firma para doble validacion, que me huelo que tampoco esta implementada. Usease, un proceso de entrega que parece logico seria:

- con las claves publicas de los agentes que van a contar la votacion, el cliente cifra el mensaje.

- con la clave publica del agente censal el cliente cifra su autorizacion personal de voto, la fecha, y el cifrado anterior.

- el cliente calcula el hash de este mensaje, y manda al servidor mensaje y hash.

- el servidor archiva el mensaje, recalcula el hash y lo firma. Esto, un hash firmado, es lo que valdria como prueba de voto, si el cliente tiene que entregarlo en el curro o algo asi. 

En cambio la documentacion parece implicar que solo se hace el primer paso, y que el calculo del hash es en el servidor, emulando en cierto modo el paso cuatro. Digo en cierto modo porque un hash asi como asi, sin firma digital, no prueba nada. Si luego el usuario no lo encuentra en el tally, es su palabra contra la de una string alfanumerica.

[Eduardo Robles Elvira]

2014-11-06 17:21 GMT+01:00 Al.R...@gmail.com <al.r...@gmail.com>:
> Pues quizas es un problema de que los documentos no se explican bien. Porque
> despues de estas semanas yo el proceso que he entendido es que el login en
> Podemos sirve para que este emita una identificacion unica que autoriza al
> votante en esa eleccion, y que con esa identificacion se le redirige al
> servidor de votacion y ya no se le vielve a ver el pelo en el de Podemos.
>
> Y se me hace raro que algo tenga que ocurrir forzosamente en el servidor,
> salvo una firma para doble validacion, que me huelo que tampoco esta
> implementada. Usease, un proceso de entrega que parece logico seria:
>
> - con las claves publicas de los agentes que van a contar la votacion, el
> cliente cifra el mensaje.
> - con la clave publica del agente censal el cliente cifra su autorizacion
> personal de voto, la fecha, y el cifrado anterior.
> - el cliente calcula el hash de este mensaje, y manda al servidor mensaje y
> hash.
> - el servidor archiva el mensaje, recalcula el hash y lo firma. Esto, un
> hash firmado, es lo que valdria como prueba de voto, si el cliente tiene que
> entregarlo en el curro o algo asi.
>
> En cambio la documentacion parece implicar que solo se hace el primer paso,
> y que el calculo del hash es en el servidor, emulando en cierto modo el paso
> cuatro. Digo en cierto modo porque un hash asi como asi, sin firma digital,
> no prueba nada. Si luego el usuario no lo encuentra en el tally, es su
> palabra contra la de una string alfanumerica.

Buenas:

Vamos por partes:

# Cómo funciona en Agora Voting

El hash del voto es generado en javascript en cliente antes de
enviarse al servidor de Agora Voting. Se muestra después y por eso es
fácil confundirse, pero eso es por cuestión de usabilidad.

Respecto de los credenciales, en el sistema actual hace falta que
tanto Agora Voting como el "agente censal" se compinchen para hacer
ballot stuffing, dado que el id del votante es un string
pseudoaleatorio (en realidad en el caso de Podemos es un hash sha256
de varias cosas, según les propusimos en la documentación [1]) que
sólo el agente censal sabe generar (y Agora Voting por no). Por tanto,
si el agente censal le reta a Agora Voting a desvelar los ids de los
votantes, el agente censal podría detectar si Agora Voting ha hecho
ballot-stuffing.

# Firma de votos por Agora Voting

El hecho de firmar votos por parte del servidor de Agora Voting que
recibe los votos podría realizarse, y lo hemos contemplado de cara al
futuro. Sirve para tener una característica de "dispute freeness", es
decir poder resolver disputas como la que propones (ej: un votante
afirma que su voto no ha sido contado). Firmar un voto con un sistema
de clave pública/privada como propones implica la necesidad de que el
votante se guarde un chorizaco de texto más largo que un hash.

Pero una forma de realizarlo sería dar al votante un segundo hash del
voto. Este hash sí que vendría del servidor, y sería el hash de el
hash1 + un secreto que revelaría Agora Voting al final del proceso
(por tanto es demostrable, es lo que criptográficamente se llama un
"commitment"). De esa forma, cualquiera que diga que su voto no ha
sido contado, podría decirlo antes de que Agora Voting revele el
secreto, y cuando Agora Voting lo desvele, todo el mundo podría ver
qué votos habían sido firmados por Agora Voting con ese secreto.

# Credenciales por parte del Agente Censal

Lo que propones de cifrar usando la clave pública del agente censal no
sirve para evitar que Agora Voting haga Ballot Stuffing, porque Agora
Voting también conoce dicha clave al ser, ejem, pública. Para poder
demostrar que un voto tiene los credenciales adecuados, hace falta
tener un credencial (anónimo) firmado por la autoridad censal. Este
credencial, de nuevo podría ser un hash por ejemplo, y aplicar un
procedimiento parecido al anteriormente explicado para cuando Agora
Voting firma que ha recibido un voto. Pero claro, de nuevo, tenemos
más y más hashes: terminamos volviendo loco al usuario. Pero incluso
es teóricamente posible hacerlo con múltiples autoridades de censo,
por ejemplo, lo cual añade aun más complicación.

--

Al final, en el esquema actual, para el censo tienes que:
1. Tienes que confiar en que el Agente censal no haga ballot stuffing.
Dado que dicho agente es quien decide cual es el censo, esto resulta
bastante razonable.
2. Agora Voting no puede hacer ballot-stuffing a menos que se
compinche con el Agente Censal, ver punto anterior.
3. Para las disputas del tipo "mi voto no ha sido contado", hay que
confiar en la palabra de Agora Voting dado que los votos no son
firmados (o hasheados como dije arriba, que es una forma de firma).

El punto 2 no añade más necesidad confianza que el 1, que de por sí
parece razonable. Es el 3 el que podría mejorarse, a costa de
disminuir un poco la usabilidad de los localizadores haciéndolos más
largos.

Saludos,
--
[1] https://github.com/agoravoting/agora-core-view/blob/master/INTEGRATION.md

--
Eduardo Robles Elvira @edulix skype: edulix2
http://agoravoting.org @agoravoting +34 634 571 634

[Félix Robles]

Ah, entonces yo estaba equivocado (esto me pasa por leer los documentos en líneas verticales a lo japo). Precisamente lo que queda por implementar es eso que digo de que el servidor hashee el voto + clave (o, como dice Edulix, hashear el hash1 +secreto).

[al.r...@gmail.com]

Bueno, el docmento no se explica bien, pero yo tampoco :-D

El jueves, 6 de noviembre de 2014 18:36:11 UTC+1, Eduardo Robles Elvira escribió:

 El hash del voto es generado en javascript en cliente antes de
enviarse al servidor de Agora Voting. Se muestra después y por eso es
fácil confundirse, pero eso es por cuestión de usabilidad.

Perfecto aqui. Y me alegra que os hayais planteado lo de la condicion de evitar la disputa.
En algun momento tendreis que implementarlo, sobre todo si comienza a haber
verificadores independientes, que pudieran ser engañados.

Respecto de los credenciales, en el sistema actual hace falta que
tanto Agora Voting como el "agente censal" se compinchen para hacer
ballot stuffing, dado que el id del votante es un string
pseudoaleatorio (en realidad en el caso de Podemos es un hash sha256
de varias cosas, según les propusimos en la documentación [1]) que
sólo el agente censal sabe generar (y Agora Voting por no). Por tanto,
si el agente censal le reta a Agora Voting a desvelar los ids de los
votantes, el agente censal podría detectar si Agora Voting ha hecho
ballot-stuffing.

Y aqui o la documentacion es confusa o a mi no se me enciende la luz todavia.

En algun documento se dice que esa id es enviada al sistema de votacion por separado, y de hecho
antes que el voto. Se dice que el sistema de voto de agora recibe la ID, verifica su validez
para esa votacion, y en ese momento envia la papeleta al votante.

Si eso no se hace, corregid la documentacion. Es posible que no se haga y que por eso no se me entienda
el resto de lo que estoy diciendo.

Si se hace, el sistema de votacion tiene la id sin necesidad de compincheo con el documento. Si el usuario
decide, tras ver la papeleta, no votar, el servidor  puede votar en su lugar. Incluso podria tomar riesgo y
votar en lugar de gente que si que ha mandado su voto, esperando que nunca verifiquen el hash.

# Credenciales por parte del Agente Censal

Lo que propones de cifrar usando la clave pública del agente censal no
sirve para evitar que Agora Voting haga Ballot Stuffing, porque Agora
Voting también conoce dicha clave al ser, ejem, pública.

Er, no, lo que queria decir es que la ID del votante fuera cifrada junto con el voto
con esa clave, para que Agora Voting (el receptor del voto) no supiera nunca quien votaba
y por tanto no pudiera suplantarlo. Agora voting no va poder crear un voto
valido porque nunca recibe la ID del votante fuera de ese paquete.

Esto es, realmente los votos se guardan sin tocar y sin identificar hasta el final de la votacion.
Una vez finalizada, se bloquea cualquier posible modificacion del fichero que contienen los votos
y se descifra esa clave, con lo que cada voto aparece explicito: fecha o numero de secuencia,
id secreta de votante, y voto encriptado completo. En ese momento se descartan los votos
no autorizados y los de fecha posterior. Eso lo meteis a las mixnets y sale el voto perfectamente
anonimo.

[al.r...@gmail.com]

Upps, "con el agente censal"

[al.r...@gmail.com]

Me vuelvo a corregir, ahora que puedo ver una votacion en activo, para que conste en acta. Da la impresion de que hay mas chequeo de los que habiamos hablado, al menos ahora :-)

-- El redirect desde el agente censal al nodo de votacion separa los datos mediante #, asi que el navegador no se los regala a vota.

https://vota.podemos.info/#/election/1110/vote/b5---hash0---ff/voter-1110-9804....

El scripit usa el segundo campo, el voterID, para -

- pedir los datos de la votacion a la api:  /api/v1/ballotbox/election/1110/config/9804...

- enviar el POST del voto: /api/v1/ballotbox/election/1110/vote/9804

asi que en principio el primer campo, que yo he llamado hash0, no lo ve nunca el servidor de voto. 

¿Se esta mandando ese campo junto con el voto encriptado? Si asi fuera, ya seria perfecto, porque tendriamos el hash que el servidor de voto nunca ve, y por tanto impide que se puedan stuffear votos. 

Lo unico que no entiendo es la header Authorization, que ademas del voter id manda otro hash... supongo que ese viene cuando se carga la pagina e impide que un cliente no autorizado por la pagina pueda conectarse a la API, ¿no?

¿Era todo asi la ultima vez? Si lo era, es mejor de como explica la documentacion.