Firmas digitales para archivos: probar autenticidad y origen

Una firma digital es una prueba criptográfica de que una persona o entidad concreta creó un archivo y de que el archivo no ha cambiado desde entonces. Técnicamente, haces hash del archivo con SHA-256 y luego «firmas» el hash con tu clave privada usando RSA-PSS, ECDSA o Ed25519. Cualquiera con tu clave pública puede verificar la firma: si se verifica, saben que tú eres el autor del archivo y que es idéntico byte a byte a lo que firmaste. Las firmas son lo que usa macOS para verificar actualizaciones de apps, lo que usa Git para la autoría de commits (git commit -S), y lo que usa PGP para correos firmados. Resuelven un problema que el cifrado solo no puede resolver: probar quién envió qué.

Firmas vs. cifrado: trabajos diferentes

El cifrado mantiene el contenido en secreto. Las firmas prueban la autoría y la integridad. Son complementarios, no alternativas.

• Solo cifrado: el destinatario conoce el contenido pero no sabe quién lo envió. Cualquiera con la clave pública podría haberlo cifrado.
• Solo firma: el destinatario sabe quién lo envió y que no fue manipulado, pero el contenido es visible para cualquiera que lo intercepte.
• Firma y cifrado: autenticidad, integridad y confidencialidad completas. El modo por defecto de PGP.

Los servicios de transferencia de archivos típicamente se centran en el cifrado. Las firmas entran en juego para contextos de alta confianza: distribución de software, documentos legales, contratos, cadenas de custodia de evidencias forenses.

Cómo funciona la firma realmente

El flujo de firma Ed25519 canónico:

1. Hash del mensaje: h = SHA-512(message).
2. Calcula un nonce determinista: r = SHA-512(private_key_prefix || h).
3. Calcula el punto de firma: R = r·G (donde G es el punto base de la curva).
4. Calcula s = r + SHA-512(R || public_key || h)·private_key mod ℓ.
5. La firma es (R, s), 64 bytes en total.

La verificación usa solo la clave pública, el mensaje y la firma. Si las matemáticas funcionan, el verificador sabe que la firma fue producida por alguien que tenía la clave privada correspondiente.

RSA-PSS (PKCS#1 v2.2) y ECDSA funcionan de forma similar pero con matemáticas subyacentes diferentes. Ed25519 es preferido para nuevos sistemas porque es determinista (sin nonce aleatorio por firma que pueda fallar) y más rápido.

Los tres algoritmos de firma más comunes

| Algoritmo | Tamaño de clave | Tamaño de firma | Velocidad | Notas | |-----------|-----------------|-----------------|-----------|-------| | RSA-PSS-2048 | 256 bytes | 256 bytes | ~1.000 firmas/s | Amplio soporte, generación de claves lenta | | ECDSA P-256 | 32 bytes | 64 bytes | ~30.000 firmas/s | Curva NIST, requiere RNG seguro por firma | | Ed25519 | 32 bytes | 64 bytes | ~50.000 firmas/s | Determinista, estándar moderno |

Los tres están aprobados en FIPS 186-5 de NIST (2023). Ed25519 es la elección para los nuevos protocolos: WireGuard, SSH (por defecto desde OpenSSH 8.0), Signal, la firma de commits de Git y la firma de paquetes de Cargo de Rust.

Firma de código: un caso de uso de miles de millones de euros

La distribución de software depende de las firmas. Sin ellas, los usuarios no pueden distinguir el instalador real del malware:

• Apple Developer ID + Notarización. Todas las apps de macOS deben estar firmadas y notarizadas desde Catalina (2019). Usa RSA-2048 o ECDSA P-256.
• Microsoft Authenticode. Los ejecutables de Windows firmados con certificados RSA-3072 o ECDSA P-384.
• Android APK v2/v3. Firmas Ed25519 sobre el contenido del APK.
• Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Todos usan firmas separadas (típicamente GPG Ed25519 o RSA) sobre los manifiestos de paquetes.

Un incidente famoso: en 2020, la actualización de Orion de SolarWinds fue firmada con el certificado legítimo de la empresa después de que atacantes comprometieran el sistema de compilación. La firma era válida: simplemente probaba que el código provenía de una fuente comprometida. Las firmas garantizan la identidad del firmante, no el criterio del firmante.

PGP y firmas separadas para archivos

GnuPG (gpg) sigue siendo el caballo de batalla para las firmas de archivos fuera de PKI corporativa. Una firma separada mantiene el archivo sin modificar y coloca la firma en un archivo .sig separado:

gpg --detach-sign --armor documento.pdf
# Produce documento.pdf.sig

gpg --verify documento.pdf.sig documento.pdf
# gpg: Good signature from "Alicia <alicia@ejemplo.com>"

La debilidad de PGP es la distribución de claves: ¿cómo sabe el verificador que la clave de firma realmente pertenece a Alicia? Las opciones incluyen servidores de claves, web de confianza, keybase.io o verificación fuera de banda (huella digital publicada en una tarjeta de visita).

Alternativas modernas: Sigstore (usado por Kubernetes, npm) hace firma sin claves usando tokens de identidad OIDC, con logs de transparencia que reemplazan a la web de confianza. minisign de Frank Denis ofrece firma Ed25519 simple sin la complejidad de PGP.

Agregación de firmas basada en hash

Para colecciones de archivos, firmar cada uno individualmente es ineficiente. Mejor: hacer hash de cada archivo, construir un árbol Merkle, firmar la raíz. Ventajas:

• Una firma cubre muchos archivos.
• Los archivos individuales pueden verificarse contra la raíz con log(n) hashes hermanos.
• Usado por los logs de transparencia de certificados, Git y cada vez más por herramientas de cadena de suministro de software como in-toto.

Una versión de 10.000 archivos firmada de esta forma produce una firma más un hash raíz de 32 bytes, verificable contra cualquier subconjunto de los archivos.

Marcas de tiempo: probar cuándo

Una firma prueba quién, pero no cuándo. Un atacante que roba tu clave privada puede antedatar firmas. Las Autoridades de Sellado de Tiempo (TSA) resuelven esto firmando una marca de tiempo sobre tu firma, anclándola a un momento específico.

Estándares:

• RFC 3161 sellado de tiempo — usado por Microsoft Authenticode, las firmas PDF de Adobe.
• RFC 5544 (CMS con marcas de tiempo).
• Roughtime — un protocolo más nuevo de Google para tiempo verificado de baja latencia.

La firma de documentos legales (DocuSign, Adobe Sign, firmas cualificadas eIDAS de la UE) depende de marcas de tiempo RFC 3161 de autoridades de confianza para establecer cuándo se firmó un contrato.

Firmas en la transferencia de archivos

La mayoría de los servicios de transferencia de archivos orientados al consumidor no exponen firmas directamente: la etiqueta de autenticación de AES-GCM prueba la integridad dentro de la transferencia, y TLS prueba la identidad del servidor, pero no hay una forma integrada de probar la identidad del remitente.

Para transferencias de alta confianza, la firma ocurre antes de la subida:

1. El remitente firma el archivo con Ed25519 o PGP, produciendo archivo.ext y archivo.ext.sig.
2. Ambos archivos se suben a cualquier servicio de transferencia (HexaTransfer, SwissTransfer, WeTransfer).
3. El destinatario descarga ambos, verifica la firma con la clave pública del remitente.

Esto desacopla la autenticidad del mecanismo de transferencia: el servicio de transferencia podría estar comprometido sin romper la validez de la firma, siempre que la clave privada del remitente permanezca en secreto y el destinatario tenga la clave pública correcta.

Firmas cualificadas eIDAS en la UE

El Reglamento eIDAS de la Unión Europea (UE 910/2014, revisado en 2024 como eIDAS 2.0) define tres niveles de firma:

• Firma electrónica — básica, incluye firmas manuscritas escaneadas.
• Firma electrónica avanzada (FEA/AdES) — vinculada al firmante, detecta manipulaciones. Las firmas PGP califican.
• Firma electrónica cualificada (FEQ) — AdES más un certificado cualificado de un Proveedor de Servicios de Confianza, almacenado en un Dispositivo Cualificado de Creación de Firma (tarjeta inteligente o HSM).

La FEQ tiene el mismo peso legal que una firma manuscrita en todos los estados miembros de la UE. Los proveedores incluyen DocuSign EU, Adobe Sign EU, Namirial y DTrust. Los equivalentes en España bajo la LOPD-GDD siguen las mismas pautas del marco eIDAS.

Cuándo las firmas son innecesarias

No todos los archivos necesitan una firma. Prescindes de ella cuando:

• El destinatario confía en el canal de transferencia de extremo a extremo (Signal, USB en persona).
• El contenido no es crítico para la seguridad (fotos de reuniones, recetas, borradores de documentos).
• La integridad sola es suficiente y la proporciona AES-GCM o TLS.

Añade firmas cuando:

• El peso legal o contractual importa (contratos, evidencias judiciales, historiales médicos).
• La confianza en la cadena de suministro está en juego (versiones de software, actualizaciones de firmware).
• El archivo se reenviará a través de intermediarios no confiables.
• Necesitas un rastro de auditoría duradero que sobreviva a la transferencia original.

Cómo usarlo en la práctica

Para un flujo de trabajo simple: genera una clave Ed25519 con ssh-keygen -t ed25519 -f ~/.ssh/signing_key, firma un archivo con openssl pkeyutl -sign -inkey signing_key -in archivo -out archivo.sig, comparte tu clave pública fuera de banda, y envía el archivo a través de cualquier servicio de transferencia seguro. Los destinatarios verifican con openssl pkeyutl -verify.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.