Comment une signature numérique prouve qui a signé

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

En bref

Une signature numérique fait trois choses, et il vaut la peine de les garder distinctes dès le départ : elle prouve que les octets n’ont pas changé, elle prouve qui les a signés, et — avec un peu d’aide — elle prouve quand. Cette page construit cette idée à partir de rien, pour que la cryptographie cesse d’être une boîte noire.

Pourquoi c’est important

« Signé » est un mot sur lequel les gens engagent des décisions. Un contrat, une facture, une note de version pour un logiciel que quelqu’un exécutera. Si tu sais seulement qu’un outil a affiché une coche verte, tu ne sais pas vraiment ce qui a été prouvé. Tu as peut-être la preuve que les octets sont intacts, mais aucune idée de la clé qui les a signés. Tu as peut-être un vrai signataire, mais un certificat qui a expiré il y a des années. Comprendre les pièces, c’est ce qui te permet de dire, précisément, ce que signifie une signature valide — et, tout aussi utilement, ce qu’elle ne signifie pas.

La version courte

Imagine une enveloppe inviolable portant un sceau personnel pressé dans le rabat.

Le sceau est propre à une seule personne et concrètement impossible à contrefaire. Tout le monde peut le reconnaître ; seul son propriétaire peut le produire. C’est la paire de clés : une clé privée que toi seul détiens, et une clé publique que tout le monde peut voir.
Tu ne presses pas le sceau sur l’ensemble du document. Tu le presses sur un résumé minuscule et infalsifiable de celui-ci — une empreinte (hash). Change un seul octet du document et le résumé change complètement, si bien que le sceau ne correspond plus.
Signer, c’est produire une signature sur le document avec ta clé privée — sur l’empreinte pour RSA et ECDSA, ou sur le contenu lui-même pour EdDSA, qui effectue son propre hachage en interne. Vérifier, c’est exécuter le contrôle de l’algorithme avec ta clé publique, la signature et le même contenu (sous forme d’empreinte, ou directement) — cela renvoie valide ou invalide. Ce sont les mathématiques, pas la confiance, qui relient les deux.
Un certificat est la pièce qui dit à qui appartient ce sceau. Sans lui, tu as prouvé qu’une clé a signé les octets, mais pas que la clé appartient à quelqu’un en particulier.
Un horodatage est la pièce qui dit quand. L’horloge du signataire n’est qu’une affirmation ; le temps de confiance provient d’une autorité extérieure.

L’approche de NextPDF

Commence par l’empreinte, car tout le reste repose sur elle. Une fonction de hachage cryptographique lit n’importe quelle quantité de données et produit une empreinte courte et de longueur fixe — pour une signature PDF, typiquement une valeur de 256 bits. Deux propriétés la rendent utile : la même entrée produit toujours la même empreinte, et il est impossible en pratique de trouver une entrée différente ayant la même. Une empreinte est donc un fidèle substitut du document. Si deux empreintes correspondent, les octets correspondent.

Maintenant la paire de clés. Une clé privée et une clé publique sont mathématiquement liées, mais tu ne peux pas dériver l’une de l’autre dans un délai praticable. Seule la clé privée peut produire une signature valide, et seule la clé publique correspondante peut la contrôler. La signature exploite cette asymétrie : le signataire applique une opération de clé privée à l’entrée que l’algorithme choisi définit — l’empreinte du contenu pour RSA et ECDSA, ou le contenu directement pour EdDSA, qui hache en interne. Le résultat est la valeur de signature. Parce que seul le détenteur de la clé privée a pu la produire, et parce qu’elle est liée à ce contenu, elle prouve deux choses à la fois — le détenteur a signé, et les octets n’ont pas bougé depuis.

La vérification reflète cette logique. Le vérificateur reconstruit la même entrée — en hachant le document pour RSA et ECDSA, ou en prenant le contenu directement pour EdDSA — puis exécute l’opération verify de l’algorithme de signature sur la clé publique, la valeur de signature et cette entrée. L’opération renvoie valide ou invalide — et c’est la même forme que l’algorithme soit RSA, ECDSA ou EdDSA, même si seul RSA peut être imaginé comme « récupérant » littéralement l’empreinte. Valide signifie intact et authentique. Invalide signifie que quelque chose a changé, ou que la mauvaise clé a été utilisée, et la réponse honnête est invalide.

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.
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.
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.
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.
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.

Comment une signature numérique est produite puis contrôlée, à partir des premiers principes. Le signataire produit une signature sur le contenu avec sa clé privée — sur une empreinte pour RSA et ECDSA, ou sur le contenu directement pour EdDSA ; le vérificateur reconstruit la même entrée, puis exécute l'opération verify de l'algorithme sur la clé publique, la signature et cette entrée. Un résultat valide prouve que les octets sont intacts et que le détenteur de la clé privée les a signés.

Dans un vrai PDF, NextPDF ne presse pas le sceau sur la page visible — il le presse sur une plage d’octets déclarée, et empaquette la signature comme un objet CMS détaché (Spec: RFC 5652) placé à l’intérieur du fichier (Spec: ISO 32000-2, §12.8). Une précision compte : le signataire ne signe pas directement l’empreinte brute du contenu. Il signe un petit ensemble d’attributs signés qui incluent l’empreinte du contenu, de sorte que l’heure, le type de contenu et l’identifiant du certificat du signataire sont tous scellés ensemble. L’endroit où ces octets vivent, et la raison pour laquelle la plage a la forme qu’elle a, font l’objet de Comment les signatures se logent dans un PDF.

Jusqu’ici, les mathématiques prouvent qu’une clé a signé ces octets. Elles ne disent rien sur la clé de qui il s’agit. C’est exactement ce vide que comble un certificat. Un certificat est lui-même une déclaration signée — émanant d’une autorité de certification — selon laquelle cette clé publique appartient à ce sujet nommé. Lui faire confiance, c’est suivre la chaîne du certificat du signataire jusqu’à une autorité que tu as décidé d’approuver, en contrôlant la validité de chaque maillon en chemin (Spec: RFC 5280, §6). Sans cette chaîne, « signé » est anonyme. Avec elle, « signé » a un nom.

La dernière pièce, c’est quand. Une signature peut intégrer l’heure que le signataire prétend, mais une horloge que tu ne contrôles pas est une affirmation, pas une preuve. Un horodatage émanant d’une autorité d’horodatage lie une empreinte de la signature à un instant, attesté par une partie qui n’a aucun intérêt dans le document (Spec: RFC 3161, §1). C’est ce qui permet à une signature de rester significative après l’expiration du certificat du signataire : tu peux montrer que la signature existait alors que le certificat était encore valide. Le traitement plus approfondi se trouve dans Horodatages et temps de confiance.

Exemple pratique

Les formes ci-dessous sont les opérations conceptuelles, écrites simplement. Le but n’est pas un appel d’API — c’est de voir que signer et vérifier sont des images miroir, et qu’un octet altéré rompt la correspondance par construction.

<?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.

Forger une modification qui se vérifie quand même est infaisable sur le plan calculatoire. L’empreinte porte fidèlement le contenu, si bien qu’altérer le contenu altère l’empreinte, et l’opération verify le rejette — sauf à trouver une collision d’empreintes, que la fonction choisie est conçue pour rendre impraticable.

Idée reçue courante

L’erreur fréquente consiste à lire « signature valide » comme « document digne de confiance ». Ce ne sont pas la même phrase. La cryptographie prouve que les octets sont intacts et que le détenteur de la clé privée les a signés — rien de plus. Un document signé avec une clé dont tu n’as jamais entendu parler, attestée par aucune autorité que tu reconnais, peut être parfaitement « valide » et ne rien valoir. L’identité vient du certificat et de sa chaîne ; le temps vient d’un horodatage de confiance. Une coche verte qui replie discrètement tout cela en un seul booléen a décidé, à ta place, quelles questions comptaient. Connaître les pièces, c’est ce qui te permet de poser les autres.

Limites et frontières

Cette page explique l’idée d’une signature numérique, pas la procédure de validation complète. Les mathématiques ici prouvent l’intégrité et l’authenticité. Elles ne te disent pas, à elles seules, si le certificat de signature a été délivré à qui tu penses, s’il était valide au moment de la signature, ou s’il a été révoqué par la suite — ce sont des questions de chemin de certification et de révocation, et une validation correcte les exécute toutes. L’ensemble complet des contrôles se trouve dans Valider correctement une signature.

NextPDF construit la structure de signature et effectue les contrôles cryptographiques. Il ne choisit pas tes ancres de confiance, ne se porte garant d’aucune autorité de certification, et ne décide pas de l’effet juridique d’une signature — cela dépend de ton déploiement, du certificat et de la juridiction. Le moteur prouve le mécanisme ; les décisions de confiance qui s’y superposent sont les tiennes.

Ce que le moteur livre, par palier, se construit vers l’extérieur à partir de cette fondation :

Digital signature: integrity, identity, and trusted time — edition availability
Edition	Availability
Core	PAdES B-B : le mécanisme de hachage-et-signature décrit ici, empaqueté comme un objet CMS SignedData détaché, plus la validation du chemin de certification par rapport à une ancre de confiance que tu fournis.
Pro	Ajoute PAdES B-T — un horodatage de confiance RFC 3161 vérifié sur la valeur de la signature, de sorte que le « quand » est attesté plutôt qu’auto-déclaré.
Enterprise	Ajoute les profils à long terme (B-LT, B-LTA) : preuves de validation intégrées et horodatages de document qui maintiennent les preuves d’identité et de temps répondables pendant des années.

Documents liés

Comment les signatures se logent dans un PDF — où la valeur de signature et sa plage d’octets vivent réellement dans le fichier.
Valider correctement une signature — l’ensemble complet des contrôles qu’un vérificateur doit exécuter, au-delà des mathématiques de cette page.
Horodatages et temps de confiance — ce que prouve un horodatage RFC 3161, et pourquoi l’horloge du signataire n’en est pas.
Profils de référence PAdES — quel profil superpose l’identité, le temps et le matériel à long terme à cette fondation.

Glossaire

Empreinte (hash, digest) — une empreinte courte et de longueur fixe de données, produite par une fonction de hachage cryptographique ; tout changement des données la modifie complètement.
Paire de clés — une clé privée liée (détenue seulement par le signataire) et une clé publique (partagée librement) ; seule la clé privée peut signer, et seule la clé publique correspondante peut vérifier.
Signer — appliquer l’opération de clé privée à l’entrée que l’algorithme définit : une empreinte du contenu pour RSA et ECDSA, ou le contenu directement pour EdDSA (qui hache en interne). Dans un PDF, ce contenu est constitué des attributs signés, qui incluent l’empreinte du document. Le résultat est la valeur de signature.
Vérifier — reconstruire la même entrée (une empreinte recalculée, ou le contenu directement pour EdDSA), puis exécuter l’opération verify de l’algorithme sur la clé publique, la valeur de signature et cette entrée pour obtenir une réponse valide-ou-invalide.
Valeur de signature — les octets que produit l’opération de clé privée ; ce qu’un vérificateur contrôle face à l’entrée d’algorithme fraîchement reconstruite (une empreinte pour RSA et ECDSA, le contenu lui-même pour EdDSA).
Certificat — une déclaration signée liant une clé publique à une identité nommée ; à laquelle on fait confiance en remontant la chaîne jusqu’à une autorité que tu acceptes (RFC 5280 §6).
Ancre de confiance — une autorité de certification que tu as décidé d’approuver ; la racine d’une chaîne de certificats acceptable.
Horodatage (RFC 3161) — un jeton signé émanant d’une autorité d’horodatage liant une empreinte à une valeur de temps, fournissant une preuve de confiance du quand.
CMS SignedData — la structure Cryptographic Message Syntax (RFC 5652) qui porte la valeur de signature et le certificat du signataire.
PAdES — PDF Advanced Electronic Signatures : la famille de profils ETSI pour la signature de PDF. Traitée en profondeur sur les pages de signature.