Saltar al contenido

Firmas digitales: qué garantizan y qué no

    Firmas digitales:

    qué garantizan y qué no

    Fundamentos de criptografía  |  unfantasmaenelsistema.com

    La firma digital es una de esas piezas que aparece por todas partes sin que nadie la presente: el paquete que instala tu gestor de software «está firmado», el commit de Git lleva un tic verde, la actualización del móvil «viene verificada», el PDF del contrato tiene una firma electrónica, y DKIM «firma» cada correo que sale de tu dominio. Todas son la misma idea criptográfica, y todas garantizan exactamente lo mismo: este contenido lo produjo quien dice, y no ha cambiado ni un byte desde entonces.

    Este artículo cierra el trío de fundamentos junto con hashing/cifrado/codificación y simétrico/asimétrico. Vamos a ver cómo se construye una firma (spoiler: es un hash cifrado con la clave privada), qué propiedades ofrece y cuáles no, en qué se diferencia de un HMAC, y por qué la parte difícil nunca es la firma en sí, sino saber de quién es la clave pública con la que verificas.

    Qué aprenderás en este artículo

    Cómo se firma y cómo se verifica, en cuatro pasos y sin matemáticas · Qué garantiza una firma (integridad, autenticidad) y qué no (confidencialidad) · El no repudio y sus matices legales y prácticos · Firma digital frente a MAC/HMAC: cuándo usar cada una · Por qué la cadena de confianza (¿de quién es esta clave pública?) es el verdadero problema · Ejemplos reales: paquetes de distribución, commits de Git, artefactos de contenedor, PDF y eIDAS

    1. Qué es una firma digital

    Una firma digital es un valor que se adjunta a un mensaje y que solo puede haber generado quien posee una clave privada concreta, pero que cualquiera puede verificar con la clave pública correspondiente. Es la operación asimétrica «al revés» del cifrado: en el cifrado para alguien usas su clave pública y solo su privada abre; al firmar usas tu privada y cualquiera comprueba con tu pública.

    1.1 Cómo se firma

    • Se calcula el hash del mensaje completo (SHA-256, normalmente). Esto reduce un documento de cualquier tamaño a un resumen de longitud fija
    • Se aplica la clave privada del firmante a ese hash mediante un algoritmo de firma (RSA-PSS, ECDSA, Ed25519). El resultado es la firma
    • Se envía el mensaje junto con la firma (y a menudo el certificado que contiene la clave pública)

    1.2 Cómo se verifica

    • El receptor calcula por su cuenta el hash del mensaje recibido
    • Aplica la clave pública del firmante a la firma y comprueba que el resultado corresponde a ese hash
    • Si cuadra: el mensaje no se ha modificado y lo firmó quien tiene la clave privada. Si no cuadra: o el mensaje cambió, o la firma no es de esa clave, o está corrupta

    Se firma el hash y no el documento entero por eficiencia: la operación asimétrica es lenta y solo admite entradas cortas. Esto hace que la seguridad de la firma dependa también de la del hash: por eso las firmas con SHA-1 se consideran obsoletas.

    2. Qué garantiza y qué no

    Propiedad¿La da una firma?Comentario
    IntegridadSíCualquier cambio en el mensaje invalida la firma
    AutenticidadSíSolo el poseedor de la clave privada pudo generarla
    No repudioCon maticesVer sección 3
    ConfidencialidadNoEl mensaje va en claro; firmar y cifrar son operaciones distintas
    Frescura / anti-repeticiónNo por sí solaUna firma válida se puede reenviar; hace falta marca de tiempo o nonce

    El malentendido más común es creer que algo firmado está también protegido de miradas ajenas. No lo está: un correo firmado con DKIM lo puede leer cualquiera que lo intercepte. Si quieres las dos cosas, se firma y se cifra (en ese orden o combinados, según el esquema).

    Una firma válida no dice nada sobre el contenido

    Que un instalador esté correctamente firmado significa que procede de quien controla esa clave y no se ha manipulado por el camino. No significa que el programa sea seguro, ni que haga lo que dice: el malware también se firma, a veces con certificados robados o comprados a nombre de empresas fantasma. La firma traslada la pregunta de «¿confío en este fichero?» a «¿confío en quien lo firmó?»

    3. El no repudio y sus matices

    El no repudio es la idea de que el firmante no puede negar después haber firmado, porque solo él tenía la clave privada. En teoría es una propiedad potente; en la práctica tiene grietas:

    • La clave se pudo robar. Si un atacante copió la clave privada, las firmas que produjo son criptográficamente válidas pero no las hizo el titular. De ahí la importancia de proteger la clave (HSM, tarjetas, hardware) y de poder revocarla
    • Firmar no implica consentir. Un sistema puede firmar automáticamente sin que una persona haya leído ni aprobado nada. El valor probatorio depende del contexto, no solo de las matemáticas
    • El marco legal varía. En la UE, el reglamento eIDAS distingue firma electrónica simple, avanzada y cualificada; solo la cualificada (con certificado emitido por un prestador de confianza y dispositivo seguro) tiene por ley el mismo efecto que la firma manuscrita

    4. Firma digital frente a MAC / HMAC

    Ambos mecanismos detectan si un mensaje se ha alterado, pero se apoyan en modelos de confianza distintos.

    Firma digitalHMAC (MAC)
    Tipo de criptoAsimétrica (clave privada / pública)Simétrica (un secreto compartido)
    Quién puede generarSolo el poseedor de la clave privadaCualquiera que tenga el secreto
    Quién puede verificarCualquiera con la clave públicaSolo quien tiene el secreto
    No repudioSí (con matices)No: ambas partes tienen el mismo secreto
    VelocidadLentaMuy rápida
    Uso típicoSoftware, documentos, correo (DKIM), certificadosTokens de sesión, cookies firmadas, webhooks, APIs internas

    Regla rápida: si quien verifica y quien genera son la misma entidad o confían plenamente entre sí (tu backend validando sus propios tokens), HMAC es más simple y más rápido. Si necesitas que terceros verifiquen sin poder falsificar (millones de navegadores comprobando un certificado, cualquiera validando un paquete de Debian), necesitas una firma digital.

    5. El problema de verdad: ¿de quién es esta clave pública?

    Verificar una firma es fácil. Lo difícil es responder con confianza a: ¿esta clave pública pertenece de verdad a quien creo? Si un atacante me convence de usar su clave pública en lugar de la legítima, firmará el malware con su privada y mi verificación dará «correcto». Cada ecosistema resuelve este anclaje de forma distinta:

    EcosistemaCómo se establece la confianza en la clave
    TLS / webPKI jerárquica: autoridades de certificación raíz preinstaladas en el sistema
    Paquetes de LinuxLa clave del repositorio se instala con el sistema o el paquete de configuración; se confía en ella de forma pineada
    PGP / correoRed de confianza (web of trust) o verificación manual de huellas
    SSHTOFU (trust on first use): se acepta la clave del host la primera vez y se avisa si cambia
    Contenedores (cosign)Clave pública distribuida aparte, o firma keyless anclada a una identidad OIDC y un log público (Sigstore/Rekor)

    La cadena de confianza es el eslabón que se ataca

    Los incidentes reales rara vez rompen el algoritmo de firma: roban una clave de firma (caso SolarWinds), consiguen un certificado de firma de código a nombre falso, o comprometen el sistema de compilación para firmar algo malicioso con una clave legítima. Proteger la clave privada y tener un plan de revocación importa más que elegir entre Ed25519 y RSA

    6. Firmas que ya usas sin darte cuenta

    • Paquetes de distribución: apt y dnf verifican la firma del repositorio antes de instalar nada; un espejo malicioso no puede colarte paquetes alterados
    • Commits y etiquetas de Git firmados: git commit -S firma con tu clave (GPG, SSH o S/MIME) y GitHub/GitLab muestran «Verified» si conocen tu clave pública
    • Artefactos de contenedor: cosign sign / cosign verify firma imágenes de Docker; encaja con el artículo de cadena de suministro de software
    • Correo: DKIM firma cabeceras y cuerpo de cada mensaje saliente; el receptor valida con la clave publicada en el DNS del dominio (enlaza con SPF, DKIM y DMARC)
    • Documentos y eIDAS: los PDF firmados incrustan la firma y su certificado; un visor comprueba la cadena hasta una CA de confianza y muestra si el documento se tocó tras firmarlo
    • Arranque y actualizaciones: Secure Boot verifica la firma del cargador y el kernel; el móvil solo instala actualizaciones firmadas por el fabricante
    # Firmar y verificar un fichero con una clave SSH (minisign/signify son aun mas simples)
    ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n file documento.pdf     # genera documento.pdf.sig
    ssh-keygen -Y verify -f allowed_signers -I correo@ejemplo.com \
      -n file -s documento.pdf.sig < documento.pdf
     
    # Ver la firma de un commit de Git
    git log --show-signature -1
     
    # Verificar la firma de una imagen de contenedor
    cosign verify --key cosign.pub registro.ejemplo.com/app:1.4.2

    Referencias

    NIST FIPS 186-5 — estándar de firmas digitales (RSA, ECDSA, EdDSA) · Reglamento eIDAS (UE) 910/2014 y su revisión eIDAS 2 — niveles de firma electrónica en Europa · Sigstore (sigstore.dev) — firma de artefactos software sin gestionar claves de larga vida · Documentación de DKIM (RFC 6376) y de git commit signing · Nuestros artículos sobre hashing/cifrado/codificación, cifrado simétrico y asimétrico, TLS y PKI, SPF/DKIM/DMARC y cadena de suministro de software

    Conclusión

    Una firma digital es un hash del mensaje transformado con la clave privada del firmante, que cualquiera verifica con la clave pública. Garantiza que el contenido no ha cambiado y que lo produjo quien controla esa clave. No lo mantiene en secreto —para eso está el cifrado— y el no repudio que aporta tiene matices legales y depende de que la clave privada no se haya filtrado.

    Frente a un HMAC, la firma permite que terceros verifiquen sin poder falsificar, a cambio de ser más lenta. Y el trabajo de verdad no está en firmar ni en verificar, sino en anclar con confianza cada clave pública a una identidad: PKI para la web, claves pineadas para los repositorios, TOFU para SSH, logs públicos para los contenedores. Cuando algo va mal con una firma, casi siempre es esa cadena de confianza —o la custodia de la clave privada— lo que ha fallado.

    unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)

    Resumen de privacidad

    Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.