Cómo una firma digital prueba quién firmó

SpecSpec: RFC 5652RFC 5652SpecSpec: RFC 5280, §6RFC 5280 §6SpecSpec: RFC 3161, §1RFC 3161 §1

De un vistazo

Una firma digital hace tres cosas, y conviene mantenerlas separadas desde el principio: prueba que los bytes no cambiaron, prueba quién los firmó y —con un poco de ayuda— prueba cuándo. Esta página construye esa idea desde cero, para que la criptografía deje de ser una caja negra.

Por qué importa

«Firmado» es una palabra sobre la que la gente apuesta decisiones. Un contrato, una factura, una nota de versión de software que alguien va a ejecutar. Si solo sabes que una herramienta dibujó una marca de verificación verde, en realidad no sabes qué se demostró. Podrías tener prueba de que los bytes están intactos pero ninguna idea de qué clave los firmó. Podrías tener un firmante real pero un certificado que caducó hace años. Entender las piezas es lo que permite decir, con precisión, qué significa una firma válida y, de igual utilidad, qué no significa.

La versión breve

Imagina un sobre a prueba de manipulaciones con un sello personal estampado en la solapa.

• El sello es único de una persona y, en la práctica, imposible de falsificar. Cualquiera puede reconocerlo; solo su dueño puede crearlo. Eso es el par de claves: una clave privada que solo tú posees y una clave pública que todos pueden ver.
• No estampas el sello sobre todo el documento. Lo estampas sobre un resumen diminuto e infalsificable de él: un hash. Cambia un byte del documento y el resumen cambia por completo, de modo que el sello ya no encaja.
• Firmar es producir una firma sobre el documento con tu clave privada —sobre el hash para RSA y ECDSA, o sobre el propio contenido para EdDSA, que hace su propio hashing dentro. Verificar es ejecutar la comprobación del algoritmo con tu clave pública, la firma y el mismo contenido (como hash o directamente): devuelve válida o inválida. Las matemáticas, no la confianza, enlazan las dos.
• Un certificado es la parte que dice de quién es este sello. Sin él, has probado que una clave firmó los bytes, pero no que la clave pertenezca a alguien en particular.
• Una marca de tiempo es la parte que dice cuándo. El propio reloj de un firmante es solo una afirmación; el tiempo de confianza proviene de una autoridad externa.

Cómo lo aborda NextPDF

Empieza por el hash, porque todo lo demás se apoya en él. Una función de hash criptográfica lee cualquier cantidad de datos y produce una huella corta y de longitud fija; para una firma PDF, normalmente un valor de 256 bits. Dos propiedades la hacen útil: la misma entrada siempre produce la misma huella, y es inviable encontrar una entrada distinta con la misma. Así que un hash es un sustituto fiel del documento. Si dos hashes coinciden, los bytes coinciden.

Ahora el par de claves. Una clave privada y una clave pública están vinculadas matemáticamente, pero no puedes derivar una de la otra en ninguna cantidad práctica de tiempo. Solo la clave privada puede producir una firma válida, y solo la clave pública correspondiente puede comprobarla. Firmar usa esa asimetría: el firmante aplica una operación de clave privada a la entrada que define el algoritmo elegido —el hash del contenido para RSA y ECDSA, o el contenido directamente para EdDSA, que hace el hash internamente. El resultado es el valor de firma. Como solo el poseedor de la clave privada pudo producirlo, y como está ligado a este contenido, prueba dos cosas a la vez: que el poseedor firmó y que los bytes no se han movido desde entonces.

La verificación refleja esa lógica. El verificador reconstruye la misma entrada —calculando el hash del documento para RSA y ECDSA, o tomando el contenido directamente para EdDSA— y luego ejecuta la operación de verificación del algoritmo de firma sobre la clave pública, el valor de firma y esa entrada. La operación devuelve válida o inválida, y esta es la misma forma tanto si el algoritmo es RSA, ECDSA o EdDSA, aunque solo RSA pueda representarse como literalmente «recuperar» el hash. Válida significa intacta y auténtica. Inválida significa que algo cambió, o que se usó la clave equivocada, y la respuesta honesta es inválida.

1. Prepare the inputRSA and ECDSA hash the document to a short, fixed-length fingerprint; EdDSA signs the content directly and hashes it internally. Either way, any change to the bytes changes what is signed.
2. Sign with the private keyThe signer applies a private-key operation to that input — the hash for RSA and ECDSA, the content for EdDSA. The output is the signature value; only the private-key holder could have produced it.
3. Reconstruct the inputThe verifier independently rebuilds the same input from the content — a recomputed hash for RSA and ECDSA, the content itself for EdDSA. This is what the verify operation checks against.
4. Verify with the public keyThe verifier runs the algorithm's verify operation on the public key, the signature value, and that input. The same shape works for RSA, ECDSA, and EdDSA.
5. Accept or rejectThe verify operation returns valid or invalid. Valid means the bytes are intact and the private-key holder signed them. Otherwise the result is invalid — no guessing.

How a digital signature is produced and then checked, from first principles. The signer produces a signature over the content with their private key — over a hash for RSA and ECDSA, or over the content directly for EdDSA; the verifier reconstructs the same input, then runs the algorithm's verify operation on the public key, the signature, and that input. A valid result proves the bytes are intact and that the private-key holder signed them.

En un PDF real, NextPDF no estampa el sello sobre la página visible: lo estampa sobre un intervalo de bytes declarado, y empaqueta la firma como un objeto CMS separado (SpecSpec: RFC 5652RFC 5652) colocado dentro del archivo (SpecSpec: ISO 32000-2, §12.8ISO 32000-2 §12.8). Un matiz importa: el firmante no firma directamente el hash crudo del contenido. Firma un pequeño conjunto de atributos firmados que incluyen el hash del contenido, de modo que la hora, el tipo de contenido y el identificador del certificado del firmante quedan sellados juntos. Dónde residen esos bytes, y por qué el intervalo tiene la forma que tiene, es el objeto de Cómo se ubican las firmas en un PDF.

Hasta aquí, las matemáticas prueban que una clave firmó estos bytes. No dicen nada sobre de quién es la clave. Esa laguna es exactamente lo que llena un certificado. Un certificado es en sí mismo una declaración firmada —por una autoridad de certificación— de que esta clave pública pertenece a este sujeto nombrado. Confiar en él significa seguir la cadena desde el certificado del firmante hasta una autoridad en la que hayas decidido confiar, comprobando la validez de cada eslabón por el camino (SpecSpec: RFC 5280, §6RFC 5280 §6). Sin esa cadena, «firmado» es anónimo. Con ella, «firmado» tiene un nombre.

La última pieza es cuándo. Una firma puede incrustar la propia hora reclamada del firmante, pero un reloj que no controlas es una afirmación, no una prueba. Una marca de tiempo de una Autoridad de Sellado de Tiempo liga un hash de la firma a un instante, atestiguado por una parte sin interés en el documento (SpecSpec: RFC 3161, §1RFC 3161 §1). Eso es lo que permite que una firma siga teniendo sentido después de que caduque el certificado del firmante: puedes demostrar que la firma existía mientras el certificado todavía era válido. El tratamiento más profundo está en Marcas de tiempo y tiempo de confianza.

Ejemplo práctico

Las formas de más abajo son las operaciones conceptuales, escritas con sencillez. El objetivo no es una llamada de API: es ver que firmar y verificar son imágenes especulares, y que un byte manipulado rompe la coincidencia por construcción.

<?php

declare(strict_types=1);

// SIGN — the holder of the private key seals the content.
// RSA and ECDSA sign a hash; EdDSA signs the content directly (hashing inside).
$signingInput = sign_input($content);            // a digest for RSA/ECDSA, the content for EdDSA
$signatureValue = private_key_transform(         // only the key holder can do this
    privateKey: $signerPrivateKey,
    input: $signingInput,
);

// VERIFY — anyone with the public key runs the algorithm's check.
$recomputedInput = sign_input($content);          // verifier rebuilds the same input
$intactAndAuthentic = signature_verify(           // RSA, ECDSA, EdDSA — same shape
    publicKey: $signerPublicKey,                  // taken from the certificate
    signatureValue: $signatureValue,
    input: $recomputedInput,                       // the freshly reconstructed input
);
// true  -> bytes unchanged AND signed by the private-key holder
// false -> a byte changed, or the wrong key — the honest answer is "invalid"

// The certificate answers a SEPARATE question: whose public key is this?
// The timestamp answers ANOTHER: when did this signature exist?
// "intact + authentic" alone proves neither identity nor time.

Falsificar un cambio que aún verifique es computacionalmente inviable. El hash transporta el contenido con fidelidad, de modo que alterar el contenido altera el hash, y la operación de verificación lo rechaza, salvo que se encuentre una colisión de hash, algo que la función elegida está diseñada para volver impracticable.

Idea equivocada habitual

El error frecuente es leer «firma válida» como «documento fiable». No son la misma frase. La criptografía prueba que los bytes están intactos y que el poseedor de la clave privada los firmó: nada más. Un documento firmado con una clave de la que nunca has oído hablar, atestiguada por ninguna autoridad que reconozcas, puede ser impecablemente «válido» y no valer nada. La identidad proviene del certificado y su cadena; el tiempo proviene de una marca de tiempo de confianza. Una marca de verificación verde que en silencio pliega todo esto en un único booleano ha decidido, en tu nombre, qué preguntas importaban. Conocer las piezas es lo que permite hacer las demás.

Human-factors note:Human-factors note

The reason to separate these ideas is not pedantry — it is so the word “signed” stays honest. Integrity, identity, and time are three distinct proofs, established by three distinct mechanisms (a hash plus a key pair, a certificate chain, and a timestamp authority). A tool that reports them as one flag is easier to read and far easier to misread. NextPDF keeps them separate, in its output and in its tests, so a result that says “valid” can be unpacked into exactly what was proven.

Límites y fronteras

Esta página explica la idea de una firma digital, no el procedimiento de validación completo. Las matemáticas de aquí prueban integridad y autenticidad. No te dicen, por sí solas, si el certificado de firma se emitió a quien crees, si era válido en el momento de la firma o si se revocó después: esas son cuestiones de ruta de certificación y de revocación, y una validación correcta las ejecuta todas. El conjunto completo de comprobaciones está en Validar correctamente una firma.

NextPDF construye la estructura de la firma y realiza las comprobaciones criptográficas. No elige tus anclas de confianza, no avala a ninguna autoridad de certificación ni decide el efecto jurídico de una firma: eso depende de tu despliegue, del certificado y de la jurisdicción. El motor prueba el mecanismo; las decisiones de confianza que se construyen encima son tuyas.

Lo que el motor incluye, por nivel, se construye hacia fuera desde esta base:

Digital signature: integrity, identity, and trusted time — edition availability

Edition	Availability
Core	○ PAdES B-B: the hash-and-sign mechanism described here, packaged as a detached CMS SignedData object, plus certificate-path validation against a trust anchor you supply.
Pro	○ Adds PAdES B-T — a verified RFC 3161 trusted timestamp on the signature value, so the “when” is attested rather than self-claimed.
Enterprise	○ Adds the long-term profiles (B-LT, B-LTA): embedded validation material and document timestamps that keep the identity and time proofs answerable for years.

Documentos relacionados

• Cómo se ubican las firmas en un PDF — dónde residen realmente en el archivo el valor de firma y su intervalo de bytes.
• Validar correctamente una firma — el conjunto completo de comprobaciones que un verificador debe ejecutar, más allá de las matemáticas de esta página.
• Marcas de tiempo y tiempo de confianza — qué prueba una marca de tiempo RFC 3161 y por qué el propio reloj de un firmante no lo es.
• Perfiles de base PAdES — qué perfil superpone identidad, tiempo y material de largo plazo sobre esta base.

Glosario

• Hash (resumen) — una huella corta y de longitud fija de unos datos, producida por una función de hash criptográfica; cualquier cambio en los datos la cambia por completo.
• Par de claves — una clave privada vinculada (que solo posee el firmante) y una clave pública (compartida libremente); solo la clave privada puede firmar, y solo la clave pública correspondiente puede verificar.
• Firmar — aplicar la operación de clave privada a la entrada que define el algoritmo: un hash del contenido para RSA y ECDSA, o el contenido directamente para EdDSA (que hace el hash internamente). En un PDF, ese contenido son los atributos firmados, que incluyen el hash del documento. El resultado es el valor de firma.
• Verificar — reconstruir la misma entrada (un hash recalculado, o el contenido directamente para EdDSA) y luego ejecutar la operación de verificación del algoritmo sobre la clave pública, el valor de firma y esa entrada para obtener una respuesta de válida o inválida.
• Valor de firma — los bytes que produce la operación de clave privada; lo que un verificador comprueba frente a la entrada de algoritmo recién reconstruida (un resumen para RSA y ECDSA, el propio contenido para EdDSA).
• Certificado — una declaración firmada que liga una clave pública a una identidad nombrada; se confía en él encadenándolo a una autoridad que aceptas (RFC 5280 §6).
• Ancla de confianza — una autoridad de certificación en la que has decidido confiar; la raíz de una cadena de certificados aceptable.
• Marca de tiempo (RFC 3161) — un token firmado de una Autoridad de Sellado de Tiempo que liga un hash a un valor temporal, proporcionando prueba de confianza de cuándo.
• CMS SignedData — la estructura de Cryptographic Message Syntax (RFC 5652) que transporta el valor de firma y el certificado del firmante.
• PAdES — PDF Advanced Electronic Signatures: la familia de perfiles ETSI para firma de PDF. Tratada en profundidad en las páginas de firma.