← Todos los artículos

El código abierto en votaciones es necesario — pero aún no es suficiente. Aquí está el resto.

El Condado de Los Ángeles pasó una década construyendo el sistema de votación más transparente del mundo — de código abierto, de propiedad pública, auditable de forma independiente. Suiza hizo lo mismo. Los investigadores aún encontraron una puerta trasera oculta. Aquí está lo que ambos casos pasaron por alto.

Es 21 de agosto de 2018, y un oficial estatal de California está de pie frente a un micrófono a punto de decir algo que nunca antes se había dicho en la historia del estado: el Condado de Los Ángeles acaba de tener certificado su sistema de conteo de votos — y por primera vez, el software que cuenta los votos pertenece al público.

No a un vendedor. No a una empresa privada protegida por leyes de secreto comercial. Al público.

El sistema se llama VSAP — Soluciones de Votación para Todas las Personas. Tomó años y decenas de millones de dólares construirlo. Fue diseñado desde cero para servir a la jurisdicción electoral más grande de Estados Unidos, reemplazando máquinas propietarias obsoletas. Y su código fuente — las instrucciones reales que le dicen a la computadora cómo contar tu voto — fue publicado para que cualquiera lo leyera.

Esto es, genuinamente, un hito. Y aún así no es suficiente.

Esa brecha — entre código abierto y conteo verificado — es de qué trata este artículo.

Por qué el código fuente secreto siempre fue la respuesta incorrecta

Para entender por qué VSAP importa, tienes que entender qué reemplazó.

Durante décadas, el software que contaba los votos estadounidenses fue un secreto comercial. Los vendedores argumentaban que su código era propiedad intelectual propietaria. Los funcionarios electorales tenían que creer en su palabra de que las máquinas funcionaban correctamente. Los investigadores que obtuvieron máquinas por otros medios — como el equipo de Princeton que consiguió una Diebold AccuVote-TS y pasó algunas semanas con ella en 2006 — descubrieron que podían instalar código para robar votos en menos de un minuto que se propagaría de máquina en máquina y alteraría cada registro interno para mantenerse consistente. La máquina reportaría el conteo manipulado con perfecta confianza.

El código era secreto. La manipulación era invisible.

Coffee County, Georgia en 2021 mostró el otro filo de esa misma espada: mantener el código secreto no lo mantiene seguro. A un equipo forense se le permitió la entrada a la oficina electoral y salió con una copia del sistema de votación Dominion completo — el Sistema de Gestión Electoral, los pads de votación, los dispositivos marcadores de boletas, el escáner, todo. El secreto como estrategia de seguridad es solo tan fuerte como el insider más cooperativo en la sala.

El código de código abierto rompe ambos modos de fallo. No puedes ocultar un virus para robar votos en código que todos pueden leer. No necesitas robar el secreto porque no existe uno.

Pero en el momento en que publicas el código fuente, cambias la pregunta. La pregunta ya no es "¿qué dice el código?" La pregunta se convierte en: "¿Es el código que en realidad se ejecuta en la noche electoral el mismo código que está en GitHub?"

Y resulta que esa pregunta es muy difícil de responder.

La lección suiza: código abierto, defecto oculto

En 2019, Swiss Post y su vendedor español Scytl hicieron algo que se parecía al estándar de oro de la transparencia. Publicaron el código fuente completo del sistema de votación por internet de Suiza antes del uso planeado en votaciones federales vinculantes. Los investigadores independientes podían leer cada línea.

Los investigadores Sarah Jamie Lewis, Olivier Pereira y Vanessa Teague aceptaron la invitación. Lo que encontraron dentro de la criptografía no era un error tipográfico. No era un error descuidado. Era una puerta trasera — una estructura matemática enterrada en la prueba de mezcla del mixnet que permitía a quien tuviera ciertos valores secretos generar una transcripción de verificación que pasaría cada control mientras alteraba los votos debajo.

El sistema afirmaba ofrecer "verificabilidad universal." Una prueba que se veía válida confirmaría que la mezcla era correcta. Pero si conocías los valores de la puerta trasera, podías hacer que esa prueba pasara por una mezcla que no era correcta en absoluto.

Llamaron a su informe Ceci n'est pas une preuve — "Esto no es una prueba." Swiss Post y Scytl reconocieron el hallazgo. Las autoridades suizas suspendieron el sistema. Una década de trabajo, una publicación de código completamente abierto — y el defecto seguía allí, invisible hasta que criptógrafos externos excavaron en las matemáticas.

Aquí está la lección que no aparece en el comunicado de prensa: el código de código abierto es necesario porque hace posible la inspección independiente. No es suficiente porque la inspección aún tiene que ocurrir realmente, por personas calificadas para encontrar lo que buscan, y luego las correcciones tienen que ser verificablemente aplicadas.

Publicar el código es el comienzo de la historia, no el final.

El problema de reproducibilidad: del código a la máquina en ejecución

Hagamos esto concreto. Imagina que eres un miembro del consejo municipal del Condado de Los Ángeles. Puedes leer el código fuente de VSAP. Lo encuentras limpio. Estás satisfecho de que el código es correcto.

Llega la noche electoral. En algún lugar de un almacén, una máquina se despierta y comienza a contar papeletas.

¿Cómo sabes que la máquina está ejecutando el código que leíste?

La brecha entre "código fuente" y "software en ejecución" se llama el proceso de construcción. El código fuente es texto legible por humanos. Una computadora ejecuta binario compilado — instrucciones de máquina que un compilador produce de ese texto. El proceso de compilación no es automático, obvio, ni verificable a primera vista. Implica elecciones: qué versión del compilador, qué banderas, qué dependencias, en qué orden.

Si dos personas compilan el mismo código fuente usando compiladores diferentes, a menudo producen binarios diferentes. Y si los binarios son diferentes, no puedes decir mirándolos si la diferencia es inocente (una configuración de optimización diferente) o maliciosa (una instrucción añadida).

Esto no es una preocupación teórica. Fue descrito con precisión letal en la conferencia del Premio Turing de 1984 de Ken Thompson, "Reflexiones sobre Confiar en la Confianza." Thompson mostró que podrías insertar una puerta trasera en un compilador que agregaría invisiblemente código malicioso a cualquier programa que compilara — incluyendo versiones futuras del compilador mismo — sin dejar rastro en ningún código fuente que alguien pudiera leer.

La solución, desarrollada durante la pasada década en el mundo del software libre, se llama construcciones reproducibles. La idea: si un proceso de construcción es determinista — mismos datos de entrada, mismos datos de salida, cada vez — entonces cualquier parte independiente puede compilar el mismo código fuente y comparar la huella digital binaria contra lo que en realidad está instalado en la máquina. Si las huellas digitales coinciden, la máquina está ejecutando lo que el código dice.

Si no coinciden, algo cambió entre el código y la máquina. Eso no es una preocupación filosófica. Eso es una falla de seguridad.

Cubrimos esto en mayor profundidad en nuestro artículo sobre construcciones reproducibles. La versión corta: sin ellas, "código abierto" significa "puedes leer la receta." No significa "lo que salió del horno es lo que la receta describe."

La arquitectura de código abierto de VSAP es un paso genuino hacia adelante. Pero código abierto sin un proceso de construcción documentado y reproducible deja una brecha que ninguna auditoría del código fuente puede cerrar.

Atestación: probando que la máquina es la máquina

Las construcciones reproducibles te dicen si un binario coincide con el código fuente. La atestación es el paso que vincula una máquina específica a un binario verificado específico en un momento específico en el tiempo.

Piénsalo como una cadena de firmas. La jurisdicción certifica un binario. El binario está firmado criptográficamente. Cuando la máquina arranca el día electoral, mide su propio estado de software y genera un informe firmado — una "medida" — que puede ser verificada contra el valor certificado. Si algo ha sido modificado, la medida no coincidirá. Esto no es exótico; ya es cómo un smartphone moderno protege su proceso de arranque.

En la práctica actual del sistema electoral, el equivalente es un hash — una huella digital — que se supone debe ser verificada contra la versión certificada antes del despliegue. Pero "se supone que" está haciendo un trabajo pesado en esa oración. Los controles a menudo son manuales, infrecuentes, o confían en una cadena de custodia que ella misma puede tener brechas.

Considera lo que pasó en Coffee County: el software completo del sistema fue copiado y distribuido por personas con acceso físico legítimo a la oficina. Los sistemas pasaron sus controles previos a la elección. Una comparación de hash después del hecho te diría si el binario cambió en la máquina que se quedó en la oficina. No te diría qué se hizo con la copia que se fue.

La atestación no resuelve el problema de la amenaza interna sola. Pero sí significa que cada máquina, al arrancar, puede ser instada a probar qué está ejecutando — y la respuesta puede ser verificada contra un registro público antes de que se cuente un solo voto.

Cadena de custodia: la capa física que el código no puede reemplazar

Aquí está lo que se ve un sistema completamente auditable de código abierto a las 2 a.m. en la noche electoral: una tarjeta de memoria sale de un tabulador, va a una bolsa sellada firmada por observadores de múltiples partidos, se registra en un libro de contabilidad, es transportada por dos personas que no son del mismo partido, y llega a una instalación central donde su sello es verificado antes de que los datos sean leídos.

Y aquí está lo que se ve cuando esa cadena se rompe: la Corte Constitucional Austriaca en 2016 anuló una segunda vuelta presidencial — no porque se encontrara fraude, sino porque en múltiples distritos, las papeletas postales habían sido abiertas y contadas por personas no autorizadas fuera de la ventana requerida por la ley, sin los testigos requeridos. Aproximadamente 77,000 votos fueron afectados por violaciones procedimentales comprobadas, que excedieron el margen ganador de 30,000 votos. La corte no encontró fraude. Anuló la elección de todas formas, porque los procedimientos que hubieran hecho detectable el fraude no habían sido seguidos — y una manipulación no detectada es indistinguible de una manipulación no detectada.

La misma lógica se aplica a una máquina de votación con código de código abierto perfecto y una construcción reproducible. Si la tarjeta de memoria que contiene resultados es manejada por una sola persona sin testigos antes de llegar al escrutinio, la cadena de custodia se rompe. La corrección del código es irrelevante. No puedes probar que la tarjeta contiene el resultado que la máquina produjo.

La cadena de custodia física no es un procedimiento heredado que la tecnología reemplaza. Es el ancla que conecta el mundo del software con el mundo físico. Sin ella, una prueba criptográfica perfecta del conteo flota libre de cualquier papeleta física que alguien pueda revisar.

Auditorías: el control que cierra el ciclo

La Corte Constitucional Federal de Alemania planteó el principio tan claramente como cualquier corte lo ha hecho: los pasos esenciales de una elección deben ser "examinables por el ciudadano de manera confiable y sin conocimiento especializado alguno." La Corte dijo esto en 2009, anulando el uso de computadoras de votación Nedap en la elección federal de 2005. Las máquinas almacenaban votos solo en memoria electrónica. Sin registro verificable independientemente. Sin control que un no experto pudiera realizar. La corte encontró que era inconstitucional — independientemente de si las máquinas alguna vez hubieran funcionado mal.

El código de código abierto parcialmente satisface este requisito para ciudadanos técnicamente alfabetizados. Una auditoría criptográficamente verificable lo satisface para todos.

La auditoría de conteo manual estatal de Georgia en 2020 — aproximadamente 5 millones de papeletas presidenciales, examinadas por 159 condados en menos de seis días — confirmó el conteo de máquina a dentro de aproximadamente una décima de un por ciento. Ese es un resultado significativo. Una papeleta de papel que el votante marcó con su mano, contada por una persona que el votante podría en principio observar, verificada contra un total de máquina: esa es una cadena que un ciudadano ordinario puede rastrear sin un título en criptografía.

Pero incluso esa cadena tiene límites. Colorado ejecutó la primera auditoría estatal de limitación de riesgo en 2017, proporcionando confianza estadística de que el resultado reportado era correcto. Una auditoría de limitación de riesgo es más rigurosa que una verificación de porcentaje fijo: muestrea más papeletas en carreras cerradas, menos en victorias abrumadoras, y entrega una probabilidad definida de que un resultado incorrecto hubiera sido atrapado. Colorado ha continuado endureciendo su límite de riesgo. Esa es la dirección del viaje.

La lección de ambas: una auditoría solo funciona si hay algo digno de confianza para auditar en su contra. Una papeleta de papel que un votante marcó y pudo inspeccionar es digna de confianza. Un código QR que el votante no puede leer — que una corte federal encontró en Curling v. Raffensperger "no proporciona un registro de papeleta verificable y auditable" porque el código mismo tabula el voto y el votante no puede verificarlo — no es una pista de auditoría. Es una máquina confiando en sí misma.

Código abierto + construcciones reproducibles + atestación + cadena de custodia convergen en esto: un registro duradero y legible por humanos que el votante personalmente verificó, que cualquier parte independiente puede recontar, y cuyo camino de la mano del votante al conteo final está documentado en cada paso por múltiples partes con intereses conflictivos.

La lista de verificación que nadie ha completado completamente

Aquí está la lista real de lo que "código abierto" te da y lo que no:

Lo que el código abierto te da:

  • La capacidad para expertos calificados de leer el código y encontrar errores o puertas traseras
  • La capacidad de comparar la lógica declarada del conteo contra lo que debería hacer
  • Eliminación de argumentos de secreto comercial que bloquean la investigación de seguridad
  • Una base para construcciones reproducibles y auditoría comunitaria

Lo que el código abierto no te da:

  • Prueba de que el binario en ejecución coincide con el código fuente (requiere construcciones reproducibles)
  • Prueba de que una máquina específica está ejecutando el binario certificado (requiere atestación)
  • Prueba de que los resultados no fueron alterados entre la máquina y el escrutinio (requiere cadena de custodia)
  • Prueba de que el conteo refleja las papeletas de papel en la caja (requiere auditorías contra un registro de papel verificado por el votante)

Suiza publicó su código fuente e igualmente ocultó una puerta trasera — no porque la publicación fue inútil, sino porque la publicación sin revisión sostenida, experta y adversarial dejó la trampa sin activarse por demasiado tiempo. El Condado de Los Ángeles publicó su código fuente y merece crédito. La pregunta para la próxima década es si cada condado que usa VSAP puede verificar, independientemente, que el binario en cada máquina coincide con lo que el código dice, y que cada tarjeta de memoria viajó una cadena ininterrumpida de máquina a escrutinio.

La transparencia no es un momento único. Es un proceso que se ejecuta desde el repositorio de código fuente hasta la bolsa sellada en la mesa a las 2 a.m.

Lo que realmente haría esto verificable

Si quisieras construir un sistema donde cualquier parte independiente — no solo un oficial, no solo un vendedor — pudiera verificar toda la cadena desde código a resultado certificado, se vería así:

Uno: Código fuente publicado en un repositorio versionado e inmutable con un hash criptográfico para cada versión.

Dos: Un proceso de construcción documentado y basado en scripts que cualquier parte puede reproducir, produciendo un binario cuyo hash coincide con el hash certificado.

Tres: Atestación preelectoral: cada máquina, antes de procesar una papeleta, genera una medida firmada de su propio estado de software. Esa medida es verificada contra el hash certificado y registrada públicamente.

Cuatro: Registros de papel verificados por el votante — papeletas que el votante personalmente inspeccionó que reflejan elecciones legibles por humanos, no códigos de barras que el votante no puede leer.

Cinco: Auditorías rutinarias de limitación de riesgo que muestrean papeletas de papel contra conteos de máquina, dimensionadas según el margen de la carrera, conducidas por observadores de múltiples partidos, con resultados publicados a nivel de precinto.

Seis: Resultados legibles por máquina a nivel de precinto publicados en el momento en que son certificados — no después del hecho, no en un formato que requiere una solicitud de libertad de información, sino en un archivo .csv o .xml que cualquiera puede descargar y reconciliar contra las cintas del precinto.

Ninguno de estos pasos es exótico. Todos existen en algún lugar de la práctica actual. Ninguna jurisdicción los ha implementado todos de principio a fin, con verificación independiente en cada vínculo.

Esa es la brecha. No "código abierto vs. código cerrado." La brecha es entre publicar el código y hacer toda la cadena — desde código a máquina a papeleta a conteo — verificable independientemente por cualquiera que quiera verificar.

Hasta que esa cadena esté completa y sea pública, "código abierto" es una mejora necesaria. No es una respuesta terminada.

Ver cómo esta brecha aparece en jurisdicciones de todo el mundo →

Lee la versión de 2 minutos de por qué el código abierto es necesario pero no suficiente →

Explora las brechas específicas en construcciones reproducibles y atestación →

Fuentes

Ver todos los artículosExplora las brechas