Signatures numériques pour fichiers : prouver l'authenticité

Une signature numérique est une preuve cryptographique qu'une personne ou entité spécifique a créé un fichier et que celui-ci n'a pas été modifié depuis. Concrètement, vous hachez le fichier avec SHA-256, puis vous « signez » ce hachage avec votre clé privée via RSA-PSS, ECDSA ou Ed25519. Toute personne disposant de votre clé publique peut vérifier la signature — si elle est valide, elle sait que vous êtes l'auteur du fichier et qu'il est identique octet par octet à ce que vous avez signé. C'est ce que macOS utilise pour vérifier les mises à jour d'applications, ce que Git utilise pour l'attribution des commits (git commit -S), et ce que PGP utilise pour les e-mails signés. Les signatures résolvent un problème que le chiffrement seul ne peut pas résoudre : prouver qui a envoyé quoi.

Signatures et chiffrement : des rôles distincts

Le chiffrement garde le contenu secret. Les signatures prouvent l'authorship et l'intégrité. Elles sont complémentaires, pas alternatives.

Chiffrement seul : le destinataire connaît le contenu mais pas l'expéditeur. N'importe qui ayant la clé publique aurait pu chiffrer le message.
Signature seule : le destinataire sait qui a envoyé et que le fichier n'a pas été altéré, mais le contenu est visible pour quiconque intercepte le transfert.
Signature et chiffrement : authenticité, intégrité et confidentialité complètes. Le mode par défaut de PGP.

Les services de transfert de fichiers se concentrent généralement sur le chiffrement. Les signatures entrent en jeu dans les contextes à haute confiance : distribution de logiciels, documents juridiques, contrats, chaînes de preuves forensiques.

Le fonctionnement concret de la signature

Le flux de signature canonique avec Ed25519 :

Hacher le message : h = SHA-512(message).
Calculer un nonce déterministe : r = SHA-512(préfixe_clé_privée || h).
Calculer le point de signature : R = r·G (où G est le point de base de la courbe).
Calculer s = r + SHA-512(R || clé_publique || h)·clé_privée mod ℓ.
La signature est (R, s), soit 64 octets au total.

La vérification n'utilise que la clé publique, le message et la signature. Si le calcul est correct, le vérificateur sait que la signature a été produite par quelqu'un détenant la clé privée correspondante.

RSA-PSS (PKCS#1 v2.2) et ECDSA fonctionnent de manière similaire mais avec des mathématiques sous-jacentes différentes. Ed25519 est préféré pour les nouveaux systèmes car il est déterministe (aucun nonce aléatoire par signature pouvant mal tourner) et plus rapide.

Les trois algorithmes de signature courants

| Algorithme | Taille de clé | Taille de signature | Vitesse | Notes | |-----------|----------|----------------|-------|-------| | RSA-PSS-2048 | 256 octets | 256 octets | ~1 000 sign/s | Très répandu, génération de clé lente | | ECDSA P-256 | 32 octets | 64 octets | ~30 000 sign/s | Courbe NIST, nécessite un RNG sécurisé par signature | | Ed25519 | 32 octets | 64 octets | ~50 000 sign/s | Déterministe, référence moderne |

Les trois sont approuvés dans FIPS 186-5 du NIST (2023). Ed25519 est le choix pour les nouveaux protocoles : WireGuard, SSH (par défaut depuis OpenSSH 8.0), Signal, la signature des commits Git, et la signature des paquets Cargo de Rust.

La signature de code : un cas d'usage à plusieurs milliards d'euros

La distribution de logiciels repose sur les signatures. Sans elles, les utilisateurs ne peuvent pas distinguer le vrai installateur d'un malware :

Apple Developer ID + Notarisation. Toutes les applications macOS doivent être signées et notariées depuis Catalina (2019). Utilise RSA-2048 ou ECDSA P-256.
Microsoft Authenticode. Les exécutables Windows signés avec des certificats RSA-3072 ou ECDSA P-384.
Android APK v2/v3. Signatures Ed25519 sur le contenu des APK.
Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Tous utilisent des signatures détachées (généralement GPG Ed25519 ou RSA) sur les manifestes de paquets.

Un incident célèbre : en 2020, la mise à jour d'Orion de SolarWinds a été signée avec le certificat légitime de l'entreprise après que des attaquants eurent compromis le système de build. La signature était valide — elle prouvait simplement que le code provenait d'une source compromise. Les signatures garantissent l'identité du signataire, pas son jugement.

PGP et les signatures détachées pour les fichiers

GnuPG (gpg) reste l'outil de référence pour les signatures de fichiers en dehors de l'infrastructure PKI d'entreprise. Une signature détachée laisse le fichier intact et place la signature dans un fichier .sig séparé :

gpg --detach-sign --armor document.pdf
# Produit document.pdf.sig

gpg --verify document.pdf.sig document.pdf
# gpg: Bonne signature de "Alice <alice@example.com>"

La faiblesse de PGP réside dans la distribution des clés : comment le vérificateur sait-il que la clé de signature appartient vraiment à Alice ? Les options incluent les serveurs de clés, la toile de confiance, keybase.io, ou la vérification hors bande (empreinte publiée sur une carte de visite).

Alternatives modernes : Sigstore (utilisé par Kubernetes, npm) effectue une signature sans clé via des tokens d'identité OIDC, avec des journaux de transparence remplaçant la toile de confiance. minisign de Frank Denis offre une signature Ed25519 simple sans la complexité de PGP.

Agrégation de signatures par hachage

Pour des collections de fichiers, signer chacun individuellement est inefficace. Mieux : hacher chaque fichier, construire un arbre de Merkle, signer la racine. Avantages :

Une seule signature couvre de nombreux fichiers.
Les fichiers individuels peuvent être vérifiés par rapport à la racine avec log(n) hachages frères.
Utilisé par les journaux de transparence des certificats, Git, et de plus en plus par les outils de chaîne d'approvisionnement logicielle comme in-toto.

Une version de 10 000 fichiers signée ainsi produit une seule signature plus un hachage racine de 32 octets, vérifiable pour n'importe quel sous-ensemble des fichiers.

L'horodatage : prouver le quand

Une signature prouve le qui, mais pas le quand. Un attaquant qui vole votre clé privée peut antidater des signatures. Les Autorités d'Horodatage de Confiance (TSA) résolvent ce problème en signant un horodatage sur votre signature, l'ancrant à un moment précis.

Standards :

RFC 3161 — utilisé par Microsoft Authenticode, les signatures PDF Adobe.
RFC 5544 (CMS avec horodatages).
Roughtime — un protocole plus récent de Google pour un temps vérifié à faible latence.

La signature électronique de documents juridiques (DocuSign, Adobe Sign, signatures qualifiées eIDAS de l'UE) repose sur les horodatages RFC 3161 d'autorités de confiance pour établir le moment de la signature d'un contrat.

Les signatures dans le transfert de fichiers

La plupart des services de transfert de fichiers grand public n'exposent pas directement les signatures — le tag d'authentification AES-GCM prouve l'intégrité au sein du transfert, et TLS prouve l'identité du serveur, mais il n'existe pas de moyen intégré de prouver l'identité de l'expéditeur.

Pour les transferts à haute confiance, la signature se fait avant l'envoi :

L'expéditeur signe le fichier avec Ed25519 ou PGP, produisant fichier.ext et fichier.ext.sig.
Les deux fichiers sont envoyés via n'importe quel service de transfert (HexaTransfer, SwissTransfer, WeTransfer).
Le destinataire télécharge les deux, vérifie la signature avec la clé publique de l'expéditeur.

Cela dissocie l'authenticité du mécanisme de transfert — le service de transfert pourrait être compromis sans invalider la signature, tant que la clé privée de l'expéditeur reste secrète et que le destinataire dispose de la bonne clé publique.

Les signatures qualifiées eIDAS de l'UE

Le règlement eIDAS de l'Union européenne (UE 910/2014, révisé en 2024 sous eIDAS 2.0) définit trois niveaux de signature :

Signature électronique — basique, inclut les signatures manuscrites numérisées.
Signature électronique avancée (SEA/AdES) — liée au signataire, détecte les altérations. Les signatures PGP qualifient.
Signature électronique qualifiée (SEQ) — AdES plus un certificat qualifié d'un Prestataire de Services de Confiance, stocké sur un Dispositif de Création de Signature Qualifié (carte à puce ou HSM).

La SEQ a la même valeur juridique qu'une signature manuscrite dans tous les États membres de l'UE. Les prestataires incluent DocuSign EU, Adobe Sign EU, Namirial et DTrust. Les équivalents sous les lois ESIGN et UETA aux États-Unis sont moins formellement hiérarchisés mais fonctionnellement comparables.

Quand les signatures sont superflues

Tous les fichiers n'ont pas besoin de signature. Vous pouvez vous en passer lorsque :

Le destinataire fait confiance au canal de transfert de bout en bout (Signal, USB remis en main propre).
Le contenu n'est pas critique pour la sécurité (photos de réunion, recettes, brouillons).
L'intégrité seule suffit et est assurée par AES-GCM ou TLS.

Ajoutez des signatures quand :

Le poids juridique ou contractuel est en jeu (contrats, preuves judiciaires, dossiers médicaux).
La confiance dans la chaîne d'approvisionnement est concernée (versions de logiciels, mises à jour de firmware).
Le fichier sera transmis via des intermédiaires non fiables.
Vous avez besoin d'une piste d'audit durable qui survit au transfert original.

Mise en pratique

Pour un flux de travail simple : générez une clé Ed25519 avec ssh-keygen -t ed25519 -f ~/.ssh/cle_signature, signez un fichier avec openssl pkeyutl -sign -inkey cle_signature -in fichier -out fichier.sig, partagez votre clé publique hors bande, et expédiez le fichier via n'importe quel service de transfert sécurisé. Les destinataires vérifient avec openssl pkeyutl -verify.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.