Get best of the week

Lecciones de votación electrónica en la Moscú City Duma 2019

Continuamos hablando sobre las actividades de DIT Moscú (ver nuestras publicaciones anteriores ), pero al mismo tiempo pasamos al siguiente tema, que de repente se ha vuelto relevante y ha cobrado impulso: el tema de la votación electrónica.

Si el año pasado, el voto remoto de los ciudadanos se consideró más como una curiosidad o un experimento, de lo que se sacarán conclusiones más adelante, entonces, en 2020, todos descubrimos de repente que esta es una realidad que enfrentaremos pronto y en su totalidad. En gran medida, las restricciones de cuarentena provocaron esto: la celebración de elecciones se puso en tela de juicio y la vida de los partidos políticos se detuvo.

En general, la demanda se encontró con la oferta, y las facturas cayeron. A los partidos se les permitió llevar a cabo primarias a través de Gosuslugi / ESIA, las regiones informan una tras otra sobre el deseo de organizar el DEG (votación electrónica remota) en septiembre en las elecciones locales.

Afortunadamente o desafortunadamente, la legislación por sí sola no es suficiente, también necesitamos una implementación técnica, que no es tan simple. Alguien cree que todo se hizo en Moscú el año pasado (¡incluso había una cadena de bloques allí!), Alguien: que DEG es generalmente imposible de implementar a un nivel que no permita falsificaciones masivas, y por lo tanto, es necesario abandonar DEG en principio.

Por lo tanto, decidimos dedicar una pequeña serie de artículos y reuniones al análisis de estos temas:

  1. Alexey Scherbakov - "Lecciones de la votación electrónica en la Duma de la ciudad de Moscú de 2019"
  2. Oleg Artamonov - " Voto electrónico remoto: arquitectura de un sistema electoral confiable "
  3. Mesa redonda "Presione el botón: teoría y práctica del voto electrónico"



Comenzaremos el primer artículo en este momento, y colgaremos el segundo y el anuncio de la mesa redonda mañana (y agregaremos enlaces aquí).

Hablando estrictamente, este no es un artículo, sino un texto ligeramente literalmente editado del discurso homónimo de Alexei Shcherbakov (alexeishch) en nuestra conferencia el 5 de marzo de este año.

Alexey es un experto invitado del equipo de Roman Yuneman en la preparación del informe “ Votación electrónica. Riesgos y vulnerabilidades ", desarrollador principal de backend en FoodPlex.

El informe explica cómo exactamente la votación electrónica remota se organizó técnicamente en las elecciones al MHD en 2019, cuáles fueron las ventajas y desventajas tanto en las soluciones técnicas como en el trabajo con grupos de expertos.

Además de este texto, también puede leer dos artículos más ya publicados en Habré:


Si prefiere video o audio, puede ver el informe completo en YouTube .

***


Hola, mi nombre es Alexei Shcherbakov, fui un experto en el equipo invitado de Roman Uneman en la votación de Moscú. Bueno, en general, antes de hablar sobre el voto en sí, vale la pena decir cómo sucedió esto en general.



Todo comenzó en marzo de 2019, cuando se anunció el experimento, luego en mayo se aprobó una ley de votación, y la votación en sí tuvo lugar el 8 de septiembre en tres distritos de Moscú. La votación se realizó por Internet durante 12 horas.

El sistema en sí fue construido sobre la base de la cadena de bloques Ethereum por Parity. El esquema de encriptación de El Gamal también se usó allí. Graylog usó el sistema de registro y se utilizó algún tipo de implementación AMQP para transferir datos entre mensajes, suponemos que lo más probable es que fuera RabbitMQ, solo como un estándar empresarial. El sistema en sí se veía así: la



mayor parte del sistema estaba fuera del Departamento de Tecnología de la Información de Moscú (DIT) [ este es un punto muy importante, ya que solo DIT Moscú se comunicó con expertos externos - aprox. ed. ], pero la cadena de bloques estaba con ellos. Trabajaron junto con el portal del Servicio del Estado. Descripción de cómo se creó este sistema, DIT de Moscú publicado en Habr. Y ya hablaron allí en particular que tenían problemas, básicamente, solo durante una hora, alrededor de 400 personas se vieron afectadas por esto.



Realizamos un análisis de datos basado en la descarga de blockchain, que fue presentado por Medusa. Y examinaron por separado los testimonios de testigos, que ya fueron recopilados directamente por observadores en los colegios electorales. Era un sitio electrónico, donde se fotografiaron las lecturas en las pantallas, más adelante les contaré más.



Antes de hablar sobre el análisis que se realizó, les contaré cómo abordamos la tarea. Si yo mismo diseñara este sistema, usaría ciertos estándares para diseñar un sistema de alta disponibilidad. En particular, las métricas se utilizarían para monitorear directamente el estado del sistema. Para comprender que algunos problemas están comenzando y responder rápidamente a ellos. Y además del equipo que debería hacer todo esto, los propios observadores deben verlo, es decir, los observadores deben comprender de alguna manera que algo está yendo mal. Y la comisión electoral del distrito electoral, que estaba ubicada en este distrito electoral, también tenía que entender qué estaba yendo mal si algo salía mal de repente.



En nuestro caso, la métrica de tiempo para calcular bloques blockchain se veía así. Muestra varios problemas por separado, los primeros problemas asociados con la detención de la cadena de bloques, estas son las tres primeras zonas. Y otra zona es un problema desconocido que no vemos específicamente en esta métrica. Y al final vemos una degradación suave que ocurrió hasta el final de la votación.



Si consideramos la segunda métrica, el número de transacciones por bloque, entonces por ellas vemos el problema con más detalle. En primer lugar, vemos que en las áreas de cierre no se registraron transacciones. En nuestra zona sospechosa, vemos muy pocas transacciones, y luego vemos un momento interesante cuando cambia la naturaleza de la grabación de datos de blockchain. ¿Cuál es la razón para esto? Inicialmente, cuando se escribieron los datos, se escribieron en un cierto intervalo, esto se hizo para que fuera imposible determinar exactamente qué persona votó en el momento de la votación. Los datos se acumularon y se volcaron en la cadena de bloques. Sin embargo, luego de algún tipo de reconfiguración de blockchain, los datos comenzaron a grabarse al azar. Es decir, se realizó alguna operación, pero no podemos decir con precisión sobre la base de esta métrica qué hizo exactamente el DIT. Pero podemos decirque en este caso, DIT de alguna manera interfirió con el sistema.



En función de estas métricas, podemos calcular el tiempo durante el cual se detuvo la cadena de bloques. En áreas de operación estable, el tiempo de bloqueo fue de aproximadamente 4 segundos. En consecuencia, podemos calcular en las zonas de detención cuántos bloques caben durante 4 segundos y cuánto se detuvo el tiempo de bloque restante. Y en base a esto, obtenemos un límite inferior por un tiempo de parada de 2 horas. Este es el momento en que la cadena de bloques no funcionó completamente .



Además, todavía tenemos otra zona en la que los datos no llegaron a la cadena de bloques. En total, todas estas zonas de falla toman 4 horas. La zona de degradación dura aproximadamente 6 horas, comenzó después del almuerzo y continuó hasta el final de la votación. Debido al hecho de que no monitorearon la cadena de bloques de ninguna manera, ni siquiera sospecharon que hubiera algún problema. Además, las personas que estaban presentes en la mesa electoral, parte de la comisión electoral, dijeron que todo lo que podían hacer era sentarse en el sofá y ver lo que sucedía en la pantalla. Es decir, no entendieron lo que estaba sucediendo y aprendieron sobre algunos problemas exclusivamente de los medios. No tenían herramientas para observar el problema .

Además, había un punto interesante: los observadores tenían que tener acceso a la cadena de bloques en sí. Es decir, se les prometió que tendrán un nodo de observación especial y podrán acceder directamente a la cadena de bloques, realizar operaciones en ella y ver qué sucede. ¡Pero esta oportunidad les fue quitada! ¿Por qué? Poco claro. Y las estadísticas simplemente se mostraban en la pantalla.



Así es como se veían las pantallas, solo hay cuatro posiciones: el clásico "embudo de ventas", cuando tenemos el número de personas que fueron a la página de votación, iniciaron sesión, recibieron una boleta y votaron, y disminuye con cada paso.

Aquí hay un punto muy importante: la vida del boletín. Si el votante no tuvo tiempo de completar la boleta en 15 minutos, entonces se consideró cancelado. Y las estadísticas en sí también fueron a intervalos de 15 minutos. Es decir, si nuestro votante no pasó por alguna sección del embudo en 15 minutos, entonces podemos decir con confianza que en la siguiente etapa de estadísticas no se tuvo en cuenta. Y en cada etapa tenemos una cantidad menor. Gracias a esto, fue posible rastrear anomalías interesantes de estadísticas.



Este embudo se muestra aquí, los colores indican los tiempos de mal funcionamiento de blockchain. Aquí hay anomalías interesantes, por ejemplo, cuando la línea roja cruza sobre la amarilla: este número de boletas emitidas se ha convertido en más que el número de personas que han ingresado ingresando el código de SMS. Es físicamente imposible simplemente, para recibir un boletín informativo, debe ingresar un código. Y esto sucedió en el área de dos horas.



Esta es una comparación de las estadísticas obtenidas de los observadores y las estadísticas obtenidas de la descarga de la cadena de bloques. Como puede ver, prácticamente coinciden, pero hay una ligera diferencia cuando, aparentemente, hubo pequeños problemas en las estadísticas en el front-end. Esto nos da la oportunidad de decir que las estadísticas obtenidas por observadores independientes y las estadísticas obtenidas de la cadena de bloques basadas en la carga son casi las mismas, excepto en la etapa en que tuvimos algunos problemas.

Además de las estadísticas, tenemos una grabación de audio interesante : el tiempo es de aproximadamente 17 horas, unas 2.000 personas votaron, uno de los representantes de la Administración de Información de Moscú dice qué intervenciones realizaron en un sistema de trabajo. En particular, dice que alrededor de 900 personas recibieron repetidamente SMS para su autorización.



Esto nos dice, en primer lugar, que debido al sistema de registro que utilizaron, el DIT de Moscú podría violar el secreto del voto . Podrían comparar el tiempo de votación, el estado de la boleta y el número de teléfono, ¡lo cual es muy importante! Identificaron personas que tenían problemas, identificaron sus números de teléfono y enviaron SMS repetidos. El número de estas personas es aproximadamente el 40% de todos los votantes en esta mesa electoral. La diferencia entre los dos candidatos, el primero y el segundo, ascendió a solo 84 personas, mientras que para 900 personas ni siquiera podemos decir cuál fue su resultado. Porque se tomó alguna medida sobre ellos.No podemos decir que estos votos fueron manipulados, pero podemos decir que 900 personas tuvieron problemas, no podemos decir por quién votaron y si votaron en absoluto. Es decir, el número de personas que encontraron problemas es diez veces mayor que el número de personas que separaron a un candidato de la victoria.

El repositorio de datos y el código utilizado para el análisis se pueden encontrar en este enlace .

También analizamos el código que se utilizó para la votación en sí. Esperábamos que la mayoría de las operaciones tuvieran lugar directamente en la cadena de bloques y que el código se publicara. Recibimos contratos inteligentes, un código de formulario y un código responsable de enviar el mensaje. Pero había partes que seguían siendo desconocidas, porque se llevaron a cabo al lado de otro Departamento, el portal mos.ru ya.



¿Qué se encontró de manera interesante en el código? Resultó que no limitó la capacidad de una persona para votar en diferentes distritos. Este es un punto interesante, estaba a merced del backend, que se encontraba en otro lugar y cuyo código fuente no podíamos ver.No está claro por qué el sistema usó blockchain, ya que aún no controlaba todo, podría reemplazarse por una base de datos normal . Bueno, el código mágico se agregó al código del formulario solo un día antes de la votación, lo que permitió incluir un script adicional en el formulario utilizando una variable en el lado del backend, ¡lo cual es muy interesante! ¿Por qué hicieron esto? De hecho, esta es la capacidad de ejecutar código arbitrario al momento de votar en el dispositivo del usuario .



La criptografía también fue un punto interesante. Inicialmente, eligieron el cifrado de 256 bits, aunque en 1999 se propuso utilizar 768 bits para este esquema, y ​​hace 10 años se ofrecieron 1024 bits. Y si ahora abre las recomendaciones de la Unión Europea, habrá un requisito de "al menos 1024 bits", pero si se requiere protección antes del año 2030, se recomienda utilizar 3072 bits. También hay un punto interesante en cómo calculan la entropía. Está claro que las personas no entendían completamente por qué necesitaban todo esto .

¿Qué puedo decir sobre este sistema?

En primer lugar, el DIT de Moscú no pudo proporcionar al menos un 90% de rendimiento . En general, se cree que un sistema de alta disponibilidad, debería tener al menos el 90% del tiempo. Es decir, ni siquiera podemos decir que ella estaba trabajando.

En segundo lugar, se realizaron operaciones en el sistema de producción que nadie controlaba de ninguna manera, nadie podía entender lo que estaba sucediendo. Si nos fijamos en la audiencia de la corte [para apelar los resultados electorales - aprox. ed. ], resulta que ni las personas, ni los observadores, ni la propia comisión entendieron lo que estaba sucediendo . Aún así, era necesario prepararlos de alguna manera para el procedimiento en sí, que estaba teniendo lugar.

En lugar de una conclusión


No queremos decir que las elecciones electrónicas son necesariamente un desastre, problemas constantes, soluciones técnicas extrañas y un malentendido de lo que está sucediendo en este momento.

Sin embargo, como vemos en este material, la cuestión de la confianza en los resultados de la votación era esencialmente una cuestión de confianza en sus organizadores, cuya interacción resultó ser muy ambigua. Nos parece que esto responde a la pregunta muy actual de si el Sistema de Información e Información de Moscú tiene suficiente experiencia para escalarlo a todo Moscú, y aún más a todo el país, y a la pregunta de si es posible simplemente tomar algún tipo de "voto" con blockchain ”, ejecútelo en el servidor y comience a realizar elecciones.

De la misma manera, ¿es posible construir un sistema de votación digital en general, cuya credibilidad esté garantizada por su propia arquitectura y no por la honestidad de sus autores? Hablaremos en el próximo artículo.

More articles:


All Articles