Cómo verificar un paquete de prueba de un documento sin el proveedor

Un paquete de prueba solo vale la pena si puedes comprobarlo sin conexión, con herramientas que ya están en el equipo, frente a una raíz de confianza que obtienes tú mismo y no una que viajó dentro del paquete. Si la comprobación deja de funcionar el día que el proveedor cierra, no tienes una prueba. Tienes una suscripción.

Puntos clave

• Un paquete de prueba debe permitir que un desconocido recalcule la afirmación desde cero. Eso requiere cuatro cosas: tu documento, el token del sello de tiempo, el camino desde el hash de tu documento hasta la raíz sellada y unas instrucciones escritas para alguien que nunca ha visto nada de esto. Solo el documento se queda contigo.

• Un árbol de Merkle es una decisión de privacidad antes que una decisión de velocidad. Una lista plana te obligaría a entregar los hashes de todos los demás documentos anclados ese día, incluidos los de otras personas.

• Según el artículo 41, apartado 2, de eIDAS, un sello cualificado de tiempo electrónico goza de la presunción de exactitud de la fecha y la hora y de integridad de los datos vinculados. La presunción está en el artículo 41, no en el 42.

• La conservación de la prueba en PDFengine es de veinte años por defecto, y se configura aparte del tiempo que se conserva el propio documento.

• Conserva los bytes originales exactamente como los recibiste. Guardar de nuevo rompe la coincidencia, y el Consejo de Estado neerlandés ha visto que eso ocurre dentro del propio circuito de los tribunales.

La otra parte comprueba su propia copia, nunca la nuestra: un paquete con nuestra copia del documento solo demostraría algo sobre nuestra copia.

¿Qué debe haber en un paquete de prueba y por qué?

Tienen que estar presentes cuatro cosas para que un desconocido pueda recalcular la afirmación. El propio documento. El token que vincula un hash a un momento. El camino desde el hash de ese documento hasta la raíz sellada. Y unas instrucciones escritas, porque un tercero obligado a adivinar la construcción no está verificando nada.

Una de las cuatro falta en lo que enviamos, y es el documento. En el caso normal, el paquete contiene cuatro archivos: proof.json, README.txt, timestamp.tsr y los certificados intermedios en tsa-chain.pem. Los dos últimos aparecen una vez que la ronda se ha sellado de verdad y la autoridad ha facilitado su cadena.

El razonamiento que hay detrás de la ausencia del documento es incómodo, pero sólido. Un paquete con nuestra copia solo demostraría algo sobre nuestra copia. La copia en disputa está en tu escritorio, así que esa es la que debe estar junto a estos archivos durante la comprobación. De ahí se siguen dos efectos secundarios: un enlace filtrado no entrega ningún material de clientes, y el paquete sigue siendo lo bastante pequeño para viajar como adjunto de correo.

proof.json contiene el SHA-256 del documento, su posición en el árbol, los hashes hermanos con su lado izquierdo o derecho registrado, el hash raíz, el nombre de la autoridad de sellado de tiempo y una regla escrita de cómo se combinan hojas y nodos. Este último punto importa más de lo que parece. Sin ella, un tercero tiene que adivinar cómo se construyó el árbol, y una conjetura no es una verificación.

¿Por qué un árbol de Merkle y no una lista plana?

Por la privacidad, no por el rendimiento. Ese orden es todo el argumento.

Imagina que los documentos de un día se anclaran como una lista plana, con la raíz como un hash de esa lista. Para demostrar que tu contrato estaba en ella, tendrías que reproducir la lista. Entera. Eso significa entregar a la otra parte los hashes de todos los demás documentos sellados ese día, incluidos documentos de personas ajenas a tu disputa. Filtrarías una lista de clientes para ganar un punto sobre un solo PDF.

Un árbol elimina el problema. Solo aportas los nodos situados justo al lado de tu camino hacia arriba. Cada vez que el lote se duplica se añade exactamente un hash hermano más, de modo que un día con mucho trabajo cuesta unas pocas líneas más en un archivo JSON y no un incidente de divulgación.

El anclaje se ejecuta una vez al día, a las 03:00 Europe/Amsterdam. Una ronda, un árbol, una llamada a la autoridad de sellado de tiempo, tanto si la ronda contiene cuatro documentos como cuatro mil. Solo sale del edificio el hash raíz. Esa economía es lo que permite que la ronda diaria cubra todo lo que entró, y no solo los documentos que alguien se acordó de señalar. Sellar un PDF concreto a petición es una acción aparte, de pago: la herramienta de sello de tiempo cualificado lo hace, archivo por archivo.

¿Por qué la prueba sobrevive cuando el archivo hace tiempo que no existe?

Porque el registro y el documento son objetos distintos con vidas distintas, y los tratamos así a propósito.

Un registro de prueba es un hash, una posición de hoja, una lista corta de hashes hermanos y una referencia a su ronda. Unos cientos de bytes, sin un coste de almacenamiento digno de mención. El documento que describe es otra cuestión: sigue el período de conservación ordinario y se limpia según lo previsto, como debe ser.

Aquí la conservación de la prueba es de veinte años por defecto, configurada con independencia de la conservación de los archivos. Borrar el resultado no elimina el registro del hash. Cinco años después de cerrado un asunto, con el PDF purgado hace tiempo, la aritmética sigue funcionando, siempre que la otra parte haya guardado su copia.

Aquí es donde los incentivos del proveedor se tuercen en silencio. Si tu prueba vive dentro del archivo de otro, necesita que sigas pagando por ese archivo, y el almacenamiento ilimitado deja de ser generosidad para convertirse en el candado.

¿Por qué falta a propósito el certificado raíz?

Porque validar un token frente a una raíz que llegó en el mismo sobre es una comprobación de integridad disfrazada de comprobación de confianza.

Piensa en lo que estás probando. La cadena de tsa-chain.pem muestra que el token es internamente coherente. Bien. Pero la coherencia con una raíz que te entregamos nosotros solo demuestra que somos coherentes con nosotros mismos. Quien pudiera falsificar el token podría falsificar la raíz que va a su lado. La comprobación pasa, la conclusión no vale nada y todo parece una verificación de verdad.

Así que la secuencia tiene tres pasos:

1. Obtén tú mismo el certificado raíz, de la propia publicación de la autoridad de sellado de tiempo o mediante el navegador de la lista de confianza de la UE. proof.json nombra a la autoridad, así que sabes de quién es la raíz que buscas. La nuestra es Disig a.s., en Eslovaquia.

2. Recalcula el hash raíz a partir del SHA-256 de tu documento y los hashes hermanos, siguiendo la regla escrita en proof.json, y comprueba después que tu resultado coincide con el hash raíz registrado allí.

3. Verifica el token sobre ese hash raíz:

openssl ts -verify -digest <root_hash> -in timestamp.tsr \

-untrusted tsa-chain.pem -CAfile <root you fetched yourself>

La contrapregunta obvia es cómo sabes que obtuviste la raíz correcta. No necesitas saberlo de antemano: si apuntas el comando a la equivocada, falla en lugar de pasar en silencio. La raíz firma la cadena que hay detrás de tu token o no la firma.

El mismo razonamiento rige la palabra “cualificado”. Un identificador de política dentro de un token es una autodeclaración de quien construyó el token. La condición de cualificado se deriva, en cambio, de la entrada de un proveedor en una lista de confianza nacional, que es pública y se puede leer sin nosotros. El nuestro figura allí para TSA/QTST con estado granted. Ve a mirarlo.

¿Por qué el anclaje nunca toca el archivo en sí?

Porque el hash se calcula sobre bytes, y escribir el resultado de vuelta en el documento cambiaría esos bytes.

Es un pequeño bucle que atrapa a un número sorprendente de productos. Calculas el hash del documento, obtienes un ancla y luego, con la mejor intención, estampas esa ancla en el PDF para que el lector pueda verla. El PDF almacenado ya no coincide con el hash que acabas de anclar. La prueba se invalida a sí misma en el acto de anunciarse. Por eso el archivo almacenado se mantiene idéntico byte a byte: nada escrito en él, nada guardado de nuevo, nada optimizado. El registro vive junto al documento, nunca dentro.

La misma disciplina se aplica aguas arriba. Con RFC 3161 solo viaja la huella del mensaje hasta la autoridad, y de vuelta viaja un token firmado sobre esa huella. Para material confidencial, esa suele ser la razón de que la conversación sea posible.

¿Qué debe hacer la parte receptora y qué lo estropea?

Conserva el documento original exactamente como llegó. No lo guardes de nuevo. No lo abras en Acrobat para guardar. No lo pases por un conversor para dejarlo ordenado para el expediente. Un hash sobre bytes no perdona, y guardar de nuevo reescribe bytes aunque no haya cambiado nada visible.

El derecho procesal neerlandés apunta en la misma dirección por sus propias razones. El artículo 156a del Código de Procedimiento Civil permite conservar un documento público electrónico en formato electrónico, a condición de que el almacenamiento permita una reproducción inalterada del contenido durante un período adecuado a su finalidad. La reproducción inalterada es el estándar que debe cumplir tu paso de archivo. Un nuevo guardado bienintencionado lo incumple en silencio.

Ese fallo no es teórico. En ECLI:NL:RVS:2024:4237 el Consejo de Estado intentó validar una orden de detención firmada electrónicamente y obtuvo un error. El informe pericial del 3 de septiembre de 2024 explicó por qué: tras la firma, el ministerio envió el archivo a los tribunales, donde se convirtió a un formato para archivo digital. Esa conversión, en palabras de la propia sentencia, dañó información en la parte del archivo donde reside la firma electrónica.

Lee de nuevo la secuencia. La firma estaba bien; el perito la validó en el original. El paso de archivo produjo la copia rota, y esa copia rota entró en el expediente digital. La sentencia no dice a qué formato se convirtió, así que nosotros tampoco.

La regla para quien recibe un documento con prueba adjunta: archiva los bytes recibidos sin tocarlos y trabaja con un duplicado. ¿Ya lo guardaste encima? Pide el original al remitente.

¿Cómo se compara esto con un sello de tiempo de documento en Adobe Acrobat?

El sello de tiempo de documento de Acrobat es un mecanismo real, y un tercero puede comprobarlo. Las diferencias están en dónde vive la prueba, quién elige la fuente de tiempo y qué le pasa al documento.

Qué ediciones y planes de Acrobat incluyen qué funciones de firma lo debe decir Adobe, en sus propias páginas de precios. No vamos a citar cifras que cambian.

Ninguna de las dos columnas es la villana aquí. Si ya sabes en qué autoridad de sellado de tiempo confías y por qué, la vía integrada de Acrobat es respetable. La mayoría de la gente falla en esa segunda cláusula.

¿Qué no demuestra este paquete?

Que el documento existía como muy tarde en el momento registrado en el token y que no ha cambiado desde entonces. Esa es toda la afirmación, y estirarla es como la gente pierde credibilidad en una vista.

No demuestra quién hizo el documento. La construcción no incluye identidad: ni firma ni nadie que avale la autoría. La autoría es una cuestión de firma, y nuestra visión general jurídica explica dónde está esa línea. Tampoco demuestra que el contenido sea cierto. Una factura meticulosamente anclada por un trabajo que nunca se hizo sigue siendo una mentira anclada.

Un ancla es un límite superior, nunca una partida de nacimiento. Existía como muy tarde en. No creado el. Mantenemos una lista de formulaciones vetadas en nuestros propios textos, y “creado el” figura en ella, junto a “legalmente válido” y “certificado”. La versión acotada sobrevive al contacto con una sala de vistas. La versión de marketing no.

Dentro de esos límites, el valor es real. El artículo 41, apartado 2 atribuye a un sello cualificado una presunción de hora exacta y de integridad de los datos vinculados. En la práctica, eso traslada la carga de la prueba a quien quiera impugnar la fecha.

Preguntas frecuentes

¿Tengo que enviar mi documento a la autoridad de sellado de tiempo?

No. Con RFC 3161 el cliente envía solo la huella del mensaje, que es un hash. El documento nunca sale de tu entorno, y por eso esto sigue siendo utilizable con material confidencial que no podrías subir a un sitio web de validación.

¿Puedo seguir comprobándolo si PDFengine deja de existir?

Sí, y por eso el paquete incluye un token y no un enlace. Todo lo que necesita la comprobación está en el paquete, más una raíz que obtienes de la autoridad o de la lista de confianza, y la herramienta es openssl y no nuestro software. Nuestro README pone la página de verificación en último lugar, por cortesía, debajo del comando sin conexión.

¿Puede alguien cambiar sin más la fecha de creación dentro de un PDF?

Sí. Las fechas de creación y modificación dentro de un PDF son campos de metadatos corrientes que se pueden reescribir sin conocimientos especiales, y el reloj del equipo se puede retrasar antes de que se genere el documento. Una fecha en la que confiar tiene que venir, por tanto, de fuera del archivo, firmada por una parte sin interés en él.

Abrí el archivo y lo guardé. ¿Rompí la prueba?

En esa copia, probablemente. Guardar reescribe bytes aunque no haya cambiado nada visible, y el hash cubre bytes. Vuelve a la copia tal como se recibió y, si ya no existe, pide al remitente que la facilite de nuevo. Una comparación de huellas digitales aún puede indicar si el contenido se desplazó, aunque es una afirmación más débil que una coincidencia de bytes.

¿Por qué no se incluye el certificado raíz en el paquete?

Porque una raíz que viajó con el token no demuestra nada sobre el token. Validar frente a ella es una comprobación de integridad disfrazada de comprobación de confianza. Obtén la raíz del proveedor o del navegador de la lista de confianza de la UE y verifica frente a esa.

¿En qué situación deja esto al documento que tienes en tu escritorio?

Si un documento puede discutirse algún día, el momento útil es ahora, mientras nadie discute todavía. Fija los bytes, haz que se anclen y conserva intacta la copia recibida. La discusión pasa entonces de “¿nos fiamos de este archivo?” a “¿qué dice este archivo?”.

¿Te han entregado un documento con prueba adjunta? /verify acepta un archivo, un hash o un código de verificación, e informa de los resultados por separado en lugar de reducirlos a una única marca verde. Es una comodidad, y la página lo dice. Los comandos del paquete son la prueba.

Daan van Tongeren es el fundador de PDFengine, donde diseñó el paquete de prueba descrito aquí, incluida la línea del README que te dice que no te fíes de la raíz que contiene. Se agradecen correcciones, o el relato de un caso en el que esto salió mal en la práctica, a través de la página de contacto.