Qu'est-ce qu'une signature numérique ?

Les enjeux sont considérables lorsque la signature numérique pose problème. Les processus manuels, les outils disparates et les clés de signature non protégées exposent de nombreuses entreprises au vol de clés et aux attaques de la chaîne d’approvisionnement de type « software ». Chacun de ces incidents érode la confiance que nous accordons aux codes et documents signés. Ce guide explique ce que sont les signatures numériques et comment la signature fonctionne concrètement, passe en revue les problèmes qu’elles permettent de résoudre, compare les principales familles d’algorithmes, de RSA aux algorithmes post-quantiques, et décrit comment les signatures sont utilisées au sein d’ PKI s et protégées à grande échelle. À la fin de ce guide, vous comprendrez à la fois la cryptographie et l’infrastructure qui la rend fiable.

Qu'est-ce qu'une signature numérique ?

Une signature numérique est une valeur cryptographique qui lie l'identité du signataire à une donnée spécifique. Elle permet à quiconque de vérifier deux éléments à la fois : que la donnée n'a pas été modifiée depuis sa signature, et qui en est l'auteur. C'est cette combinaison d'intégrité et d'origine qui confère à la signature sa valeur réelle, au-delà d'une simple fonction décorative.

Cela diffère considérablement d’une simple signature électronique. Une image numérisée de votre écriture manuscrite, un nom saisi au bas d’un e-mail ou une case à cocher « Accepter » enregistrent certes une intention, mais aucun de ces éléments n’est lié de manière cryptographique au contenu. Il suffit de modifier un seul mot dans le document pour que la signature numérisée reste intacte. Une signature numérique (cryptographique), en revanche, est invalidée dès que les données sous-jacentes sont modifiées, et c’est précisément là tout l’intérêt.

La signature consiste à produire cette valeur cryptographique. Le signataire utilise une clé privée pour générer une signature sur les données, et toute personne disposant de la clé publique correspondante peut la vérifier. Le terme « signature » désigne donc l'opération, tandis que « signature numérique » désigne le résultat. Ces deux éléments reposent sur la confidentialité de la clé privée, ce qui explique pourquoi une grande partie de ce guide est consacrée à la protection des clés.

Fonctionnement des signatures numériques : les principes fondamentaux

Au cœur de toute signature numérique se trouve une paire de clés. La clé privée sert à signer, tandis que la clé publique permet de vérifier la signature. Ces deux clés sont mathématiquement liées. La clé publique est dérivée de la clé privée (ou d’une graine privée) à l’aide d’un algorithme efficace, mais il est impossible de déduire la clé privée à partir de la clé publique. Le signataire conserve précieusement sa clé privée. En revanche, il diffuse librement la clé publique, souvent intégrée à un certificat, afin que quiconque puisse valider ce qu’il a produit sans jamais pouvoir le falsifier.

Dans la pratique, les signataires signent rarement les données brutes elles-mêmes. Ils suivent plutôt le modèle classique « hachage puis signature » : les données sont d’abord soumises à un hachage cryptographique, c’est-à-dire une fonction qui produit un résumé court et de longueur fixe, puis ce résumé est signé. C'est pourquoi les noms d'algorithmes se présentent souvent sous cette forme, comme SHA256WithRSA et SHA256WithECDSA, où la première partie désigne l'algorithme de hachage et la seconde l'algorithme de signature. Signer un hachage compact plutôt qu'un fichier binaire de plusieurs gigaoctets permet de garantir la rapidité et la praticité de l'opération.

Le hachage côté client pousse cette idée encore plus loin. Le hachage est calculé côté client ; ainsi, les fichiers volumineux n’ont jamais besoin de transiter par le réseau pour atteindre un service de signature central. Les développeurs peuvent signer rapidement, les équipes gardent le contrôle de leurs artefacts, et même les environnements les plus complexes et à grande échelle conservent leurs performances, car seul un petit résumé est transmis au signataire.

Dans tous les cas, une règle s'impose : les clés de signature privées ne doivent jamais quitter leur espace de stockage sécurisé et chiffré, même pendant la signature. Les architectures les plus sûres génèrent et utilisent la clé au sein d'un environnement protégé hardware, de sorte que la valeur secrète ne soit jamais exposée sur un poste de travail ou un serveur de compilation. La signature est générée ; la clé reste à l'intérieur.

Quels problèmes les signatures numériques permettent-elles de résoudre ?

Les signatures numériques offrent un ensemble de garanties de fiabilité que les fichiers simples ne peuvent tout simplement pas offrir à eux seuls.

• Intégrité.
  Une signature prouve que le code, les documents ou le micrologiciel n'ont pas été altérés, que ce soit pendant leur transfert ou lorsqu'ils sont stockés. Si un seul octet est modifié, la vérification échoue.
• Authenticité.
  Une signature permet de confirmer l'identité du signataire, vous offrant ainsi une preuve fiable de l'identité de la personne ayant signé le message, plutôt qu'une simple affirmation invérifiable.
• Non-répudiation et vérifiabilité.
  Des journaux d'événements détaillés et signables constituent une trace irréfutable des activités de signature, ce qui est inestimable en matière de conformité et de traçabilité. Un signataire ne peut nier devant quiconque une action consignée dans un journal signé.

Il s'agit là de trois des cinq piliers de la sécurité de l'information, les deux autres étant la confidentialité et la disponibilité.

Les signatures permettent également de résoudre d’autres problèmes concrets, tels que la garantie de la sécurité des chaînes d’approvisionnement et la protection contre les logiciels malveillants. La signature de code est une étape essentielle pour empêcher la propagation de logiciels malveillants et bloquer les acteurs malveillants au sein de la chaîne d’approvisionnement de l’ software . Que vous distribuiez des applications, déployiez des scripts et des conteneurs, ou transmettiez des mises à jour à distance vers des appareils IoT , c’est la signature qui permet aux destinataires de faire confiance à l’artefact.

Ensemble, ces caractéristiques expliquent pourquoi la signature électronique est omniprésente, qu’il s’agisse d’ software s publiées, d’images de base de conteneurs, de contrats juridiques ou de cartes d’identité électroniques délivrées par les pouvoirs publics.

Familles d'algorithmes de signature numérique

En coulisses, plusieurs familles d'algorithmes permettent de générer des signatures. Le domaine connaît actuellement une profonde mutation, passant des algorithmes classiques qui ont assuré la sécurité de la signature pendant des décennies à de nouveaux algorithmes post-quantiques conçus pour résister aux futurs ordinateurs quantiques. Comprendre d'abord les familles d'algorithmes classiques permet de suivre beaucoup plus facilement la transition vers les algorithmes post-quantiques.

Signatures RSA

RSA est la norme de référence depuis longtemps. Il a été le choix par défaut pour la signature pendant de nombreuses années et reste très présent, souvent sous la forme de combinaisons « hachage-signature » telles que SHA256WithRSA. Même dans les configurations utilisant des algorithmes plus récents pour la signature, RSA reste fréquemment présent : les paires de clés de chiffrement avec récupération de clé, par exemple, s'appuient souvent encore sur RSA avec des longueurs de 1 024 ou 2 048 bits. RSA est fiable et universellement pris en charge, ce qui explique précisément pourquoi il est si bien ancré.

ECDSA et signatures sur courbes elliptiques

L'algorithme de signature numérique à courbe elliptique (ECDSA) offre un niveau de sécurité comparable à celui du RSA avec des clés beaucoup plus courtes, ce qui est particulièrement intéressant pour les appareils aux ressources limitées et la signature de grands volumes. Pour garantir une stabilité à long terme, il est recommandé d'utiliser les courbes les plus couramment employées. Choisissez P-256, P-384 ou P-521, sauf si une exigence spécifique impose le contraire. Les implémentations basées sur BouncyCastle prennent en charge un large éventail de courbes nommées issues des familles NIST, SEC, X9.62 et Brainpool.

La plupart des déploiements intègrent directement les courbes nommées dans les certificats et les requêtes, conformément aux recommandations de l'IETF. Dans certains cas, vous devez toutefois utiliser des paramètres explicites, une approche imposée par l’Organisation de l’aviation civile internationale (OACI) pour les certificats d’autorité de certification nationale (CSCA) et les certificats de signataire de documents utilisés dans les passeports électroniques. Les paramètres explicites ne doivent être activés que lorsque cela est réellement nécessaire, car ils peuvent enfreindre la norme RFC 5280 et entraîner l’échec de l’inscription dans certains flux d’API REST.

EdDSA (signatures basées sur la courbe d'Edwards)

L'algorithme de signature numérique sur courbes d'Edwards (EdDSA) utilise une variante de la signature de Schnorr basée sur des courbes d'Edwards torsadées ; il est défini dans la RFC 8032. Conçu pour être plus rapide que les schémas de signature existants sans compromettre la sécurité, il constitue aujourd'hui un choix très répandu. Il existe deux variantes : Ed25519 et Ed448, Ed25519 étant de loin la plus largement prise en charge. La prise en charge d'hardware s'est progressivement généralisée au fil du temps, et la plupart des modules d'hardware s testés prennent en charge Ed25519, tandis qu'Ed448 reste moins courant.

Algorithmes de signature post-quantiques

Les algorithmes post-quantiques constituent désormais une quatrième famille incontournable, mais leur description mérite d'être approfondie. Consultez la section consacrée aux algorithmes post-quantiques ci-dessous pour en savoir plus sur les normes, les compromis opérationnels et un exemple concret de migration.

Protocoles et formats utilisant des signatures numériques

Les signatures sont rarement isolées. Elles sont intégrées dans des formats normalisés afin que différents outils et plateformes puissent les générer et les vérifier de manière cohérente.

• Formats de signature de code.
  Il s'agit notamment de MS Authenticode pour les exécutables Windows, les programmes d'installation MSI et les scripts PowerShell ; de la signature de fichiers JAR Java et de la signature Android ; de la signature CMS ; de la signature OpenPGP avec hachage côté client ; de la signature des paquets Debian ; et de la signature des bundles AppX de Microsoft.
• Signature de documents.
  À l'instar de PKI, la signature de documents PDF prend en charge différents niveaux de certification (en fonction des modifications autorisées sur le document) et permet de demander et d'intégrer des réponses d'horodatage.Signatures électroniques avancées(AdES) pourles services d'identification, d'authentification et de confiance électroniques(eIDAS).
   La famille AdES comprend PAdES pour les PDF, CAdES pour la syntaxe de messagerie cryptographique (CMS) et XAdES pour le XML.
• Horodatage.
  Les horodatages sont conformes à plusieurs RFC de l'IETF ainsi qu'à la norme MS Authenticode. Une autorité d'horodatage peut émettre des horodatages conformes à la directive eIDAS afin de prouver la date à laquelle un document a été signé.
• Signature des passeports électroniques.
  Les documents de voyage lisibles par machine (MRTD) de l'OACI s'appuient sur des signatures numériques pour sécuriser les données contenues dans les passeports électroniques.

Comment les signatures numériques sont-elles utilisées au sein de PKI

Au sein d'une infrastructure à clé publique (PKI), la signature intervient à plusieurs niveaux distincts. Cette section se concentre sur ces différents rôles liés à la signature plutôt que sur les principes fondamentaux de l'PKI . Si vous souhaitez approfondir vos connaissances sur l'PKI, consultez notre .

Les clés de signature de l'autorité de certification (CA) constituent le point d'ancrage. La paire de clés de signature de la CA signe chaque certificat qu'elle émet à l'aide de son algorithme de signature, quel que soit le type de clé du souscripteur. Une CA EdDSA, par exemple, appose des signatures EdDSA sur les certificats qu'elle émet, même lorsque la clé du client est de type RSA ou ECDSA.

La signature des réponses OCSP (Online Certificate Status Protocol) est une fonction connexe. Des paires de clés et des certificats dédiés à la signature OCSP signent les réponses relatives au statut de révocation, afin qu’un client vérifiant la validité d’un certificat puisse se fier à la réponse qu’il reçoit. Cette technique est utilisée dans de nombreux déploiements d’ PKI , notamment dans certaines parties de l’ PKI Web. La signature des CRL (listes de révocation de certificats) remplit le même objectif de manière batch : les listes de révocation de certificats sont elles-mêmes signées. Les CRL volumineuses peuvent poser des défis pratiques en matière de signature avec certains algorithmes, un point qui revêt une importance particulière avec les schémas post-quantiques. Pour en savoir plus, consultez nos guides dédiés auxCRLet àl’OCSP.

Enfin, la délivrance d’un certificat n’associe généralement une clé publique à une identité qu’après que le demandeur a démontré la possession de la clé privée correspondante, le terme « possession » désignant ici la capacité à l’utiliser, et non un contrôle exclusif. Pour les clés de signature, cela ne présente pratiquement aucun coût : la norme PKCS#10 exige que la demande soit auto-signée, et l’autorité de certification vérifie cette signature. Mais cela n’a jamais été la norme universelle. Les clés d’accord de clé et de transport de clé ont nécessité d’autres mécanismes depuis la RFC 4210, et RSA s’est contenté de masquer le problème en permettant à une clé exclusivement destinée au chiffrement de produire malgré tout une autosignature valide. Le modèle ML-KEM supprime cette facilité. La RFC 9810 définit les alternatives pour les clés KEM : l’archivage de la clé privée, une preuve indirecte dans laquelle l’autorité de certification renvoie le certificat chiffré au sujet, ou une procédure directe de type « défi-réponse », où EnvelopedData remplace l’ancienne valeur EncryptedValue partout. Infrastructure de signature : sécurisation des clés et évolutivité de la signature

Des algorithmes et des protocoles robustes ne constituent que la moitié de l'histoire. L'infrastructure qui héberge les clés et gère les opérations de signature revêt une importance tout aussi grande.

• Moteurs de signature centralisés.
  Une seule plateforme peut prendre en charge simultanément de nombreux cas d'utilisation, signataires, organisations et utilisateurs. Le regroupement d'outils de signature dispersés au sein d'un seul moteur simplifie l'administration, renforce la sécurité et réduit les coûts, tout en permettant aux développeurs et aux processus automatisés de signer rapidement.
• Protection des clés via un HSM.
  Les clés de signature doivent être générées et utilisées au sein d’un module de sécurité HSM ( hardware ) certifié FIPS, afin qu’elles ne soient jamais exposées sur des postes de travail ou des serveurs de compilation. Différents membres d’un projet ou différents systèmes peuvent s’authentifier et partager la même clé protégée, mais en conservant toujours une trace indiquant qui a signé quoi.
• Signature de code en tant que service.
  Des agents légers s'intègrent directement aux outils natifs de la plateforme, tels que SignTool, Jarsigner, Cosign et OpenSSL, de sorte que la signature s'effectue localement sur le poste de travail du développeur ou sur le serveur de compilation. Les fichiers binaires volumineux n'ont ainsi jamais besoin d'être transférés via le réseau vers un service central.
• Politiques, contrôle d'accès et authentification.
  Des politiques granulaires déterminent qui peut signer quoi, quand et avec quels outils. L'authentification via SAML, OAuth ou des méthodes similaires permet de vérifier l'identité des utilisateurs et des machines avant toute signature, tandis que des contrôles basés sur les rôles garantissent la conformité de l'utilisation.
• Traçabilité et évolutivité.
  Des journaux d'événements détaillés et signables constituent des traces irréfutables des accès et utilisations clés. Les fonctionnalités intégrées de basculement, d'équilibrage de charge et d'évolutivité à la demande garantissent la disponibilité de la signature même en cas de volumes de transactions élevés.

Signatures numériques post-quantiques

La cryptographie post-quantique (PQC) est une cryptographie capable de résister à la menace que représenterait un ordinateur quantique suffisamment puissant sur le plan cryptographique. Il n'existe pas encore d'ordinateur quantique suffisamment puissant pour déchiffrer les systèmes cryptographiques, mais les gouvernements et les organismes de normalisation encouragent déjà l'abandon de la cryptographie asymétrique classique, et le principal acteur de cette initiative est le National Institute of Standards and Technology (NIST). La raison est simple : dès qu'un ordinateur quantique suffisamment puissant sera disponible, des algorithmes tels que le RSA et la cryptographie à courbe elliptique pourront être piratés.

Le NIST a normalisé les algorithmes de base. En matière de signatures, la norme FIPS 204 définit le ML-DSA (dérivé de CRYSTALS-Dilithium) et la norme FIPS 205 définit le SLH-DSA (dérivé de SPHINCS+), une autre norme de signature, le FN-DSA (dérivé de FALCON), devant suivre. Un processus de normalisation supplémentaire est actuellement en cours, visant à ajouter des constructions de signature afin de diversifier les fondements mathématiques et de couvrir différents cas d’utilisation. Il existe également deux algorithmes de signature à état basés sur un hachage, LMS et XMSS, normalisés dans la spécification NIST SP 800-208. Ils sont cryptographiquement solides, mais lourds à mettre en œuvre, car la clé privée comporte un état qui doit être géré avec précaution. La spécification n'autorise pas l'exportation du matériel de la clé privée, ce qui rend véritablement difficiles une exploitation sécurisée à long terme et la reprise après sinistre.

Pour faciliter la transition, les clés et signatures hybrides associent une clé classique (RSA, ECDSA ou EdDSA) à une clé post-quantique telle que ML-DSA. Un certificat protégé de cette manière reste fiable tant que l’un ou l’autre de ses composants est valide. Il s’agit d’une mesure de précaution judicieuse pendant la migration vers la cryptographie post-quantique (PQC), car tout le monde n’a pas encore pleinement confiance dans la sécurité des nouveaux algorithmes PQC. Tous les modules HSM ne prenant pas en charge toutes les combinaisons hybrides, il convient de vérifier à la fois le modèle et la version de son micrologiciel.

Une difficulté technique mérite d’être soulignée. De nombreux algorithmes post-quantiques ne fonctionnent pas selon le principe « hachage-signature », contrairement aux algorithmes classiques RSA et EC, qui acceptent des résumés de hachage dépendant uniquement du message, ce qui les rend plus portables. Cela signifie que, dans le cas de nombreuses constructions post-quantiques, la charge utile complète doit être transmise à la fonction de signature, plutôt qu’un hachage compact. Cela peut mettre à rude épreuve un HSM lors de la signature d’objets volumineux tels que de grandes listes de révocation de certificats (CRL), car la quantité de données pouvant être transmise à un HSM est généralement limitée. La RFC 9881 résout ce problème en introduisant Externalμ-ML-DSA comme méthode privilégiée pour gérer la signature de charges utiles volumineuses ; toutefois, la prise en charge varie selon les HSM et les micrologiciels, il est donc judicieux de procéder à des tests à l’échelle de production dès les premières phases.

Pour en savoir plus sur l'écosystème global de la résistance quantique, consultez notreguide complet sur la cryptographie post-quantique.

Comment Keyfactor vous aider

KeyfactorSon portefeuille de solutions de signature répond directement aux défis présentés dans ce guide. SignServer est un moteur de signature côté serveur polyvalent qui signe en toute sécurité les applications « software », les micrologiciels, les conteneurs, les documents et bien plus encore, tandis que Signum propose la signature de code en tant que service grâce à un HSM intégré et à un modèle SaaS rapide à déployer.

Les deux établissent un lien entre les problèmes des lecteurs et des solutions concrètes. Ils

• protéger les clés de signature dans des modules HSM certifiés FIPS afin que les informations confidentielles ne soient jamais exposées,
• appliquer la politique de signature de manière centralisée,
• s'intégrer aux processus DevOps et de documentation existants grâce à des outils natifs et des interfaces standard, et
• conserver des pistes d'audit complètes et signables pour chaque action de signature.
• Cette combinaison permet de lutter directement contre les principaux risques liés au vol et à la chaîne d'approvisionnement, qui sapent la confiance.

Elles sont également conçues pour offrir une agilité cryptographique et une compatibilité avec les technologies post-quantiques. La prise en charge couvre les algorithmes RSA, ECDSA et EdDSA, ainsi que les algorithmes de signature post-quantiques ML-DSA et SLH-DSA, sans oublier le hachage côté client pour optimiser les performances et la scalabilité à la demande pour les volumes élevés. Cela permet aux équipes de continuer à signer dès aujourd’hui et de passer à la signature post-quantique lorsqu’elles seront prêtes.

Keyfactor’s Bouncy Castle est une bibliothèque de cryptographie open-source établie de longue date, qui constitue le choix par défaut pour tout ce qui concerne les certificats et les signatures. Elle prend en charge pratiquement tous les algorithmes de signature utilisés, y compris les nouveaux schémas post-quantiques tels que ML-DSA et SLH-DSA.