El día que el sistema de voto electrónico Vot.Ar fue vulnerado
El sistema de voto electrónico (conocido como “Boleta Única Electrónica“) Vot.Ar tiene múltiples vulnerabilidades conocidas. La defensa que hasta ahora ensayan tanto la empresa como los múltiples impulsores del voto “fácil y rápido” es que ninguna de ellas ha sido explotada en las elecciones en que se ha utilizado, pero pocos conocen en detalle lo sucedido antes de las elecciones del 5 de julio de 2015 en la Ciudad Autónoma de Buenos Aires. En dicha oportunidad, un aspecto de la seguridad del sistema fue vulnerado, y de no ser por la buena voluntad de quienes descubrieron el problema, las consecuencias podrían haber sido graves.
El mecanismo de transmisión de datos
Antes de proseguir, es necesario explicar cómo funciona el mecanismo de transmisión de los datos de cada mesa para el escrutinio provisorio. En cada centro de votación (escuela), un técnico de la empresa MSA toma una de las máquinas de Vot.Ar, la inicia con un software especial de transmisión y la conecta a Internet (usando la red de la escuela, una conexión 3G/4G, etc.). Luego, utilizando dicho software, el delegado del Tribunal Superior de Justicia toma los “telegramas” (boletas con chip RFID) que le acercan los presidentes de las distintas mesas, los lee con la máquina y esta los transmite a un servidor de MSA, del que luego la autoridad electoral tomará los datos para el escrutinio provisorio.
¿Cómo se realiza la autenticación de cada una de las terminales, para evitar que alguien pueda transmitir datos falsos? Usando certificados SSL. El mecanismo es simple: cada terminal de transmisión dispone de un certificado X.509 y su correspondiente clave privada, mediante la cual se autentica ante el servidor. De esta forma, este último “sabe” que quien envía los datos es quien dice ser. Este mecanismo se utiliza, además, para garantizar la integridad de la información (esto es, que los datos recibidos son iguales a los datos enviados).
El problema
Para que este mecanismo funcione, en cada máquina transmisora debe estar instalada la clave privada correspondiente al certificado que la identifica. Es vital que esta sea mantenida en secreto, ya que quien logre hacerse de ella puede suplantar la “identidad” de una máquina de transmisión, posibilitando el envío de datos falsos de manera indetectable por el servidor. La empresa MSA debería haber utilizado algún medio seguro para distribuir estas claves apropiadamente (evitando que sean interceptadas por terceros). La forma más razonable hubiera sido utilizar los canales de comunicación formales con el Tribunal Superior de Justicia, ya que sus delegados eran los responsables de la transmisión de datos. Pero la solución implementada estuvo lejos de cualquier atisbo de razonabilidad.
¿Cómo solucionó MSA la distribución de certificados y claves? Poniéndolas a disposición de cada técnico a través de una aplicación web. Amén del error de confiar la transmisión de los datos del escrutinio provisorio a personas contratadas a través de consultoras de recursos humanos (con quienes la empresa ni siquiera tuvo contacto presencial), esto se hizo de la peor manera posible: una vez que un técnico obtuviera un certificado de su escuela, podría determinar fácilmente la forma de descargar el resto.
Por ejemplo, cuando el técnico destinado al Instituto Summa ingresaba al sistema, podía descargar el certificado y la clave del siguiente URL:
Y para empeorar aún más la situación, el nombre de usuario de cada técnico en el sistema era su apellido seguido de sus nombres, y su contraseña era su dirección de e-mail. Por increíble que parezca, hasta lo pusieron por escrito en los manuales de capacitación:
En definitiva, la empresa MSA puso en manos de sus técnicos contratados la seguridad de la transmisión de datos del escrutinio provisorio (aún cuando en las escuelas estos tenían vedada la participación en el proceso efectivo de transmisión, que debía ser realizado por los delegados del TSJ). Además, lo hizo implementando un sistema de usuarios y contraseñas fácilmente deducible. Y para empeorar aún más la situación, una vez que alguien (un técnico o alguien que tuviera acceso a esta información) lograba hacerse de un certificado y una clave para la transmisión de datos, podía fácilmente descargar los de todos los centros de votación.
La filtración de los certificados
Como cualquiera (excepto el personal de MSA) podía imaginarse, el sistema de autenticación de técnicos y de distribución de certificados y claves fue vulnerado. Afortunadamente, quienes lo lograron decidieron hacerlo público:
Además, fue publicada la lista completa de las direcciones (URL) para descargar los certificados y las claves en " just paste . it / lzap " (Sin espacios ni comillas). (A quien le interese examinar un certificado, puede descargar uno que fue almacenado el 25 de junio de 2015 en archive . org, incluyendo la clave correspondiente y el certificado de la Autoridad de Certificación.)
El 25 de junio de 2015, faltaban 10 días para la realización de los comicios. Esto le dio a MSA más de una semana para cambiar su esquema de distribución y generar nuevos certificados para los centros de votación (algo para lo que bastaban un par de días). Además, el programador Joaquín Sorianello (uno de los descubridores del fallo) se comunicó inmediatamente con un colega empleado de la empresa para ponerlo al tanto de la situación.
Además de los certificados y las claves, también se filtraron los datos personales de todos los técnicos contratados por MSA, lo que hace sospechar de un problema de seguridad aún mayor en los sistemas de la empresa. La explicación oficial del Gobierno de CABA para todas estas filtraciones, a través de Guillermo Montenegro, fue que “Hackearon el mailing. El sistema es seguro”. Nada más.
Las posibles consecuencias
¿Qué podría haber pasado si quienes detectaron el problema no lo hacían público? Ni la empresa, ni la Justicia Electoral, ni el público en general se habrían enterado de la falla. ¿Qué habría sucedido el domingo 5 de julio luego de las 18 horas, si alguien hubiese utilizado maliciosamente los certificados y las claves expuestas por MSA? Alguien podría haberse conectado al servidor de MSA autenticándose con las claves, simulando ser las máquinas de transmisión de los centros de votación, y transmitido resultados falsos para escrutinio provisorio. Esto hubiera pasado aún si los certificados y claves divulgados 10 días antes no eran los que se usarían el día de la elección: el atacante podría haberlos descargado nuevamente apenas unos minutos antes de las 18 horas.
¿Podría haber prosperado tal adulteración del escrutinio provisorio? Difícilmente. Pero seguramente la noche del domingo no podría haberse realizado el escrutinio provisorio. Lo que es imposible saber es qué tipo de problemas políticos y de disputas podrían haberse suscitado ante esta hipotética situación (inédita en la historia electoral de la CABA). Lo que hubiera quedado perfectamente claro es la precariedad del sistema de transmisión de datos implementado por la empresa MSA y avalado por el Tribunal Superior de Justicia. Pero nada de esto ocurrió, como ya fue dicho, gracias a la buena voluntad de quienes descubrieron el problema.
Las consecuencias reales
La primera consecuencia de la divulgación de los errores de MSA fue que una jueza mandó a bloquear los URL donde fue publicada la información filtrada (algunos proveedores de Internet optaron por bloquear completamente el sitio " just paste . it "(sin espacios por q si no no me dejaban postearlo).
Otra consecuencia fue que la empresa MSA abandonó el uso de certificados SSL para autenticar las máquinas de transmisión: montó una VPN y adquirió 850 tokens USB. A la luz de los resultados, el esquema de seguridad improvisado no funcionó del todo bien. A las 22 horas del domingo 5 de julio, la página del escrutinio provisorio mostraba lo siguiente:
En tanto que a las 2 horas del lunes 6 de julio, podía verse lo siguiente:
En 4 horas sólo se contabilizaron 178 mesas (un 2,4%). Y las restantes 370 mesas (el 5%) no aparecerían en el sistema. Los telegramas de varias escuelas llegaron al centro de cómputo no mediante una VPN, sino con el delegado del TSJ y el técnico de MSA montados arriba de un taxi. Por supuesto, nadie notó este detalle: la elección ya estaba definida y los candidatos habían festejado y reconocido la derrota, según el caso, a las 21 horas. ¿Que habría pasado si la elección hubiese sido reñida?
Un error menor (casi una nota de color, comparado con el resto) fue que la empresa MSA cargó mal los totales de votantes por comuna (intercambiando la 1 con la 15, la 2 con la 14, y así sucesivamente). Como resultado, hasta que notaron el problema, algunas comunas exhibían más votos que votantes.
Pero lo más relevante en el contexto de este artículo ocurrió el día viernes inmediato anterior al domingo electoral: siendo las 21:30 horas, con una orden judicial, la Policía Metropolitana allanó el domicilio del programador Joaquín Sorianello. (Casualmente, el mismo día en que fue publicada la vulnerabilidad “multivoto” de Vot.Ar.)
Así es que la empresa MSA denunció penalmente por daños al programador que 10 días antes de las elecciones los puso sobre aviso de un problema ocasionado por un error (grosero) de ellos, impidiendo que se produjera un daño real (ya no sólo a la empresa, sino a todos los ciudadanos de la CABA). Cabe destacar que en estos casos, la práctica usual es recompensar económicamente a quien informó el fallo (que bien podría haberlo vendido en el mercado negro). La noticia fue publicada en varios medios nacionales (Clarín, La Nación, Telam), como así también en medios internacionales. Incluso el periodista Jorge Lanata en su programa Periodismo Para Todos se ocupó del tema, la misma noche de la elección:
Hoy, a casi 9 meses del allanamiento, el peritaje judicial a los equipos de Sorianello, parece tener ciertos problemas técnicos:
Conclusión
Claramente, el esquema de seguridad montado por MSA para el escrutinio provisorio del 5 de julio en la CABA fue altamente deficiente. También fallaron las auditorías y controles oficiales, que no sólo no detectaron los problemas sino que tampoco reaccionaron al ser puestos estos en evidencia. El sistema de voto electrónico (boleta única electrónica) Vot.Ar fue vulnerado, pero la única causa judicial es el proceso penal que se le sigue al programador que informó a la empresa del grosero error que habían cometido.
Pero nada, ni aún este artículo, parece ser suficiente para hacer reflexionar a quienes impulsan la implantación de este sistema a nivel nacional (a contramano de la tendencia mundial).
Errores Visibles a destacar:
Cómo votar múltiples veces con el sistema Vot.AR:
Aca se demuestra uno de los errores de seguridad más graves encontrados, que permite que cualquier elector malintencionado deposite una boleta en la urna con un chip grabado para alterar el resultado del escrutinio provisorio.
Descripción e impacto del Ataque Multivoto
El presidente de mesa entrega a cada votante inscrito en el padrón una boleta. Esta contiene un tag de identificación por radiofrecuencia (RFID), compuesto de un circuito integrado (“chip”) y una antena. Mediante las máquinas de Vot.Ar, el elector elige los candidatos de su preferencia, y esta selección se graba en el chip y se imprime en la boleta, que es luego depositada en una urna tradicional.
Al finalizar los comicios, el presidente de mesa abre la urna y comienza el conteo de los votos empleando la misma máquina vot.ar mediante otra función del programa. Para efectuar el conteo:
- Apoya la boleta en la máquina -> se contabiliza un voto.
- Apoya la próxima boleta -> se contabiliza otro voto.
Y así hasta finalizar el recuento. El software de la máquina de voto (PC corriendo sistema operativo Ubuntu 14.04) no permite restar votos al recuento sin volver a cero.
Durante nuestra investigación descubrimos que este proceso no está correctamente implementado, y a través de un error de programación es posible grabar el chip mediante un simple smartphone de forma que contenga múltiples votos a un mismo candidato. Cuando el presidente apoye la boleta en la máquina, ocurrirá lo siguiente:
- Una boleta con chip -> se contabilizan múltiples votos.
Detalles técnicos
El pseudo-código del programa que lee y cuenta los votos es:
class Selection(object):
...
def from_string(TAGcontent):
datatag = parse(TAGcontent)
...
candidates = []for e in datatag.vote:
party_code = e["party"]category_code = e
["category"]candidate = CandidateClass.get(category_code,
party_code)candidates.append (candidate)
Primero se leen los datos del chip de la boleta y se almacenan en la variable datatag. Después se interpreta la selección y se agrega a la lista candidatos.
El código NUNCA verifica si hay más de un voto para el mismo candidato por elector, y tampoco limita un número máximo de votos por boleta.
La función parse() falla también en verificar los datos de forma alguna.
Luego, la clase "Count()" suma los votos. Este es el pseudo-código:
class Count(object):
...
def add_selection(self, selection, RFIDserial=None):
if not RFIDserial or not self.serial_exists(RFIDserial):
for candidate in selection.candidates:
self.results[candidate.party_code,
candidate.category_code] += 1
if RFIDserial:
self._RFIDserials.append(RFIDserial)
...
else:
raise RepeatedSerial()
Aquí la lista que contiene los múltiples votos es agregada a la variable 'results'. Nuevamente, no hay mecanismo alguno que detecte votos repetidos.
Falla de Recuento
Este problema podría haberse subsanado en la fase de recuento de votos asegurándose de que la suma de votos coincida con la cantidad de boletas. Como puede verse en la siguiente fotografía de la impresión, esta verificación no se realiza:
Desmintiendo la falacia de que se acaba el clientelismo y se elimina la duda:
El sistema de voto electrónico (conocido como “Boleta Única Electrónica“) Vot.Ar tiene múltiples vulnerabilidades conocidas. La defensa que hasta ahora ensayan tanto la empresa como los múltiples impulsores del voto “fácil y rápido” es que ninguna de ellas ha sido explotada en las elecciones en que se ha utilizado, pero pocos conocen en detalle lo sucedido antes de las elecciones del 5 de julio de 2015 en la Ciudad Autónoma de Buenos Aires. En dicha oportunidad, un aspecto de la seguridad del sistema fue vulnerado, y de no ser por la buena voluntad de quienes descubrieron el problema, las consecuencias podrían haber sido graves.
El mecanismo de transmisión de datos
Antes de proseguir, es necesario explicar cómo funciona el mecanismo de transmisión de los datos de cada mesa para el escrutinio provisorio. En cada centro de votación (escuela), un técnico de la empresa MSA toma una de las máquinas de Vot.Ar, la inicia con un software especial de transmisión y la conecta a Internet (usando la red de la escuela, una conexión 3G/4G, etc.). Luego, utilizando dicho software, el delegado del Tribunal Superior de Justicia toma los “telegramas” (boletas con chip RFID) que le acercan los presidentes de las distintas mesas, los lee con la máquina y esta los transmite a un servidor de MSA, del que luego la autoridad electoral tomará los datos para el escrutinio provisorio.
¿Cómo se realiza la autenticación de cada una de las terminales, para evitar que alguien pueda transmitir datos falsos? Usando certificados SSL. El mecanismo es simple: cada terminal de transmisión dispone de un certificado X.509 y su correspondiente clave privada, mediante la cual se autentica ante el servidor. De esta forma, este último “sabe” que quien envía los datos es quien dice ser. Este mecanismo se utiliza, además, para garantizar la integridad de la información (esto es, que los datos recibidos son iguales a los datos enviados).
El problema
Para que este mecanismo funcione, en cada máquina transmisora debe estar instalada la clave privada correspondiente al certificado que la identifica. Es vital que esta sea mantenida en secreto, ya que quien logre hacerse de ella puede suplantar la “identidad” de una máquina de transmisión, posibilitando el envío de datos falsos de manera indetectable por el servidor. La empresa MSA debería haber utilizado algún medio seguro para distribuir estas claves apropiadamente (evitando que sean interceptadas por terceros). La forma más razonable hubiera sido utilizar los canales de comunicación formales con el Tribunal Superior de Justicia, ya que sus delegados eran los responsables de la transmisión de datos. Pero la solución implementada estuvo lejos de cualquier atisbo de razonabilidad.
¿Cómo solucionó MSA la distribución de certificados y claves? Poniéndolas a disposición de cada técnico a través de una aplicación web. Amén del error de confiar la transmisión de los datos del escrutinio provisorio a personas contratadas a través de consultoras de recursos humanos (con quienes la empresa ni siquiera tuvo contacto presencial), esto se hizo de la peor manera posible: una vez que un técnico obtuviera un certificado de su escuela, podría determinar fácilmente la forma de descargar el resto.
Por ejemplo, cuando el técnico destinado al Instituto Summa ingresaba al sistema, podía descargar el certificado y la clave del siguiente URL:
Y para empeorar aún más la situación, el nombre de usuario de cada técnico en el sistema era su apellido seguido de sus nombres, y su contraseña era su dirección de e-mail. Por increíble que parezca, hasta lo pusieron por escrito en los manuales de capacitación:
En definitiva, la empresa MSA puso en manos de sus técnicos contratados la seguridad de la transmisión de datos del escrutinio provisorio (aún cuando en las escuelas estos tenían vedada la participación en el proceso efectivo de transmisión, que debía ser realizado por los delegados del TSJ). Además, lo hizo implementando un sistema de usuarios y contraseñas fácilmente deducible. Y para empeorar aún más la situación, una vez que alguien (un técnico o alguien que tuviera acceso a esta información) lograba hacerse de un certificado y una clave para la transmisión de datos, podía fácilmente descargar los de todos los centros de votación.
La filtración de los certificados
Como cualquiera (excepto el personal de MSA) podía imaginarse, el sistema de autenticación de técnicos y de distribución de certificados y claves fue vulnerado. Afortunadamente, quienes lo lograron decidieron hacerlo público:
Además, fue publicada la lista completa de las direcciones (URL) para descargar los certificados y las claves en " just paste . it / lzap " (Sin espacios ni comillas). (A quien le interese examinar un certificado, puede descargar uno que fue almacenado el 25 de junio de 2015 en archive . org, incluyendo la clave correspondiente y el certificado de la Autoridad de Certificación.)
El 25 de junio de 2015, faltaban 10 días para la realización de los comicios. Esto le dio a MSA más de una semana para cambiar su esquema de distribución y generar nuevos certificados para los centros de votación (algo para lo que bastaban un par de días). Además, el programador Joaquín Sorianello (uno de los descubridores del fallo) se comunicó inmediatamente con un colega empleado de la empresa para ponerlo al tanto de la situación.
Además de los certificados y las claves, también se filtraron los datos personales de todos los técnicos contratados por MSA, lo que hace sospechar de un problema de seguridad aún mayor en los sistemas de la empresa. La explicación oficial del Gobierno de CABA para todas estas filtraciones, a través de Guillermo Montenegro, fue que “Hackearon el mailing. El sistema es seguro”. Nada más.
Las posibles consecuencias
¿Qué podría haber pasado si quienes detectaron el problema no lo hacían público? Ni la empresa, ni la Justicia Electoral, ni el público en general se habrían enterado de la falla. ¿Qué habría sucedido el domingo 5 de julio luego de las 18 horas, si alguien hubiese utilizado maliciosamente los certificados y las claves expuestas por MSA? Alguien podría haberse conectado al servidor de MSA autenticándose con las claves, simulando ser las máquinas de transmisión de los centros de votación, y transmitido resultados falsos para escrutinio provisorio. Esto hubiera pasado aún si los certificados y claves divulgados 10 días antes no eran los que se usarían el día de la elección: el atacante podría haberlos descargado nuevamente apenas unos minutos antes de las 18 horas.
¿Podría haber prosperado tal adulteración del escrutinio provisorio? Difícilmente. Pero seguramente la noche del domingo no podría haberse realizado el escrutinio provisorio. Lo que es imposible saber es qué tipo de problemas políticos y de disputas podrían haberse suscitado ante esta hipotética situación (inédita en la historia electoral de la CABA). Lo que hubiera quedado perfectamente claro es la precariedad del sistema de transmisión de datos implementado por la empresa MSA y avalado por el Tribunal Superior de Justicia. Pero nada de esto ocurrió, como ya fue dicho, gracias a la buena voluntad de quienes descubrieron el problema.
Las consecuencias reales
La primera consecuencia de la divulgación de los errores de MSA fue que una jueza mandó a bloquear los URL donde fue publicada la información filtrada (algunos proveedores de Internet optaron por bloquear completamente el sitio " just paste . it "(sin espacios por q si no no me dejaban postearlo).
Otra consecuencia fue que la empresa MSA abandonó el uso de certificados SSL para autenticar las máquinas de transmisión: montó una VPN y adquirió 850 tokens USB. A la luz de los resultados, el esquema de seguridad improvisado no funcionó del todo bien. A las 22 horas del domingo 5 de julio, la página del escrutinio provisorio mostraba lo siguiente:
En tanto que a las 2 horas del lunes 6 de julio, podía verse lo siguiente:
En 4 horas sólo se contabilizaron 178 mesas (un 2,4%). Y las restantes 370 mesas (el 5%) no aparecerían en el sistema. Los telegramas de varias escuelas llegaron al centro de cómputo no mediante una VPN, sino con el delegado del TSJ y el técnico de MSA montados arriba de un taxi. Por supuesto, nadie notó este detalle: la elección ya estaba definida y los candidatos habían festejado y reconocido la derrota, según el caso, a las 21 horas. ¿Que habría pasado si la elección hubiese sido reñida?
Un error menor (casi una nota de color, comparado con el resto) fue que la empresa MSA cargó mal los totales de votantes por comuna (intercambiando la 1 con la 15, la 2 con la 14, y así sucesivamente). Como resultado, hasta que notaron el problema, algunas comunas exhibían más votos que votantes.
Pero lo más relevante en el contexto de este artículo ocurrió el día viernes inmediato anterior al domingo electoral: siendo las 21:30 horas, con una orden judicial, la Policía Metropolitana allanó el domicilio del programador Joaquín Sorianello. (Casualmente, el mismo día en que fue publicada la vulnerabilidad “multivoto” de Vot.Ar.)
Así es que la empresa MSA denunció penalmente por daños al programador que 10 días antes de las elecciones los puso sobre aviso de un problema ocasionado por un error (grosero) de ellos, impidiendo que se produjera un daño real (ya no sólo a la empresa, sino a todos los ciudadanos de la CABA). Cabe destacar que en estos casos, la práctica usual es recompensar económicamente a quien informó el fallo (que bien podría haberlo vendido en el mercado negro). La noticia fue publicada en varios medios nacionales (Clarín, La Nación, Telam), como así también en medios internacionales. Incluso el periodista Jorge Lanata en su programa Periodismo Para Todos se ocupó del tema, la misma noche de la elección:
Hoy, a casi 9 meses del allanamiento, el peritaje judicial a los equipos de Sorianello, parece tener ciertos problemas técnicos:
Conclusión
Claramente, el esquema de seguridad montado por MSA para el escrutinio provisorio del 5 de julio en la CABA fue altamente deficiente. También fallaron las auditorías y controles oficiales, que no sólo no detectaron los problemas sino que tampoco reaccionaron al ser puestos estos en evidencia. El sistema de voto electrónico (boleta única electrónica) Vot.Ar fue vulnerado, pero la única causa judicial es el proceso penal que se le sigue al programador que informó a la empresa del grosero error que habían cometido.
Pero nada, ni aún este artículo, parece ser suficiente para hacer reflexionar a quienes impulsan la implantación de este sistema a nivel nacional (a contramano de la tendencia mundial).
Errores Visibles a destacar:
Cómo votar múltiples veces con el sistema Vot.AR:
Aca se demuestra uno de los errores de seguridad más graves encontrados, que permite que cualquier elector malintencionado deposite una boleta en la urna con un chip grabado para alterar el resultado del escrutinio provisorio.
Descripción e impacto del Ataque Multivoto
El presidente de mesa entrega a cada votante inscrito en el padrón una boleta. Esta contiene un tag de identificación por radiofrecuencia (RFID), compuesto de un circuito integrado (“chip”) y una antena. Mediante las máquinas de Vot.Ar, el elector elige los candidatos de su preferencia, y esta selección se graba en el chip y se imprime en la boleta, que es luego depositada en una urna tradicional.
Al finalizar los comicios, el presidente de mesa abre la urna y comienza el conteo de los votos empleando la misma máquina vot.ar mediante otra función del programa. Para efectuar el conteo:
- Apoya la boleta en la máquina -> se contabiliza un voto.
- Apoya la próxima boleta -> se contabiliza otro voto.
Y así hasta finalizar el recuento. El software de la máquina de voto (PC corriendo sistema operativo Ubuntu 14.04) no permite restar votos al recuento sin volver a cero.
Durante nuestra investigación descubrimos que este proceso no está correctamente implementado, y a través de un error de programación es posible grabar el chip mediante un simple smartphone de forma que contenga múltiples votos a un mismo candidato. Cuando el presidente apoye la boleta en la máquina, ocurrirá lo siguiente:
- Una boleta con chip -> se contabilizan múltiples votos.
Detalles técnicos
El pseudo-código del programa que lee y cuenta los votos es:
class Selection(object):
...
def from_string(TAGcontent):
datatag = parse(TAGcontent)
...
candidates = []for e in datatag.vote:
party_code = e["party"]category_code = e
["category"]candidate = CandidateClass.get(category_code,
party_code)candidates.append (candidate)
Primero se leen los datos del chip de la boleta y se almacenan en la variable datatag. Después se interpreta la selección y se agrega a la lista candidatos.
El código NUNCA verifica si hay más de un voto para el mismo candidato por elector, y tampoco limita un número máximo de votos por boleta.
La función parse() falla también en verificar los datos de forma alguna.
Luego, la clase "Count()" suma los votos. Este es el pseudo-código:
class Count(object):
...
def add_selection(self, selection, RFIDserial=None):
if not RFIDserial or not self.serial_exists(RFIDserial):
for candidate in selection.candidates:
self.results[candidate.party_code,
candidate.category_code] += 1
if RFIDserial:
self._RFIDserials.append(RFIDserial)
...
else:
raise RepeatedSerial()
Aquí la lista que contiene los múltiples votos es agregada a la variable 'results'. Nuevamente, no hay mecanismo alguno que detecte votos repetidos.
Falla de Recuento
Este problema podría haberse subsanado en la fase de recuento de votos asegurándose de que la suma de votos coincida con la cantidad de boletas. Como puede verse en la siguiente fotografía de la impresión, esta verificación no se realiza:
Desmintiendo la falacia de que se acaba el clientelismo y se elimina la duda: