← Todos los artículos14 de noviembre de 2026

¿Y si el software cambia después de haber sido probado?

El software de votación pasó todas las pruebas. Luego alguien entró en una oficina electoral, copió todo el sistema en un disco duro y se fue. ¿Qué significa "certificado" después de eso?

Es la mañana del 7 de enero de 2021, y un equipo de análisis forense informático entra por la puerta principal de la oficina electoral del Condado de Coffee, Georgia —dejado entrar por funcionarios del condado que tenían todas las llaves. No son investigadores. No son auditores. Pasan las siguientes horas copiando todo: el servidor del Sistema de Gestión Electoral, los dispositivos de marcado de papeletas, el escáner de alta velocidad, el software de votación Dominion de Georgia a nivel estatal. Todo. Se van con todo en discos duros.

El sistema que copiaron había sido probado. Había sido certificado. Había ejecutado una elección real.

Nada de eso detuvo lo que pasó después.

Qué "certificado" realmente certifica

Antes de que cualquier sistema de votación toque una papeleta real, pasa por un proceso de certificación. Un laboratorio de pruebas examina el hardware y el software. Verifica que la máquina haga lo que dice la documentación. Emite un informe. La jurisdicción acepta el sistema.

Esto suena exhaustivo. Y para una instantánea en el tiempo, lo es.

Pero la certificación es una fotografía, no una cámara de vigilancia. Captura el sistema tal como existía el día en que el laboratorio lo examinó. Lo que le sucede a ese sistema entre el laboratorio y tu lugar de votación —y entre elecciones— es una pregunta completamente diferente, y el proceso de certificación en sí apenas la responde.

La brecha crítica es esta: nadie demuestra rutinariamente, de una manera que el público pueda verificar de forma independiente, que el software ejecutándose el Día de Elecciones es el mismo software que pasó la prueba.

Esa brecha tiene un nombre. La llamamos el problema del intercambio de software antes de la elección. No es teórico.

Condado de Coffee: cuando las llaves van a las personas equivocadas

El episodio del Condado de Coffee, documentado en deposiciones en el caso federal Curling v. Raffensperger y posteriormente en una acusación del Condado de Fulton, es la demostración más clara del mundo real de por qué el secreto es una estrategia de seguridad frágil para el software electoral.

La integridad del sistema se basaba, en parte, en la suposición de que solo las personas autorizadas tendrían acceso a él. Esa suposición se rompió en el momento en que un funcionario del condado dejó entrar al equipo de análisis forense. Varias personas conectadas con la violación más tarde se declararon culpables. La oficina del Secretario de Estado de Georgia la describió como acceso no autorizado en violación de la ley estatal.

Pero aquí está la pregunta que persiste después de los veredictos de culpabilidad: ¿qué haces con un sistema de votación cuyo software ha sido copiado y ahora está en algún lugar que no controlas?

La respuesta honesta, bajo el modelo de certificación actual, es: no mucho. Puedes cambiar contraseñas. Puedes aplicar parches a los sistemas. Puedes afirmar, como lo hicieron los funcionarios, que la violación no afectó la integridad de las elecciones posteriores. Pero no puedes comprobarlo a nadie que ya no esté inclinado a confiar en ti —porque el sistema nunca fue diseñado para ser independientemente verificable en primer lugar.

Como se documenta en el caso Curling, el testimonio de expertos ante la corte incluyó hallazgos de que un ciberataque podría viablemente intercambiar o eliminar votos y comprometer el sistema. La corte encontró que el sistema de tabulación basado en código QR "no proporciona un registro de papeleta verificable y auditable porque se basa en el código QR para la tabulación de votos y ese código en sí no puede ser leído y verificado por el votante." Una copia impresa en papel no es un registro verificable por el votante si la copia impresa codifica el voto real en un código de barras que ningún humano puede leer.

La seguridad por opacidad falló en el Condado de Coffee porque la opacidad siempre falla eventualmente. Alguien siempre tiene las llaves.

El problema más profundo: ¿qué sucede entre la certificación y el Día de Elecciones?

El Condado de Coffee es la versión dramática de un problema mundano.

Los sistemas electorales reciben parches, cambios de configuración y actualizaciones de software a lo largo de su vida operativa. Los proveedores envían correcciones. Los condados aplican actualizaciones. Las tarjetas de memoria se reprograman entre elecciones. Este es mantenimiento de software normal, razonable —y ocurre casi en su totalidad fuera de la vista pública.

La revisión de arriba hacia abajo de California en 2007, en la que científicos de la computación de la Universidad de California examinaron el código fuente de sistemas de votación certificados, encontró vulnerabilidades serias en cada sistema que estudiaron —incluyendo riesgos de software malicioso que podría propagarse entre máquinas. La revisión EVEREST de Ohio el mismo año, que estudió sistemas certificados de tres proveedores principales, concluyó que todos ellos "poseen fallas de seguridad críticas" y señaló que los registros de auditoría eran comúnmente falsificables o borrables por las personas que se suponía debían monitorear. Estos eran sistemas certificados, en uso activo, examinados por expertos independientes a quienes se les dio el código fuente.

La lección de California y Ohio es la misma que la lección del Condado de Coffee: "fue certificado" es el comienzo de la pregunta, no el final.

La Oficina de Responsabilidad Gubernamental de EE.UU. hizo esencialmente este punto en 2005 —en un informe emitido hace más de dos décadas— encontrando que los esfuerzos federales para mejorar la seguridad del sistema de votación estaban en marcha pero "actividades clave permanecían incompletas," incluyendo establecer repositorios de software seguro e intercambiar información sobre vulnerabilidades. Algunas de esas brechas se han reducido desde entonces. El problema estructural no.

El experimento de Princeton, y por qué sigue siendo importante

En 2006, los investigadores de Princeton Ariel Feldman, J. Alex Halderman y Edward Felten obtuvieron una máquina Diebold AccuVote-TS real —del tipo utilizado en los Estados Unidos— y pasaron alrededor de un minuto con acceso físico a ella. Lo que construyeron fue un virus que roba votos que podía instalarse a través de la tarjeta de memoria, alterar los totales mientras mantenía todos los registros internos consistentes, y propagarse de máquina a máquina durante las operaciones normales del día de elecciones.

La máquina fue certificada. El software había pasado las pruebas.

El artículo de Princeton ahora tiene casi veinte años, y los sistemas de votación han cambiado. Pero la lección estructural no: si no puedes verificar de forma independiente que el software que se ejecuta el Día de Elecciones es el software que inspeccionaste, entonces la inspección no establece mucho.

Un sistema certificado-luego-actualizado, certificado-luego-parchado, o certificado-luego-copiado no es necesariamente el sistema que el laboratorio probó. Y bajo la mayoría de los marcos de certificación actuales, no hay mecanismo rutinario, independiente y público para verificarlo.

Compilaciones reproducibles: la solución técnica que cambia la pregunta

Hay un concepto de ingeniería de software que aborda esto directamente. Se llama una compilación reproducible.

Aquí está la idea en lenguaje simple. Cuando el software se compila —cuando el código fuente legible por humanos se convierte en el binario que realmente se ejecuta en una máquina— el proceso generalmente produce una salida ligeramente diferente cada vez, dependiendo de marcas de tiempo, configuraciones del compilador y otras variables. Esto significa que incluso si publicas tu código fuente, una parte independiente que lo compile por sí sola obtendrá un binario que no coincida exactamente con el binario que se ejecuta en la máquina desplegada. No puedes verificar, byte por byte, que el código que se ejecuta coincida con el código publicado.

Una compilación reproducible cambia esto. Cuando una compilación es reproducible, cualquiera que tome el código fuente publicado y siga el proceso de compilación documentado obtiene exactamente el mismo binario, byte por byte. Luego puedes comparar un hash criptográfico del binario en la máquina desplegada con el hash del binario compilado independientemente. Si coinciden, sabes qué código se está ejecutando. Si no coinciden, algo cambió —y puedes averiguar qué.

Esto no es ciencia ficción. El proyecto Debian Linux ha buscado compilaciones reproducibles desde 2013. El Navegador Tor las logra. Bitcoin Core las logra. Estos son sistemas reales desplegados donde partes independientes pueden confirmar que el binario coincide con el código fuente publicado.

Para software de votación, compilaciones reproducibles significarían esto: después de cualquier actualización o cambio de configuración, la jurisdicción publica el hash binario. Cualquiera —un periodista, un investigador, una campaña, un grupo de defensa de votantes— puede compilar de forma independiente el código fuente y verificar si el hash coincide. Si no lo hace, ese es un hecho público, falsable.

Esto es lo que significa reemplazar "confía en nosotros" con "verifica por ti mismo". No una auditoría por funcionarios que revisan sus propios sistemas. No una instantánea de certificación. Una cadena continua, independiente, verificable públicamente desde el código fuente hasta la máquina que se ejecuta. Lee más sobre esta brecha y qué se ve como una solución real.

Por qué el código abierto es necesario pero no suficiente

El sistema VSAP del Condado de Los Ángeles, certificado en 2018 como el primer sistema de tabulación electoral de código abierto certificado de California, es un desarrollo genuinamente positivo. La propiedad pública del software electoral y el código de código abierto significan que el proceso de conteo puede ser inspeccionado por expertos independientes en lugar de ocultarse como secreto comercial del proveedor.

Pero el código abierto resuelve solo la primera parte del problema: ¿puede alguien ver el código fuente? No responde por sí solo la segunda parte: ¿es el código en la máquina el mismo que el código en el repositorio?

Suiza descubrió este límite en 2019. Swiss Post publicó el código fuente completo de su sistema de votación por internet para escrutinio público —un acto notable de transparencia. Investigadores independientes Sarah Jamie Lewis, Olivier Pereira y Vanessa Teague lo leyeron. Lo que encontraron fue una puerta trasera criptográfica: una autoridad que conocía los valores secretos podía generar una prueba de mezcla que pasaba la verificación matemática mientras en realidad había alterado votos. La falla era invisible en una caja negra certificada. Se hizo detectable en el momento en que la fuente fue publicada y criptógrafos independientes miraron.

La publicación habilitó la detección. Pero la detección ocurrió porque alguien miró de cerca las pruebas criptográficas en sí —y encontró que la prueba podía mentir.

La lección: el código abierto es un requisito previo, no una garantía. Las compilaciones reproducibles agregan la segunda capa —probando que el código que lees es el código que se ejecutó. Y las auditorías criptográficas independientes agregan la tercera —probando que incluso si el código se ejecutó correctamente, su diseño no permite manipulación oculta.

Los tres son necesarios. La mayoría de los sistemas electorales no tienen ninguno.

Lo que no puedes verificar ahora mismo, y qué lo haría comprobable

Aquí está el estado de las cosas, expresado claramente.

Cuando una elección concluye y los funcionarios anuncian el resultado, estás en una posición de verificar algunas cosas: puedes verificar si los totales de papeletas de papel del conteo manual coinciden con los totales de máquinas (como demostró el conteo manual estatal de Georgia en 2020, dentro de aproximadamente una décima de un por ciento). Puedes examinar registros de custodia de cadena para las papeletas de papel. Puedes observar el conteo.

Lo que no puedes verificar —en la mayoría de jurisdicciones, por ningún mecanismo actualmente disponible al público— es si el software que tabuló esas papeletas era el software que el laboratorio de pruebas examinó, o si fue modificado en cualquier momento entre la certificación y el Día de Elecciones.

Estás confiando en una cadena que no puedes ver.

La solución no es misteriosa. Requiere:

Compilaciones reproducibles, para que el binario en cada máquina pueda ser verificado independientemente contra el código fuente publicado.
Valores de hash publicados, firmados y con marca de tiempo, cada vez que el software o la configuración se actualiza —antes de cualquier elección que ese software va a tocar.
Auditorías de compilación independientes, en las que partes fuera del proveedor y fuera de la autoridad electoral compilen el código ellas mismas y verifiquen que los hashes coincidan.
Papeletas de papel que el votante pueda leer, para que sea lo que haga o no haga el software, hay un artefacto independiente —marcado por el votante, legible por un humano, contable a mano— que puede resolver la pregunta.

Ese último punto importa más cuando los primeros tres fallan. El conteo manual de Georgia en 2020 confirmó el resultado de la máquina dentro de una décima de un por ciento precisamente porque papeletas de papel existían que fueron marcadas por votantes y legibles sin software. La preocupación del tribunal Curling sobre el sistema de código QR de Georgia era exactamente que la copia impresa en papel codifica el voto tabulado en una forma que ningún humano puede leer sin una máquina —lo que significa que un "conteo manual" de esas papeletas es en realidad un re-escaneo, confiando en la misma cadena de software nuevamente.

El papel no es suficiente si el papel no puede ser leído. El software no es suficiente si no puede ser verificado. El único sistema que es resiliente contra un intercambio de software es uno donde el registro marcado por el votante, legible por humanos es tanto la entrada al conteo como la verificación independiente del software que lo cuenta.

Ninguna garantía del Secretario de Estado cambia esto. Ningún comunicado de prensa "auditoría confirmó los resultados" lo aborda. La pregunta es si alguien fuera del sistema puede verificar de forma independiente lo que se ejecutó. Ahora mismo, en la mayoría de lugares, la respuesta es no.

La verdad compartible

La certificación te dice que el software pasó una prueba una vez. No te dice que el software que se ejecutó el Día de Elecciones es el software que fue probado. Esa brecha no es una conspiración —es un problema de ingeniería con una solución conocida. Las jurisdicciones que construyen para verificabilidad no necesitan que confíes en ellas. Ese es el punto.

Explora la brecha del intercambio de software en detalle | Mira cuán comunes son las brechas de integridad en todo el mundo | La versión de dos minutos

Fuentes

Ver todos los artículos Explora las brechas