Sellado de tiempo y hash SHA-256: cómo demostrar que un archivo no ha cambiado

El hash SHA-256 de un archivo identifica sus bytes exactos, y un sellado de tiempo demuestra que ese hash existía en un momento determinado: juntos acreditan que el archivo no ha cambiado desde entonces. Ninguno de los dos prueba que el contenido sea verdadero, que el documento sea auténtico ni quién lo creó.

Esta guía está pensada para equipos de cuentas a pagar, siniestros, asesoría jurídica y cumplimiento que conservan archivos como prueba. Explica cómo comprobar un hash con las herramientas de su equipo, cómo leer un sello de tiempo RFC 3161, qué dicen el derecho europeo y el español y cómo integrar ambos en un flujo de revisión. No constituye asesoramiento jurídico.

Qué demuestra un hash SHA-256 y qué no

Un hash SHA-256 (también llamado huella) es un resumen de 256 bits calculado a partir de todos los bytes de un archivo y escrito con 64 caracteres hexadecimales; el algoritmo lo define la norma NIST FIPS 180-4. A diferencia de una suma de verificación, que detecta una corrupción accidental, una función hash criptográfica está diseñada para que sea inviable fabricar otro archivo con el mismo resultado. Describe bytes, no apariencia:

Un hash distinto significa bytes distintos, no necesariamente un importe alterado ni un fraude. Un hash idéntico significa los mismos bytes, no un contenido auténtico: una factura falsa también tiene un hash estable. Y quien puede modificar un archivo puede recalcular su hash: solo sirve de prueba si se registró donde el custodio no puede reescribirlo sin dejar rastro, y eso es lo que aporta el sellado de tiempo.

El NIST prevé abandonar SHA-1 en todas las aplicaciones antes del 31 de diciembre de 2030 (NIST), y el RFC 6151 considera MD5 inaceptable allí donde se exige resistencia a colisiones, como en las firmas digitales. Para un expediente probatorio, evite MD5 y SHA-1.

En España no confunda este hash con la huella de los registros de facturación (VERI*FACTU y demás sistemas informáticos de facturación). Cada registro lleva una huella o «hash» que lo encadena con el anterior (Orden HAC/1177/2024, art. 13), y la AEAT indica que el algoritmo es, por ahora, SHA-256 en todos los casos (AEAT, preguntas frecuentes). Pero se calcula con un subconjunto de campos del registro (NIF del emisor, número, fecha, importes, huella anterior), no con los bytes del PDF recibido: no sustituye al hash del archivo.

Cómo comprobar el hash SHA-256 de un archivo en Windows, macOS y Linux

Para comprobar un hash, calcule el del archivo en su propio equipo y compare el valor completo con el esperado. Cada sistema trae ya un comando.

Para comparar correctamente:

1. Calcule el hash del propio archivo, no el de una copia que se haya abierto y vuelto a guardar en una aplicación.
2. Compare los 64 caracteres: hacer coincidir los primeros resulta barato, y comparar solo el principio y el final no demuestra nada. Las mayúsculas no importan (PowerShell las muestra, sha256sum usa minúsculas).
3. Deje que la máquina compare. En PowerShell, (Get-FileHash .\factura.pdf -Algorithm SHA256).Hash -eq "HASH_ESPERADO" devuelve True o False. Para una lista publicada en un archivo SHA256SUMS, sha256sum -c SHA256SUMS (Linux) o shasum -a 256 -c SHA256SUMS (macOS) responde OK o FAILED por cada archivo.

Para probar su herramienta, calcule el hash de un archivo que contenga exactamente los tres caracteres abc (printf abc > prueba.txt en macOS y Linux, Set-Content -Path prueba.txt -Value abc -NoNewline en PowerShell): debe obtener ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Si un editor añade un salto de línea final, el resultado pasa a ser edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb.

El valor esperado debe proceder de una fuente independiente. Un hash publicado junto al archivo protege frente a una descarga dañada, no frente a quien puede alterar ambos; como prueba, use su registro de recepción, el portal del emisor o un sello de tiempo, nunca el hash del remitente cuyo envío se discute.

Desconfíe de los comprobadores de hash en línea: muchos exigen subir el archivo, es decir, entregar todo su contenido a un tercero. Para una factura, un contrato o un siniestro, use los comandos anteriores: el resultado es el mismo y nada sale de su equipo.

Qué añade un sellado de tiempo: el sello RFC 3161

Un sello de tiempo electrónico vincula unos datos con un instante concreto y aporta la prueba de que existían en ese instante (Reglamento eIDAS, art. 3, punto 33). Las fechas de un archivo no cumplen esa función: la fecha de modificación, la de creación de un PDF o la de captura de una foto las escribe el software de un dispositivo que usted no controla, y pueden cambiarse. Un sello de tiempo fiable procede de un tercero cuyo reloj y cuya clave de firma son distintos de los suyos. El RFC 3161 normaliza el protocolo:

1. Usted calcula el hash SHA-256 del archivo.
2. Envía el hash, no el archivo, a la autoridad de sellado de tiempo (TSA), normalmente con un valor aleatorio (nonce) contra repeticiones.
3. La TSA firma un token que vincula su hash con la hora UTC de su creación, con un número de serie y su política.
4. La TSA le devuelve el token y usted lo guarda junto al archivo.

La TSA nunca recibe el archivo, así que el sellado sirve para documentos confidenciales. Para verificar, recalcule el hash, compruebe que coincide con el del token y valide la firma de la TSA y que su certificado, emitido para sellado de tiempo, enlaza con una raíz de confianza. OpenSSL lo hace todo (documentación):

La solicitud viaja por HTTP POST (tipo de contenido application/timestamp-query) a la dirección que documenta el prestador. -text muestra el hash (campo «Message data»), el número de serie y la hora en GMT. Una verificación correcta imprime Verification: OK; si el archivo difiere del sellado, imprime Verification: FAILED y el error «message imprint mismatch». cadena.pem contiene el certificado raíz de la TSA. OpenSSL no indica si el prestador es cualificado ni comprueba la revocación sin -crl_check.

Los certificados de las TSA caducan. Un token emitido mientras el certificado era válido sigue siendo utilizable, pero una verificación ingenua años después puede fallar: -attime valida la cadena en el instante del token (segundos desde la época Unix). Para una conservación larga, guarde los datos de validación y renueve la prueba con un sello de archivo.

Un PDF también puede llevar el token dentro, como sello de tiempo de documento, según el perfil PAdES de la norma ETSI EN 319 142-1. Cubre los bytes del PDF hasta el momento en que se añade, no las modificaciones posteriores. Acrobat lo muestra en el panel Firmas, con la hora, el emisor y el estado de validación.

Sello de tiempo cualificado: valor jurídico en España

Esta sección resume textos legales y no constituye asesoramiento jurídico. «Sello de tiempo certificado» es una expresión comercial: el Reglamento (UE) n.º 910/2014 (eIDAS) distingue el sello de tiempo electrónico del sello cualificado de tiempo electrónico (art. 3, puntos 33 y 34), y solo el segundo goza de la presunción que se describe a continuación.

Los artículos 41 y 42 de eIDAS

Según el artículo 41, no se denegarán efectos jurídicos ni admisibilidad como prueba en procedimientos judiciales a un sello de tiempo electrónico por el mero hecho de estar en formato electrónico o de no cumplir los requisitos del sello cualificado. Los sellos cualificados de tiempo electrónicos «disfrutarán de una presunción de exactitud de la fecha y hora que indican y de la integridad de los datos a los que la fecha y hora estén vinculadas».

Según el artículo 42, un sello cualificado vincula la fecha y hora con los datos de forma que se elimine razonablemente la posibilidad de modificarlos sin que se detecte, se basa en una fuente de información temporal vinculada al Tiempo Universal Coordinado y va firmado o sellado con una firma o un sello electrónico avanzado del prestador cualificado, o por cualquier método equivalente (texto consolidado de 18 de octubre de 2024, con el Reglamento (UE) 2024/1183). El Reglamento de Ejecución (UE) 2025/1929, de 29 de septiembre de 2025, fija las normas de referencia cuyo cumplimiento hace presumir esa conformidad. La presunción se refiere a la fecha y a la integridad de los datos sellados, no a la veracidad del contenido, a su autor ni a su licitud.

Ley 6/2020 y Ley de Enjuiciamiento Civil

La Ley 6/2020 complementa a eIDAS en España. Su artículo 3.2 remite, para la prueba de los documentos electrónicos privados en los que se haya usado un servicio de confianza, al artículo 326 de la Ley de Enjuiciamiento Civil: el apartado 3 si el servicio no es cualificado y el apartado 4 si lo es. El 326.3 prevé que, cuando se impugne la autenticidad, la integridad, la precisión de fecha y hora u otras características que un servicio de confianza no cualificado permita acreditar, se proceda conforme al apartado 2 del mismo artículo y a eIDAS. El 326.4 añade que, con un servicio cualificado, se presume que el documento reúne la característica cuestionada y que el servicio se prestó correctamente si figuraba, en el momento relevante, en la lista de confianza; si aun así se impugna, la comprobación corre a cargo de quien impugna.

El sello de tiempo no cualificado sigue siendo admisible, pero sin esa presunción: su peso depende de la fiabilidad del prestador y del resto de la prueba, que el tribunal valora.

Comprobar que un prestador es cualificado

El Ministerio para la Transformación Digital y de la Función Pública establece, mantiene y publica la lista de confianza de prestadores cualificados (Ley 6/2020, art. 16.1); la encontrará en su página de prestadores de servicios electrónicos de confianza. La lista de los demás Estados miembros se consulta en el navegador de listas de confianza de la Unión Europea. Busque el servicio de sellos cualificados de tiempo electrónicos y compruebe su estado en la fecha en que se emitió el sello.

Cómo usar hashes y sellos de tiempo en un flujo de revisión

Un hash y un sello de tiempo solo ayudan si se toman en el momento oportuno y se guardan aparte del archivo:

1. Calcule el hash en la recepción, antes de que nadie abra, renombre, anote o vuelva a guardar el archivo. Trabaje con copias.
2. Registre el hash con el nombre del archivo, el remitente, el canal y la hora de recepción, y conserve el mensaje original con sus cabeceras.
3. Guarde el original en modo de solo lectura, en un espacio donde los cambios queden registrados.
4. Selle un manifiesto, un archivo de texto que enumera cada nombre de archivo con su hash: un solo token fecha todos los archivos. Si el expediente puede acabar en litigio, elija un prestador cualificado.
5. Compare en cada reenvío. Un hash distinto indica una versión nueva que debe revisarse desde cero, sea cual sea el nombre del archivo.
6. Reúna un expediente de verificación (archivo, hash, token, cadena de certificados, comandos) que otra persona pueda repetir años después.

El hash indica si un archivo es el que usted registró. Para examinar qué cambió en su interior, consulte cómo saber si un PDF ha sido modificado; para cotejarlo con el pedido y los pagos, cómo verificar una factura antes de pagarla. Las credenciales de contenido de la guía C2PA, marcas de agua y detectores de imágenes IA también se apoyan en un hash y pueden incorporar un sello de tiempo RFC 3161 (especificación C2PA 2.2), pero documentan cómo se creó un contenido, no solo sus bytes.

Qué registra un informe de Fileverity

Cada informe de Fileverity registra el hash SHA-256 del archivo examinado, de modo que un revisor posterior pueda confirmar a qué archivo se refieren los hallazgos. En la emisión, los datos del informe, que incluyen ese hash, se sellan en el tiempo con la autoridad de sellado RFC 3161 de DigiCert. Los informes en PDF llevan además un sello de tiempo de documento PAdES cuya cadena enlaza con una raíz de la Adobe Approved Trust List.

Un sello de tiempo o un sello PDF solo se indica cuando la validación tiene éxito. Si falta el servicio o los datos de validación, el informe se entrega igualmente, con la ausencia de esa prueba señalada de forma expresa. Fileverity describe estos sellos como sellos de tiempo de confianza RFC 3161, no como sellos cualificados de tiempo electrónico en el sentido de eIDAS, y no es un prestador cualificado de servicios de confianza. La página de seguridad describe cómo se sellan y verifican los informes; la página de verificación muestra los resultados registrados en la emisión y coteja, en su dispositivo, una imagen o el archivo de datos del informe.

Un sello de tiempo acredita que unos datos existían en un momento, no que los hechos del documento ni los hallazgos sean correctos. Los originales no se conservan como archivo duradero: guarde su ejemplar, que el hash registrado permitirá vincular con el informe. El análisis documental cubre lo que un hash no dice: el texto, la estructura del archivo, las revisiones guardadas y las firmas PDF admitidas.

Caso práctico: dos PDF de una misma factura discutida

Este caso es ficticio y los hashes aparecen abreviados. El 6 de julio, cuentas a pagar recibe por correo la factura 2087 de un proveedor ficticio, en PDF, por 4800,00 €. Antes de abrirla, un empleado la guarda tal cual y calcula su hash, que empieza por 3fa9c1. Lo registra con el remitente, el identificador del mensaje y la hora de recepción, sella un manifiesto de una línea y conserva el token. La factura se coteja con el pedido y el albarán y se aprueba.

El 19 de septiembre, el proveedor afirma que la factura era de 5400,00 € y reenvía «el mismo PDF». Su hash empieza por b04e52. Cuentas a pagar procede así:

1. Dos hashes distintos señalan dos archivos distintos, sin decir qué difiere ni quién lo cambió.
2. Ejecuta openssl ts -verify -data manifiesto.txt -in recepcion.tsr -CAfile cadena.pem y localiza en el manifiesto el hash del original guardado, 3fa9c1…. La hora del token es la del 6 de julio.
3. Compara los dos PDF, recupera el correo original con sus cabeceras y pide al proveedor, por el contacto registrado en el alta, la copia de su sistema de facturación.

El expediente respalda una conclusión limitada: el ejemplar recibido existía, sin cambios, el 6 de julio, y el PDF del proveedor es otro archivo. No se establece quién modificó cuál, y es el correo conservado, no el sello, el que muestra lo que envió el proveedor. El importe debido se decide con el pedido, el albarán y el contrato; si la factura inicial era errónea, el proveedor debe emitir una factura rectificativa que la identifique. Un sellado pedido después del litigio no probaría nada sobre el 6 de julio: un token fecha su emisión, nunca un momento anterior.

Preguntas frecuentes

¿Sigue siendo seguro SHA-256?

Sí, para integridad y prueba: la política del NIST permite usar SHA-2, que incluye SHA-256, en cualquier aplicación que requiera un algoritmo hash seguro (política del NIST). MD5 y SHA-1 son las funciones que hay que evitar. Para documentos que se conservan muchos años, prevea volver a sellarlos.

¿Pueden dos archivos distintos tener el mismo hash SHA-256?

Matemáticamente sí, porque existen muchos más archivos posibles que valores de 256 bits. SHA-256 está diseñado para que encontrar un par así sea inviable con los medios de cálculo actuales. Un hash idéntico es, por tanto, un indicio muy fuerte de bytes idénticos, no una demostración matemática.

¿Cambia el hash si renombro o copio el archivo?

No. El hash depende solo del contenido: renombrar, mover o copiar da el mismo valor. Volver a guardar el archivo en una aplicación suele modificarlo, aunque en pantalla no parezca distinto.

¿Demuestra un sello de tiempo quién creó el archivo?

No. Vincula un hash con un instante y nada más: no identifica al autor, no prueba que el contenido sea verdadero y no excluye que el archivo se creara unos segundos antes del sellado. La autoría se acredita con otros elementos, como una firma electrónica.

¿Vale en un juicio un sello de tiempo no cualificado?

Sí, pero sin presunción. El artículo 41 de eIDAS impide negarle efectos jurídicos y admisibilidad como prueba por el mero hecho de ser electrónico o de no ser cualificado. Su peso depende después de la fiabilidad del prestador y del resto de la prueba, que valora el tribunal; solo el sello cualificado disfruta de la presunción de exactitud de la fecha y de integridad de los datos.

Por Yang Zheng · Revisado por Bill Liu