Cómo se preserva una firma digital a largo plazo
Por Pablo Bullian, CISSP y Máster en Seguridad Informática
Hoy es posible verificar una firma digital. ¿Será posible hacerlo en 2036? Para entonces, el certificado del firmante habrá vencido, el certificador podría haber dejado de responder consultas y el algoritmo de hash podría haber quedado obsoleto.
Aunque el contenido firmado se conserve, los certificados, los servicios de consulta y los algoritmos de los que depende su verificación cambian con el tiempo. Preservar una firma requiere mantener y renovar la evidencia que la respalda durante el período de archivo.
En otro artículo explicamos por qué un backup no es un archivo legal. Acá vemos el mecanismo por dentro: qué hace, paso a paso, un servicio de preservación para que una firma siga siendo verificable con los años.
Qué sostiene la verificación de una firma
Cuando un software valida una firma digital, comprueba tres cosas en el momento en que se hace la verificación:
El certificado del firmante encadena a una Autoridad Certificante intermedia, y esta a la raíz. Cada eslabón tenía que estar vigente en el momento de firmar.
Que el certificado no estuviera revocado al firmar. Eso se consulta contra un servicio OCSP o una lista de revocación (CRL) del certificador.
El hash del documento y la clave del firmante tienen que seguir siendo criptográficamente sólidos. Un hash con colisiones conocidas ya no prueba integridad.
Los tres se degradan con el tiempo. Los certificados de firma vencen en 1 a 3 años; los de las AC intermedias, en 5 a 10. Cuando un certificador licenciado deja de operar, sus endpoints OCSP y CRL dejan de responder. Y los algoritmos envejecen: SHA-1 está deprecado desde 2017, RSA-1024 dejó de considerarse seguro hace años.
Para poder verificar en el futuro, entonces, la firma no puede depender de servicios que sigan online ni de algoritmos que sigan vigentes. La evidencia hay que congelarla primero y renovarla después. Esos son los dos movimientos de la preservación.
Primer movimiento: congelar la evidencia (LTV)
La validación de largo plazo (LTV, Long-Term Validation) consiste en reunir el material que prueba que la firma era válida y guardarlo junto al documento. Ese material se puede incorporar al firmar o en una extensión posterior, mientras todavía sea posible obtener evidencia de validación confiable.
En un PDF ese material se guarda en el DSS (Document Security Store): la cadena completa de certificados, las respuestas OCSP y las CRL vigentes al recopilar la evidencia, y un sello de tiempo del documento. Con esa evidencia incorporada, la verificación ya no requiere consultar los servidores del certificador. Esa incorporación se hace como una actualización incremental del PDF: la revisión originalmente firmada y su rango de bytes quedan intactos, aunque el archivo completo recibe datos nuevos. Un esquema alternativo, la evidencia separada (ERS), deja el documento sin cambios y administra el registro de evidencia aparte.
Los estándares ETSI describen esto como niveles de una firma avanzada (AdES). Las tres familias, PAdES (PDF, EN 319 142-1), CAdES (EN 319 122-1) y XAdES (EN 319 132-1), tienen perfiles Baseline equivalentes, aunque almacenan la evidencia de forma distinta; el DSS, por ejemplo, es propio del PDF. Tomando la firma en PDF como referencia, los niveles son:
| Nivel | Qué agrega | Qué resuelve |
|---|---|---|
| B-B | Firma y certificado del firmante | Autoría |
| B-T | Sello de tiempo sobre la firma | Cuándo se firmó |
| B-LT | Cadena de certificados y OCSP/CRL embebidos | Verificable sin servicios externos |
| B-LTA | Sello de archivo sobre todo lo anterior | Renovable en el tiempo |
LTV resuelve el problema de los servicios que se apagan, pero no el de los algoritmos que envejecen. Para eso hace falta el segundo movimiento.
Segundo movimiento: el sello de archivo y su renovación
El sello de archivo del nivel B-LTA cubre el documento, la firma y todos los datos de validación como un solo bloque. Registra que todo ese conjunto existía y era coherente en una fecha determinada.
Con el tiempo, ese sello puede perder respaldo por dos motivos. El certificado de la autoridad de sellado (TSA) que lo emitió también vence. Y el algoritmo de hash con que se calculó el sello puede debilitarse.
Antes de que el certificado del sello de archivo venza, se aplica un sello nuevo sobre el anterior. La prueba de “esto existía en tal fecha” pasa al sello nuevo mientras el viejo todavía tiene respaldo. La cadena de sellos crece y ningún eslabón queda sin cobertura.
Lo que hace que esto funcione es el momento en que se renueva. Cada renovación se aplica mientras el sello anterior sigue siendo válido, de modo que nunca hay una ventana en la que la evidencia quede sin cobertura. Si se espera a que el sello venza, la renovación ya no puede transferir su respaldo.
Cuando el problema es el algoritmo, no el certificado
Renovar el sello con el mismo algoritmo de hash no sirve si lo que se debilitó es el hash. Si aparece un ataque de colisiones práctico, alguien podría fabricar un documento distinto con el mismo hash, y el sello dejaría de distinguir el original.
La respuesta es la renovación por hash. Se vuelve a calcular el hash del documento y de toda la evidencia previa con un algoritmo más fuerte, y se sella ese hash nuevo bajo un sello vigente. En un registro de evidencia separado (ERS) el documento original no se toca; se agrega una capa que ata la evidencia anterior a un hash que todavía es seguro, antes de que el viejo deje de serlo.
El mecanismo estándar para hacer esto a escala es el Evidence Record Syntax (ERS), definido en la RFC 4998 (ASN.1) y la RFC 6283 (XML). En lugar de sellar cada documento por separado, ERS arma un árbol de hashes (un árbol de Merkle) sobre muchos documentos y sella una sola raíz.
Un solo sello puede cubrir un lote grande de documentos a la vez, y cada documento conserva su ruta de prueba hasta la raíz. Cuando llega el momento de renovar (por vencimiento del sello o por debilidad del algoritmo), la operación se hace una vez sobre el árbol y abarca todo el lote. Esto es lo que permite que la preservación escale sin sellar de a uno.
Renovación por sello y renovación por hash son las dos operaciones que definen un archivo de largo plazo. La primera responde a certificados que vencen; la segunda, a algoritmos que caen. Es también la defensa concreta frente al horizonte post-cuántico: cada sello nuevo, llegado el caso post-cuántico, se aplica sobre todo lo anterior y deja constancia de que existía cuando el algoritmo viejo aún era seguro.
El servicio de preservación, por dentro
En conjunto, un servicio de preservación ejecuta cuatro operaciones sobre el archivo, de forma continua:
Ingesta y validación inicial
Recibe el documento firmado, valida la firma en ese momento siguiendo el procedimiento de la ETSI EN 319 102-1, y arma el paquete LTV con la cadena de certificados y las respuestas de revocación vigentes.
Calendario de vencimientos
Lleva registro de cuándo vence cada sello de archivo y cuándo está previsto retirar cada algoritmo de hash. Ese calendario dispara las renovaciones con anticipación.
Renovación automática
Aplica renovación por sello o por hash según corresponda, encadenando cada sello nuevo sobre la evidencia previa. La revisión originalmente firmada se conserva, y la evidencia que la respalda crece con cada renovación.
Exportación de evidencia
Entrega un paquete autocontenido (documento, sellos históricos, datos de validación y registro de operaciones) que se verifica sin conexión y sin depender de que el servicio siga online. Es el paquete que se aporta en una auditoría o un proceso judicial.
Dos estándares definen esto como servicio de confianza: la ETSI TS 119 511 fija los requisitos de política y seguridad del proveedor de preservación, y la TS 119 512 define los protocolos (preservar, recuperar y validar evidencia). En el marco europeo, eIDAS reconoce la preservación cualificada de firmas (Art. 34) y, con eIDAS 2.0, el archivo electrónico como servicio de confianza propio.
Qué significa bajo la ley argentina
El Artículo 12 de la Ley 25.506 admite conservar documentos digitales firmados cuando permanecen accesibles para su posterior consulta y permiten determinar de forma fehaciente su origen, destino, fecha y hora. Mantener la evidencia de validación y preservación ayuda a sostener esas condiciones a lo largo del tiempo; el cumplimiento concreto depende del tipo de documento, la reglamentación aplicable y el procedimiento utilizado.
Argentina todavía no tipifica un “archivo cualificado” al estilo europeo, así que usar los estándares ETSI y el mecanismo de renovación excede el requisito local. El Artículo 319 del Código Civil y Comercial pide al juez ponderar, entre otros factores, la confiabilidad de los soportes y de los procedimientos técnicos. Una cadena de evidencia autocontenida puede fortalecer esa valoración; no garantiza por sí sola la admisión ni elimina la eventual necesidad de un peritaje.
Los plazos obligan a preverlo desde el inicio. La ARCA (ex AFIP) fija un plazo mínimo de diez años para conservar comprobantes y libros; la Ley 26.529 establece diez años para la historia clínica. En esas ventanas, el certificado del firmante vence, el algoritmo cambia y el certificador puede dejar de operar. Sin renovación, la firma llega al final del plazo sin poder verificarse.
Fuentes y estándares
- Perfiles PAdES Baseline: ETSI EN 319 142-1. Procedimientos de validación de firma: ETSI EN 319 102-1.
- Servicio de preservación: ETSI TS 119 511 (política y seguridad) y ETSI TS 119 512 (protocolos).
- Evidence Record Syntax: RFC 4998 (ASN.1) y RFC 6283 (XML).
- Preservación cualificada de firmas: Reglamento (UE) 910/2014, eIDAS.
- Marco argentino: Ley 25.506 (Art. 12), Código Civil y Comercial (Art. 319) y Ley 26.529 (historia clínica).
- Algoritmos post-cuánticos: NIST FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA).
Nota de actualización editorial: Se revisó la redacción de la introducción y de las explicaciones sobre la conservación de evidencia. Se conserva la fecha de publicación original.
Que sus documentos firmados sigan verificables dentro de diez años.
El Archivo Digital de Identik implementa este mecanismo: valida cada documento al ingresar, conserva su evidencia y programa las renovaciones por sello y por hash antes de cada vencimiento. Al recuperar un documento, exporta también su historial de validación y preservación para análisis en auditorías o procesos judiciales. Utiliza la infraestructura de preservación de Namirial, QTSP europeo, con sellado de tiempo cualificado y una hoja de ruta hacia los algoritmos de firma post-cuánticos que el NIST estandarizó (ML-DSA y SLH-DSA, FIPS 204 y 205).
Pablo Bullian es CISSP y Máster en Seguridad Informática por la Universidad de Buenos Aires, y profesor investigador en ciberseguridad en CPE Lyon (Francia), especializado en criptografía y seguridad cloud. Trabaja sobre arquitectura de firma digital, PKI e identidad digital, con eje en el marco normativo argentino (Ley 25.506) y su interoperabilidad con eIDAS.