Signature numérique : comment fonctionnent clés et hachage

Le problème : un fichier peut dire n’importe quoi

Mariama dirige une petite entreprise à Conakry. Elle conclut un prêt de 5 000 000 GNF avec la société d’Ibrahima, et le contrat circule sous forme de fichier. Or un fichier n’est qu’une suite d’octets, et des octets se modifient facilement. Si quelqu’un change un chiffre en route, le montant devient 6 000 000 GNF, et le fichier s’ouvre toujours et garde toujours l’air sérieux.

Sur papier, on comparerait l’encre, les paraphes sur chaque page, l’exemplaire conservé par chaque partie. Pour un fichier, Ibrahima a besoin de deux réponses qu’il peut vérifier lui-même :

• Est-ce exactement le fichier qui a été signé, octet pour octet ?
• Quelle clé l’a signé ?

La signature numérique répond aux deux. Elle ne répond pas, à elle seule, à une troisième question qu’on lui prête souvent : quelle personne se trouvait derrière cette clé. Cet article montre comment fonctionne le mécanisme, l’exécute sur un vrai fichier et indique où s’arrêtent ses garanties.

Les normes du NIST et de l’IETF citées ici n’existent qu’en anglais : leurs citations sont traduites par nos soins.

Signature électronique ou signature numérique ?

On emploie souvent les deux expressions comme des synonymes. Elles ne désignent pas le même genre de chose.

La signature électronique (electronic signature) est une notion juridique. La loi guinéenne sur les transactions électroniques la définit dès son premier article comme « toute donnée qui résulte d’un procédé fiable d’identification, de nature à garantir ou authentifier son lien avec l’acte auquel elle s’attache » (L/2016/035/AN, art. 1).

Cette définition ne cite aucun algorithme. La loi ne définit d’ailleurs pas du tout la « signature numérique ». Notre lecture, qui ne constitue pas un avis juridique, est que la définition est neutre sur le plan technologique : elle exige un procédé fiable et un lien avec le document, et laisse la technique ouverte.

La signature numérique (digital signature) est un mécanisme cryptographique. Le Digital Signature Standard la définit comme « le résultat d’une transformation cryptographique de données qui, correctement mise en œuvre, fournit un mécanisme de vérification de l’authentification de l’origine, de l’intégrité des données et de la non-répudiation (non-repudiation) par le signataire » (FIPS 186-5, §2.1). C’est une façon de produire ce que la loi appelle une signature électronique, et c’est celle dont traite cette série.

L’article 34 va plus loin. Son alinéa 5 donne à une signature sécurisée liée à un certificat qualifié la même force ou valeur probante qu’une signature manuscrite. Son alinéa 1 emploie lui aussi la formule de la signature manuscrite, avec des conditions différentes : un dispositif fiable et sécurisé sous le contrôle exclusif du signataire, et un « certificat numérique ». L’articulation des deux alinéas est une question pour un avocat guinéen, et rien de ceci ne constitue un avis juridique. L’article 34 précise aussi qu’une signature ne peut pas être refusée au seul motif qu’elle est électronique (art. 34). Les deux alinéas comptent un certificat parmi leurs conditions : une signature numérique, à elle seule, ne remplit ni l’un ni l’autre. Pour aller plus loin sur le texte guinéen, lisez ce que dit vraiment le droit guinéen sur la signature électronique.

L’image scannée d’une signature manuscrite n’est ni l’une ni l’autre. Elle ne prouve rien sur le fichier qui l’entoure, et c’est pourquoi la signature scannée n’est pas une signature électronique. Pour le point de vue du signataire sur un parcours de signature complet, du lien reçu jusqu’au fichier scellé, lisez comment fonctionne vraiment une signature électronique. La suite de cet article ouvre la cryptographie qui se trouve à l’intérieur de ce parcours.

Le hachage : une empreinte de taille fixe des octets

Une signature numérique ne travaille pas directement sur le document. Elle le réduit d’abord à une valeur courte, appelée empreinte (message digest), à l’aide d’une fonction de hachage (hash function).

SHA-256 est l’un des algorithmes de hachage sécurisés spécifiés par FIPS 180-4, aux côtés de SHA-1, SHA-224, SHA-384, SHA-512, SHA-512/224 et SHA-512/256. Il accepte un message de moins de 2^64 bits et produit toujours une empreinte de 256 bits : 32 octets, qu’on écrit généralement sous forme de 64 caractères hexadécimaux (FIPS 180-4, §1). Un contrat d’une page et un scan de 10 Mo donnent tous deux 32 octets.

La norme qualifie ces algorithmes de « sécurisés » parce qu’il est calculatoirement impossible :

1. de trouver un message qui produit une empreinte donnée (résistance aux préimages (preimage resistance)) ;
2. de trouver deux messages différents qui produisent la même empreinte (résistance aux collisions (collision resistance)).

Le NIST SP 800-57 emploie ces deux noms (§5.6.1.2). La conséquence pratique, selon les termes de FIPS 180-4 : « toute modification d’un message produira, avec une très forte probabilité, une empreinte différente », et lorsque le hachage est utilisé avec un algorithme de signature numérique, cela « entraînera un échec de la vérification » (FIPS 180-4, point 3).

Pour les signatures, SHA-256 offre au plus 128 bits de sécurité. SHA-1, à l’inverse, « s’est révélé offrir moins de 80 bits de sécurité pour les signatures numériques » (SP 800-57, §5.6.1.2, tableau 3). C’est pourquoi il ne faut plus rien signer de nouveau avec SHA-1.

Les paires de clés : l’une pour signer, l’autre pour vérifier

Un schéma de signature utilise une paire de clés (key pair). La clé privée (private key) produit les signatures et reste chez son propriétaire. La clé publique (public key) « correspond à la clé privée sans être identique à elle » et peut être remise à n’importe qui, car elle ne sert qu’à vérifier (FIPS 186-5, annonce, point 3). Tout le monde peut vérifier ; seul le détenteur de la clé privée peut signer.

FIPS 186-5 approuve trois familles :

• ECDSA, l’algorithme à courbes elliptiques utilisé dans la partie pratique ci-dessous (§6.4). Ses courbes proviennent du SP 800-186. P-256 en fait partie : elle est classée au niveau de sécurité de 128 bits et autorisée pour ECDSA (SP 800-186, §3.2.1.3). Avec SHA-256, lui aussi à 128 bits, elle forme une paire équilibrée, ce que recommande FIPS 186-5 (FIPS 186-5, §6.1.1) (SP 800-57, §5.6.1.1).
• RSA, spécifié dans PKCS #1 (RFC 8017). FIPS 186-5 exige un module d’au moins 2048 bits. Le SP 800-57 classe RSA-2048 à 112 bits et RSA-3072 à 128 bits de sécurité.
• EdDSA. Contrairement aux deux autres, EdDSA dans sa forme pure ne hache pas le message au préalable ; la suite de cet article décrit le schéma « hacher puis signer » utilisé par RSA, ECDSA et HashEdDSA.

DSA, l’ancien algorithme, n’est plus approuvé pour produire des signatures, seulement pour vérifier les anciennes (FIPS 186-5, §4). Et une paire de clés de signature « ne doit être utilisée à aucune autre fin », par exemple l’établissement de clés (§3).

Signer et vérifier

Voici le parcours complet, tel que FIPS 186-5 le décrit pour les schémas qui hachent puis signent (§3, §3.2, §3.3).

La signature. Le signataire hache le document, puis applique l’algorithme de signature à l’empreinte avec sa clé privée. Le résultat est la signature. Le signataire peut vérifier sa propre signature aussitôt, pour se prémunir contre une erreur de calcul (§3.2).

L’envoi. Le document et la signature partent tous deux chez le vérificateur. La signature ne cache pas le document : quiconque possède le fichier peut toujours le lire.

La vérification. Le vérificateur hache à nouveau le document reçu avec la même fonction de hachage, « et non la signature numérique reçue ». Il applique ensuite l’algorithme de vérification à cette empreinte, à la signature et à la clé publique du signataire présumé. Le résultat est une acceptation ou un rejet (§3.3).

Pour ECDSA, les étapes qui se cachent derrière « signer » et « vérifier » ressemblent à ceci. Inutile de suivre l’algèbre : c’est la forme d’ensemble qui compte.

Pseudocode conceptuel

# ECDSA over curve P-256 with SHA-256 (FIPS 186-5, §6.4.1 and §6.4.2, simplified)
# G = the curve's base point, n = its order, d = private key, Q = [d]G = public key

sign(M, d):
    e = integer(SHA256(M))
    k = fresh secret random number in [1, n-1]    # new for every signature
    r = x([k]G) mod n
    s = k^-1 * (e + r*d) mod n
    destroy k
    return (r, s)                                 # the signature is two integers

verify(M, (r, s), Q):
    reject unless 1 <= r, s <= n-1
    e  = integer(SHA256(M))                       # the verifier hashes M itself
    u  = e * s^-1 mod n
    v  = r * s^-1 mod n
    R1 = [u]G + [v]Q
    accept if r == x(R1) mod n, else reject

Deux détails en découlent. Le nombre k doit être nouveau pour chaque signature et protégé comme la clé privée : un k faible peut révéler la clé privée. L’ECDSA déterministe (RFC 6979) dérive k du message et de la clé pour ne pas dépendre d’une bonne source d’aléa (§6.3). Et comme k est aléatoire, signer deux fois le même fichier donne deux signatures différentes, qui se vérifient toutes les deux (chaque exécution utilise en outre une nouvelle clé). Vous le constaterez si vous lancez plusieurs fois les exemples ci-dessous.

L’article 6 montre où cette signature se loge dans un PDF.

Mariama signe, Ibrahima vérifie

Revenons au prêt. Le contrat tient en une ligne de texte :

Contrat de pret 2026-001 : montant 5000000 GNF

1. Mariama génère une paire de clés P-256. Elle garde la clé privée et remet la clé publique à Ibrahima.
2. Elle hache le contrat avec SHA-256 et signe l’empreinte avec sa clé privée. Elle envoie le contrat et la signature.
3. Ibrahima hache le contrat qu’il a reçu, puis vérifie la signature sur cette empreinte avec la clé publique de Mariama. Le résultat est « Verified OK ».
4. En route, quelqu’un modifie le montant : 5000000 devient 6000000. Un seul octet diffère.
5. Ibrahima refait la même vérification. L’empreinte a changé, donc la vérification échoue.

Ce que cet échec apprend à Ibrahima est limité : cette signature ne se vérifie pas pour ces octets avec cette clé. Il ne lui dit pas quel octet a changé, ni si c’est le fichier ou la signature qui a été altéré (FIPS 186-5, §3.3). La seule attitude sûre est de rejeter le fichier et d’en demander une nouvelle copie.

À vous : signer, vérifier, falsifier

Tout ce qui suit s’exécute dans des conteneurs jetables, avec des clés générées sur le moment. N’utilisez jamais ces commandes avec une vraie clé.

Avec OpenSSL

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

docker run --rm -w /w alpine:3.22 sh -c '
apk add --no-cache openssl >/dev/null && openssl version &&
printf "Contrat de pret 2026-001 : montant 5000000 GNF\n" > contrat.txt &&
openssl dgst -sha256 contrat.txt &&
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out mariama.key &&
openssl pkey -in mariama.key -pubout -out mariama.pub &&
openssl dgst -sha256 -sign mariama.key -out contrat.sig contrat.txt &&
openssl dgst -sha256 -verify mariama.pub -signature contrat.sig contrat.txt;
sed -i "s/5000000/6000000/" contrat.txt && openssl dgst -sha256 contrat.txt;
openssl dgst -sha256 -verify mariama.pub -signature contrat.sig contrat.txt; echo "exit=$?"'

Le script affiche la version d’OpenSSL, hache le contrat, génère la paire de clés de Mariama (mariama.key reste privée, mariama.pub est partagée), signe, puis vérifie. Ensuite, sed modifie le montant, et le script hache et vérifie à nouveau. Si Docker doit d’abord télécharger l’image, ses lignes de progression s’affichent avant cette sortie.

OpenSSL 3.5.8 25 Aug 2026 (Library: OpenSSL 3.5.8 25 Aug 2026)
SHA2-256(contrat.txt)= 0c53f84a6928871a965328cc983d0a20d07f16dd69a3b273847aa2a9f54cff4c
Verified OK
SHA2-256(contrat.txt)= 4f4190dbac57acddb0cd0d887a89bb70753c88c56e153c4fe043178492db1c4f
20ED09B8FFFF0000:error:030000EA:digital envelope routines:EVP_DigestVerifyFinal:provider signature failure:crypto/evp/m_sigver.c:703:ECDSA digest_verify_final:
Verification failure
exit=1

Les deux empreintes sont celles du schéma plus haut. L’empreinte d’un fichier donné est la même à chaque exécution et sur chaque machine. Le fichier de signature, contrat.sig, change à chaque fois, à cause du k aléatoire. La ligne d’erreur qui précède « Verification failure » est le diagnostic interne d’OpenSSL. Ce qu’il faut regarder, ce sont les deux dernières lignes : la vérification a échoué, et la commande s’est terminée avec le code de sortie 1, qu’un script peut tester. alpine:3.22 suit la dernière version 3.22.x : la ligne de version d’OpenSSL et le préfixe de la ligne d’erreur (20ED09B8FFFF0000) peuvent donc varier d’une exécution à l’autre et d’une machine à l’autre. Le préfixe change à chaque exécution, et la version d’OpenSSL dépend du dépôt de paquets Alpine au moment de l’installation.

Avec Python

Exemple pédagogique exécutable · Docker · python:3.12-alpine · cryptography==50.0.1

Enregistrez le script ci-dessous sous le nom sign_verify.py, puis lancez :

docker run --rm --mount type=bind,src="$PWD/sign_verify.py",dst=/w/sign_verify.py,readonly -w /w python:3.12-alpine sh -c '
pip install cryptography==50.0.1 >/dev/null 2>&1 &&
python3 sign_verify.py'

import cryptography
print("cryptography", cryptography.__version__)

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
from cryptography.exceptions import InvalidSignature

original = b"Contrat de pret 2026-001 : montant 5000000 GNF\n"
tampered = b"Contrat de pret 2026-001 : montant 6000000 GNF\n"

import hashlib
print("SHA2-256(original)=", hashlib.sha256(original).hexdigest())
print("SHA2-256(tampered)=", hashlib.sha256(tampered).hexdigest())

private_key = ec.generate_private_key(ec.SECP256R1())
public_key = private_key.public_key()

signature = private_key.sign(original, ec.ECDSA(hashes.SHA256()))
print("signature bytes (hex):", signature.hex())

# Verify against the original bytes: should succeed silently
public_key.verify(signature, original, ec.ECDSA(hashes.SHA256()))
print("Verified OK")

# Verify against tampered bytes: should raise InvalidSignature
try:
    public_key.verify(signature, tampered, ec.ECDSA(hashes.SHA256()))
    print("UNEXPECTED: verification succeeded on tampered bytes")
except InvalidSignature as e:
    print("InvalidSignature raised as expected:", repr(e))

SECP256R1 est le nom que la bibliothèque donne à P-256. verify ne renvoie rien en cas de succès et lève InvalidSignature en cas d’échec : un try oublié ne peut donc pas accepter silencieusement une mauvaise signature.

cryptography 50.0.1
SHA2-256(original)= 0c53f84a6928871a965328cc983d0a20d07f16dd69a3b273847aa2a9f54cff4c
SHA2-256(tampered)= 4f4190dbac57acddb0cd0d887a89bb70753c88c56e153c4fe043178492db1c4f
signature bytes (hex): 30450220583e9cf400b0c965161bf157b15df4fb4dbdcccf754b44c6e498c6245b700cd2022100c2d2c256856560cc6e8404f772d34e3173e0fc3d5b43854e5a7b4b4791fc93a1
Verified OK
InvalidSignature raised as expected: InvalidSignature()

Les empreintes correspondent exactement à celles de l’exécution OpenSSL : mêmes octets en entrée, même empreinte en sortie. Les octets de la signature seront différents sur votre machine. Ils encodent les deux entiers r et s.

La place de SEDEYA

Le même mécanisme « hacher puis signer » se trouve sous une signature SEDEYA. SEDEYA signe les PDF au format PAdES, jusqu’au niveau B-LTA, avec des horodatages RFC 3161 et les données de validation intégrées au fichier. Les clés de signature sont conservées dans un module matériel de sécurité (hardware security module) (PKCS#11) ou dans un KMS. Et Ibrahima n’a pas besoin d’OpenSSL pour contrôler un document : il peut déposer le PDF sur la page de vérification publique de SEDEYA, ou scanner le QR code imprimé dessus. Les prochains articles de cette série expliquent chacune de ces pièces.

Risques et idées reçues

Une dernière limite à garder à l’esprit : les estimations de niveau de sécurité du SP 800-57 « seront nettement affectées lorsque l’informatique quantique deviendra une réalité pratique » (§5.6.1.1).

En résumé

• La signature électronique est une notion juridique ; le droit guinéen la définit par un procédé fiable d’identification lié au document. La signature numérique est un mécanisme cryptographique, et l’une des façons de la produire.
• SHA-256 réduit n’importe quel document à une empreinte de 256 bits. Toute modification donne, avec une très forte probabilité, une empreinte différente.
• La clé privée signe l’empreinte ; la clé publique la vérifie. Le vérificateur hache toujours le document lui-même.
• La modification d’un seul octet a fait échouer la vérification, avec OpenSSL comme avec Python.
• Une signature valide prouve qu’une clé a signé ces octets. Relier cette clé à une personne demande autre chose, par exemple un certificat.
• Une vérification qui échoue dit seulement « ne se vérifie pas », et non ce qui a changé.

Vérifiez votre compréhension

Prochaine étape

Une signature valide prouve quelle clé a signé, pas qui la détient. L’article 2 traite des certificats et de la PKI qui lient une clé publique à une personne. Vous voulez voir ces vérifications sur un vrai PDF signé ? Parlez-nous : nous vous montrerons comment SEDEYA signe un document et comment n’importe qui peut le vérifier.