Pilar · Lo que una firma sí prueba
La criptografía no dice la verdad. Dice qué no se puede cambiar después
Hay una frase que se oye cada vez más en las conversaciones sobre agentes de software: «está firmado, así que es de fiar».
Es comprensible. También es un error, y de los caros.
Una firma criptográfica es una herramienta extraordinaria. Hace dos cosas muy bien. Ninguna de ellas es certificar la verdad.
Qué prueba una firma
Cuando un agente firma un registro con su llave privada, cualquiera con la llave pública puede comprobar dos cosas: que el registro lo emitió quien tiene esa llave, y que no fue modificado ni un solo carácter desde entonces.
Los algoritmos modernos hacen esto con una economía notable. Ed25519, definido en el estándar RFC 8032, usa llaves de 32 bytes y firmas de 64. Es determinista: la misma llave y el mismo mensaje producen siempre la misma firma, lo que elimina toda una familia de fallos que dependían de la mala calidad de la aleatoriedad.
Pero una firma dice quién y qué. No dice si es cierto. Un agente que firma «puesto cubierto de 22:00 a 06:00» cuando el puesto estuvo vacío no produce una verdad. Produce una mentira con autor, y eso es más útil que una mentira anónima solo en un aspecto: sabes a quién pedirle cuentas.
Lo firmado no es lo cierto. Es lo atribuible.
El árbol que no se deja reescribir
El segundo problema es de volumen. Una operación genera miles de registros. Para que un tercero (una aseguradora, un auditor, otro agente) verifique uno solo, no debería tener que leerlos todos.
La solución tiene décadas y se usa a diario sin que nadie la note. Los registros se agrupan en un árbol de resúmenes, llamado árbol de Merkle: cada hoja es la huella de un registro, cada rama es la huella de sus dos hijas, y la raíz resume todo. El estándar RFC 6962, con el que funciona la transparencia de certificados de la web, lo describe con precisión.
Con ese árbol se pueden pedir dos pruebas. La primera, de inclusión: demostrar que un registro concreto está dentro del registro completo, con una lista de unas pocas decenas de huellas. Para un millón de registros, alrededor de veinte. La segunda, de consistencia: demostrar que la versión de hoy es la de ayer más lo nuevo, sin que nada anterior se haya tocado.
El resultado es un registro que solo crece. Puede ampliarse, y cada ampliación se puede auditar. No puede editarse hacia atrás sin que alguien lo note.
El que lleva el registro también puede mentir
Aquí aparece el problema que casi nadie menciona. Un registro inalterable en manos de un solo operador tiene una debilidad: el operador puede mostrar versiones distintas a personas distintas. Una a la aseguradora, otra al cliente. Cada versión, por dentro, es coherente. Solo la comparación las delata.
Vi ese archivo dos veces, con dos caras. La aseguradora tenía una versión. El cliente, otra. Ambas perfectas por dentro. Ninguna mentía sola.
Los sistemas serios de transparencia lo resuelven con testigos independientes: terceros que observan la raíz del registro, la cofirman y la comparan entre sí. Proyectos abiertos como Sigstore, usado para firmar software, diseñan su registro para admitir precisamente eso.
La otra pieza es el tiempo. Un registro puede probar el orden de sus hechos, pero no cuándo ocurrieron. Para eso existen las autoridades de sellado de tiempo (RFC 3161): reciben una huella, le adjuntan la hora y la firman. Y tiene una consecuencia que a una operación crítica le interesa mucho: el documento nunca sale de casa. Viaja solo la huella. Los datos se quedan donde están; lo que circula es la prueba de que existían.
El primer eslabón sigue siendo humano
Toda esta maquinaria protege lo que ya entró al registro. No dice nada sobre lo que ocurrió antes de entrar.
Si el sensor, el lector o el teléfono desde el que se registró una ronda puede ser engañado, el registro será perfectamente inalterable y perfectamente falso. La criptografía sella el momento de la captura. La calidad del momento de la captura es un problema de diseño de proceso: cómo se prueba la presencia en un lugar, con qué dispositivo, con qué llave protegida en qué hardware.
Y hay un caso más difícil, el que nos trajo hasta aquí. El silencio no se firma. Nadie puede sellar un hecho que no ocurrió. La forma de convertir una ausencia en dato es que exista una regla previa: qué rondas debían hacerse, cuándo, quién. Con la regla escrita y cada ejecución registrada, la ronda que faltó deja de ser silencio y pasa a ser un hueco visible en la comparación.
Por eso la criptografía sola no reemplaza al criterio operacional. Lo necesita como entrada.
El horizonte de diez años
Un último punto, que separa a quien piensa en el trimestre de quien piensa en el expediente.
Los registros de una operación pueden necesitarse años después: una disputa con una aseguradora, un litigio, una inspección. Las firmas que usamos hoy dependen de problemas matemáticos que una computadora cuántica suficientemente potente resolvería. Ese equipo aún no existe. Pero un registro firmado hoy debería seguir siendo creíble dentro de una década.
Conviene ser precisos con el riesgo. Para el cifrado, la amenaza es que alguien guarde hoy lo que no puede leer y lo descifre mañana. Para las firmas, la amenaza es distinta: que en el futuro alguien pueda fabricar una firma falsa y reescribir el pasado con apariencia legítima.
En agosto de 2024, el instituto de estándares de Estados Unidos (NIST) publicó las primeras normas de firma resistentes a ese escenario. Una de ellas, ML-DSA (FIPS 204), usa, en su variante intermedia, firmas de unos 3,3 kilobytes en lugar de 64 bytes. Para registros de operación, el costo es irrelevante. Lo que importa es el principio de diseño: que el algoritmo sea una pieza reemplazable, no una decisión enterrada en los cimientos. Poder re-firmar y re-anclar el archivo cuando cambie el estándar es parte de tomarse en serio la palabra «evidencia».
Qué se puede construir sobre esto
Un agente que reporta a otro agente necesita cuatro cosas: una identidad que se pueda comprobar, un registro que solo crece, un tiempo que no depende de la palabra del emisor y una forma de verificar todo eso sin pedirle permiso a quien lo emitió.
Cada una tiene una respuesta técnica conocida. Ninguna es exótica. Lo difícil no es la matemática: es aplicarla a un dominio concreto, con reglas reales de qué cuenta como hecho, quién lo verifica y qué norma manda. Y ahí no gana quien tenga el mejor algoritmo. Gana quien entienda la operación.
Esa es la razón por la que Vadric empezó por la operación humana y no por el agente. La firma es la parte fácil. Lo que hay que saber es qué se firma.
Elige un reporte que tu operación emite hoy. Pregunta: si mañana alguien lo cuestiona, ¿qué prueba existe de que no fue editado, quién lo emitió y cuándo? Si la respuesta es «confiamos en el sistema», todavía no tienes evidencia. Tienes un archivo bonito.