← Todos los artículos

280,000 personas ya habían votado en línea antes de que alguien notara el fallo

Durante una elección en vivo con 280,000 votos ya emitidos, dos investigadores encontraron un fallo que la revisión de seguridad oficial había pasado por alto — y el sistema de verificación que debería haberlo detectado también estaba roto.

Es marzo de 2015, y en algún lugar de Nueva Gales del Sur, un votante abre un navegador, sigue un enlace, y emite un voto en una elección estatal. Todo el proceso toma algunos minutos. Sin colas. Sin cabina de votación. Solo un formulario, un clic, y un mensaje de confirmación.

Lo que ese votante no sabe — lo que nadie fuera de un pequeño equipo de investigación sabe aún — es que el código que se ejecuta bajo su navegador se está cargando a través de una conexión con una debilidad de seguridad conocida. Que un atacante de red ubicado entre el votante y el servidor podría, en principio, haber manipulado ese código antes de que la página se cargara. Que el servicio de verificación telefónica separado que el sistema ofrecía como su control de integridad podría ser manipulado en sí mismo. Y que una revisión de seguridad anterior había examinado este sistema y no había encontrado nada de esto.

Para cuando los investigadores J. Alex Halderman y Vanessa Teague hicieron público su hallazgo, aproximadamente 280,000 votos ya habían sido emitidos.

El sistema que se aprobó a sí mismo

El sistema iVote no era un experimento rogue ni una ocurrencia apresurada. Nueva Gales del Sur había invertido en él deliberadamente, ofreciéndolo a votantes que eran ciegos o tenían discapacidades de impresión, los ubicados remotamente, o simplemente preferían la conveniencia de votar en línea. Había pasado una revisión de seguridad oficial previa a la elección. Las autoridades conocían los riesgos de la votación por internet — habían revisado el sistema para identificarlos. Concluyeron que estaba listo.

Una revisión cerrada que aprueba un sistema no es lo mismo que ese sistema siendo seguro.

Esto es lo que la revisión oficial no detectó, según el documento revisado por pares que Halderman y Teague publicaron en E-Vote-ID 2015: iVote cargaba JavaScript externo — código que se ejecuta en el navegador del votante — desde un servidor de análisis sobre una conexión vulnerable a los ataques FREAK y Logjam. Estas eran debilidades TLS conocidas y documentadas que habían sido divulgadas públicamente. Un atacante posicionado en la red explotando esa debilidad podría haber inyectado código malicioso en la página iVote antes de que llegara al votante, potencialmente manipulando cómo se registraba un voto sin el conocimiento del votante. El atacante no necesitaría entrar en los propios servidores de la comisión electoral. Solo necesitaría estar en la posición correcta en la red.

Los investigadores también examinaron el servicio de verificación telefónica de iVote — la característica que el sistema ofrecía como una forma para que los votantes confirmaran que su voto había sido registrado correctamente. Lo que encontraron fue que el servicio en sí era susceptible a manipulación de una manera que podría hacer que un voto manipulado pareciera verificado. La verificación estaba verificando contra una fuente que también podría ser alterada.

Eso no es una red de seguridad. Eso es la ilusión de una.

Lo que "después de que una revisión anterior lo aprobó" realmente significa

Seamos precisos sobre la secuencia de eventos, porque la secuencia es toda la historia.

Se realizó una revisión de seguridad antes de la elección. La revisión no encontró las vulnerabilidades que Halderman y Teague encontraron. La elección comenzó. Los votos se acumularon — eventualmente llegando a aproximadamente 280,000. Luego dos investigadores independientes, trabajando fuera de la comisión electoral y fuera de sus revisores contratados, analizaron el sistema en funcionamiento y encontraron fallos graves. Divulgaron los problemas. Se implementó una solución mientras la votación aún estaba en curso.

En otras palabras: la revisión oficial previa a la elección dio un visto bueno. Dos personas de fuera sin ninguna apuesta institucional en la respuesta encontraron lo que la revisión oficial pasó por alto. Los problemas fueron descubiertos no porque el proceso funcionara, sino porque investigadores independientes decidieron mirar — por su propia iniciativa, durante una elección en vivo.

"Pasó su revisión de seguridad" es una afirmación sobre una instantánea. No es una afirmación sobre el sistema que se ejecuta el día de la elección.

Este es el problema de la instantánea de certificación. Se realiza una revisión en un punto en el tiempo, sobre el código y la configuración que existen en ese momento, utilizando el plan de prueba y el modelo de amenaza que los revisores traían consigo. Si el modelo de amenaza pasó por alto una clase de ataque TLS conocida, esas vulnerabilidades no aparecen en el informe. El sistema cambia ligeramente — una biblioteca de análisis de terceros se actualiza, un parámetro de configuración se desplaza — y la revisión ya no cubre lo que realmente se está ejecutando.

La Corte Constitucional Alemana se enfrentó a una versión de este problema en 2009, cuando dictaminó que la votación electrónica solo es constitucionalmente legítima cuando los ciudadanos ordinarios pueden verificar cada paso esencial sin conocimientos especializados. Los votantes que verifican una pantalla después de hacer clic en "Enviar" y recibir un mensaje de confirmación no pueden hacer esto. Tampoco, resulta, puede un equipo de seguridad preelectoral que no sucede que mire una dependencia externa específica cargada a través de TLS.

El mecanismo de verificación que no verificó

El detalle que merece quedarse contigo un momento es la verificación telefónica.

iVote dio a los votantes una forma de llamar y verificar que su voto había sido registrado como se pretendía. Este es el instinto correcto. La verificabilidad de extremo a extremo — la capacidad para que un votante confirme que su boleta fue capturada correctamente — es un requisito de seguridad genuino, no una característica de marketing. Noruega, Estonia y Suiza han lidiado seriamente con cómo proporcionarlo. El sistema de 2019 de Swiss Post utilizó pruebas criptográficas para ofrecer lo que llamó verificabilidad universal, hasta que investigadores independientes encontraron una puerta trasera en la mixnet que podría generar una prueba convincente mientras ocultaba votos alterados.

El impulso de dar a los votantes una verificación sobre el sistema es exactamente correcto. El problema viene cuando esa verificación se ejecuta en la misma infraestructura que lo que está verificando — o cuando puede ser manipulada por el mismo atacante que podría manipular el voto en sí.

Este no es un riesgo hipotético. Halderman y Teague documentaron que la verificación telefónica de iVote era en sí misma susceptible a manipulación que podría producir una confirmación falsa. Un votante que llamara para verificar su boleta escucharía que todo estaba bien. Un votante cuya boleta había sido alterada por un atacante de red también escucharía que todo estaba bien. El servicio de verificación y la vulnerabilidad vivían en el mismo ecosistema.

Un mecanismo de verificación que puede ser engañado por el mismo ataque que el sistema subyacente no verifica nada. Proporciona comodidad, y la comodidad no es una propiedad de seguridad.

Por qué "independiente" está haciendo todo el trabajo

Aquí está la verdad incómoda sobre el episodio de NSW: nadie en la cadena oficial lo detectó.

No el proveedor. No el equipo propio de la comisión electoral. No los revisores de seguridad contratados. Fue detectado por dos académicos que no fueron solicitados, no fueron pagados, y no recibieron acceso especial a un entorno de prueba. Analizaron el sistema de producción — el que manejaba votos reales de votantes reales — y encontraron lo que el proceso oficial no había encontrado.

Washington, D.C. en 2010 es la comparación útil más cercana. Antes de desplegar un sistema de devolución de boletas por internet para votantes en el extranjero, D.C. realizó una prueba pública abierta e invitó explícitamente al público a atacarlo. Un equipo de la Universidad de Michigan liderado por Halderman obtuvo un control casi completo del servidor piloto en aproximadamente 48 horas, cambió boletas que habían sido emitidas, y dejó la canción de lucha tocando como evidencia de su acceso. D.C. descartó el sistema. No se vieron afectados votos reales. Las vulnerabilidades fueron detectadas porque la prueba era explícitamente abierta — cualquiera podría intentar, y el equipo que lo intentó encontró lo que las pruebas internas cerradas no habían encontrado.

El caso de NSW es la imagen espejo de D.C. Sin prueba pública abierta. Una revisión cerrada que aprobó el sistema. Vulnerabilidades encontradas de todos modos, por investigadores independientes, después de que votos reales ya estaban en el sistema.

La diferencia entre un desastre y un defecto atrapado es a menudo solo si la persona correcta de fuera resultó mirar.

Esa es una frase incómoda, porque significa que la seguridad de una elección puede depender de la iniciativa de investigadores que no son parte del proceso oficial y que fácilmente podrían no haber mirado. También significa que cuando lo hacen y encuentran algo, la respuesta oficial debería ser "gracias y aquí está lo que cambiamos" — no "nuestra revisión ya había aprobado el sistema."

La revisión aprobando el sistema es el punto de datos que debería preocuparte, no tranquilizarte. Te dice que una revisión cerrada no encontró lo que una revisión abierta luego encontró. La respuesta apropiada es preguntar qué más la revisión cerrada podría no haber encontrado.

El problema de la instantánea corre más profundo

Cada sistema de votación certificado en el mundo fue certificado en un momento que ahora está en el pasado.

La Comisión de Asistencia Electoral de EE.UU. certifica sistemas de votación contra las Pautas Voluntarias del Sistema de Votación. Un informe del GAO de 2005 encontró que incluso la infraestructura básica para ese programa de certificación estaba incompleta, años después de que la Ley de Ayuda para Mejorar la Votación la había mandatado. Los estándares se construyen. Los sistemas se prueban contra ellos. Se emite la certificación.

Luego pasa el tiempo. Se descubren nuevas clases de ataque. Las dependencias se actualizan. Las configuraciones se desplazan. Y la certificación, que fue una instantánea de un sistema contra un estándar en un punto en el tiempo, permanece en la pared como una fotografía enmarcada de un edificio que ha sido renovado desde entonces.

El problema más profundo es que ningún proceso de certificación puede tener en cuenta clases de ataque que no estaban en el modelo de amenaza cuando se realizó la revisión. FREAK y Logjam eran debilidades conocidas públicamente cuando iVote estaba en funcionamiento. Estaban en la literatura académica. Tenían nombres. Y aparentemente no estaban en el plan de prueba que aprobó el sistema.

Esta no es una argumentación en contra de la certificación — es una argumentación de que la certificación es necesaria pero no suficiente, y que su suficiencia se degrada con el tiempo. La versión honesta de "este sistema está certificado" es: "este sistema pasó una revisión contra un estándar específico, realizada por un equipo específico, usando un modelo de amenaza específico, en un punto específico en el tiempo. Ninguna de esas cosas está garantizada que permanezca actual."

La solución no es una instantánea mejor. La solución es verificabilidad continua, abierta e independiente — para que la pregunta no sea "¿pasó la revisión?" sino "¿puedes mostrarme las matemáticas?"

Lo que "verificable de forma independiente" realmente requiere

La historia de NSW iVote termina con una solución implementada a mediados de la elección y un sistema que continuó operando. La elección no fue detenida. Los 280,000 votos ya emitidos no fueron re-ejecutados. No había mecanismo para confirmar retrospectivamente si alguno de esos votos había sido alterado antes de la solución.

Esta es la parte difícil de la historia que no se resuelve limpiamente.

El sistema de votación electrónica estonia, que el equipo de Springall, Finkbeiner y Halderman analizó en 2014, al menos ofrecía código fuente parcial para examen independiente. Los investigadores encontraron debilidades graves de seguridad operacional y concluyeron que un atacante bien dotado podría alterar votos de forma indetectable. Estonia disputó las conclusiones. El sistema continuó operando. Disputa y continuación no son lo mismo que resolución.

El sistema de 2019 de Swiss Post fue aún más lejos — publicó su código fuente completo para escrutinio público antes del despliegue en elecciones vinculantes. Investigadores independientes encontraron la puerta trasera en la prueba de mezcla. Las autoridades suizas suspendieron el sistema. Eso es lo más cercano a una historia de éxito en este espacio: código publicado, fallo encontrado, sistema detenido antes de que votos reales fueran afectados.

La progresión de NSW a Estonia a Suiza es una progresión hacia la apertura. NSW: revisión cerrada, fallos encontrados durante una elección en vivo, sin mecanismo para que los votantes verifiquen retrospectivamente. Estonia: apertura parcial, análisis independiente, conclusiones disputadas. Suiza: publicación completa, fallo criptográfico encontrado antes del uso vinculante, sistema suspendido.

La dirección importa. Pero note lo que Suiza requirió para funcionar: no solo publicación, sino criptógrafos con las herramientas y conocimientos para detectar una puerta trasera sutil en una prueba de mixnet. Vanessa Teague — quien trabajó tanto en el análisis de NSW como en el análisis de Swiss Post — es una de un pequeño número de personas en el mundo que puede leer una prueba de mezcla y notar que algo en ella está mal.

"Verificable de forma independiente" no es lo mismo que "técnicamente posible para que cualquier ciudadano lo verifique." Para votación por internet criptográfica, la verificabilidad independiente genuina requiere participación activa y abierta de personas calificadas de fuera — y un proceso que la solicita activamente, no uno que la tolera solo después de que investigadores deciden por su propia iniciativa mirar.

El tribunal electoral de Brasil ejecuta un programa oficial de prueba de seguridad pública cada ciclo electoral, invitando a cualquier ciudadano calificado a intentar romper el sistema y arreglar lo que encuentren. Ese no es un modelo perfecto — prueba sistemas específicos en configuraciones específicas en puntos específicos en el tiempo, y los problemas que no aparecieron en la prueba pueden existir aún en el sistema de producción. Pero es estructuralmente mejor que una revisión cerrada, porque es abierto, adversarial, e institucionalizado en lugar de ocasional y accidental.

Lo que sigue sin ser verificable

Aquí está lo que ni la revisión posterior a la elección oficial de NSW ni el documento de investigación independiente pueden decirte: si alguno de los 280,000 votos emitidos antes de que se implementara la solución fue alterado.

No por mala fe. No porque alguien esté ocultando algo. Sino porque el sistema no fue diseñado para permitir que esa pregunta sea respondida después del hecho. No hay registro verificable por votante que fue comprometido antes de que el voto fuera presentado y que pueda ser comparado después. No hay pista de auditoría criptográfica que un votante pueda examinar para confirmar que su boleta fue contada como se emitió. El servicio de verificación telefónica que podría haber servido esa función podría haber sido comprometido en sí mismo.

Esta es la brecha que ninguna declaración oficial puede cerrar. Las autoridades pueden decir — y dijeron — que no están conscientes de que algún voto haya sido alterado. Esa es una declaración sincera. También es una infalsable. "No consciente de" y "no sucedió" están separados por todo el ancho de la pregunta.

El estándar de la Corte Constitucional Alemana vale la pena repetir aquí, porque se aplica con toda la fuerza: una elección es solo legítima cuando los pasos esenciales desde boleta a resultado pueden ser verificados por ciudadanos sin conocimiento especializado. Para un voto en línea que carga código sobre una conexión vulnerable, el votante no puede verificar que el código que recibió fue el código que el servidor envió. Para un servicio de verificación que puede ser manipulado en sí mismo, el votante no puede confirmar que la confirmación es real. Para un sistema sin pista de auditoría retrospectiva, los funcionarios que lo ejecutaban no pueden confirmar que no se cambiaron votos.

La pregunta correcta no es "¿encontramos alguna evidencia de manipulación?" La pregunta correcta es: "¿podría alguien haberla encontrado si la manipulación hubiera ocurrido?"

Si la respuesta a la segunda pregunta es no, la primera pregunta no proporciona ninguna garantía en absoluto.

Explora cómo esta brecha aparece en sistemas alrededor del mundo →

Lee la versión de dos minutos →

Ve el patrón completo en casos documentados →

Fuentes

Ver todos los artículosExplora las brechas