DEV Community

Cover image for Comment bien signer ses programmes avec OpenSSL ?
Jean-Noël for Younup

Posted on

Comment bien signer ses programmes avec OpenSSL ?

Pourquoi signer ?

En 2025, 72% des entreprises à l'échelle mondiale ont constaté une intensification des risques de cyberattaque et 91% des experts en cybersécurité s'attendent à une augmentation des menaces augmentées à l'IA1 😮. Et cela, notamment à partir de contenu falsifié.

Face à cette menace, comment s'assurer que les données reçues à travers le réseau proviennent du bon expéditeur, et, surtout, contiennent des données authentiques plutôt qu'un programme malveillant ?

Une des solutions à cela, évidemment, c'est la signature des fichiers !

Aujourd'hui nous allons donc voir comment signer et vérifier la signature de ces fichiers avec OpenSSL, un outil en ligne de commande gratuit, universel (Windows, Linux, Mac OS), et largement éprouvé.

Qu'est-ce que la signature, plus précisément ?

On peut hésiter entre 4 techniques : signer, chiffrer, obfusquer ou checksum ? Même si elles sont complémentaires dans le domaine de la sécurité, elles n'ont pas les mêmes fonctions !

  • Chiffrement : protéger des données confidentielles à l'aide d'une clé mathématique. Sans la clé, les données sont incompréhensibles.
  • Obfuscation (néologisme pour "offuscation") : brouiller la lecture humaine des données et les rendre plus difficiles à comprendre. En termes de sécurité, c'est une technique très (trop) minimaliste, mais néanmoins complémentaire. Exemple : "l'uglification"🧌 du code JavaScript pour le frontend.
  • Checksum : vérifier l'intégrité d'un fichier avec un hash calculé à partir de la somme des octets de ce dernier.
  • Signature : authentifier la provenance ET vérifier l'intégrité d'un fichier.

Vous l'aurez remarqué : la signature est un procédé ayant une similarité avec les checksums, mais encore plus sécurisé, bien qu'elle soit à peine plus complexe à utiliser !

Grâce à une paire de clé privée/clé publique (algorithme asymétrique, donc) elle permet de bien séparer les rôles entre le signataire et les vérificateurs de la signature :

  • Clé privée : secret uniquement détenu par le signataire.
  • Clé publique : distribuée à toutes les personnes désirant vérifier la signature.

Le processus de signature se fait donc en deux temps :

  1. La signature d'un fichier :

    Procédure de signature

  2. La vérification de la signature par les personnes ayant reçu le fichier signé :

    Procédure de vérification de signature

Ici le RSA est choisi comme algorithme de chiffrement avec un hash SHA-256. Bien entendu, il en existe d'autres dont certains seront mentionnés ci-après.

Signer avec OpenSSL

Voyons ensemble comment signer un fichier avec OpenSSL dans un invité de commande Windows (outil que presque tout le monde doit avoir quelque part, donc 😛).

Habituellement, une version d'OpenSSL est déjà présente dans l'emplacement de votre gestionnaire de version git.

Mais si la commande where openssl ne vous renvoie rien, vous devrez l'installer manuellement : soit en installant git (solution la plus simple finalement !), soit avec MSYS2 et pacman, soit avec winget.

Une fois OpenSSL installé, commencez par créer une clé privée sécurisée par mot de passe :

openssl genrsa -aes256 -out private.pem 4096
Enter fullscreen mode Exit fullscreen mode

Notez le -aes256 qui indique qu'il faut utiliser l'algorithme AES-256 pour chiffrer la clé privée avec le mot de passe qui vous sera demandé lors de l'exécution. Cet algorithme de chiffrement est encore considéré comme très sécurisé, et le restera pendant encore un bon moment.
Ainsi, même si la clé fuite par mégarde, elle restera "inutilisable".

Votre fichier private.pem généré doit globalement ressembler à ça :

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIJtTBfBgkqhkiG9w0BBQ0wUjAxBgkqhkiG9w0BBQwwJAQQNNxqBgwqaJT4CYKe
[...]
TEJyVwOU/1g7ffTreVWOUx0nd4udoOoXaaT/YmSujBqQ2vpx1XzS+XpeowtwOAX+
jhnmeck3yxSGfSKhfKfGKkw00Y7ZHejOgmcgLkk/V2pISSqTywk20Bs=
-----END ENCRYPTED PRIVATE KEY-----
Enter fullscreen mode Exit fullscreen mode

Ensuite, créez la clé publique associée, avec par exemple l'algorithme de chiffrement RSA (pour plus de compatibilité) :

openssl rsa -in private.pem -pubout -out public.pem
Enter fullscreen mode Exit fullscreen mode

Ce qui donne un fichier public.pem de cette forme-là :

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAr4rP0humPcjod7dqwyMs
[...]
19auPMRnuCBF+dFw11PR6khBDQusw2sFYXgARgoX8nc1QECvI+hZlpm1ma+K7SjC
gco+E9Iy80pNZ5JhpAWrFNkCAwEAAQ==
-----END PUBLIC KEY-----
Enter fullscreen mode Exit fullscreen mode

Enfin, signez le fichier de votre choix avec la clé privée grâce aux mots clés dgst (pour digérer le fichier, miam 😋) et -sign :

openssl dgst -sha256 -sign private.pem -out sign.sha256 <file-to-sign>
Enter fullscreen mode Exit fullscreen mode

Il est possible de convertir la signature binaire en base64, parfois plus simple à échanger sur le réseau :

openssl base64 -in sign.sha256 -out base64-sign.txt

Vérifier une signature

Maintenant, plaçons-nous du côté d'une personne souhaitant cette fois-ci vérifier la signature d'un fichier program-signed.cpp fraîchement reçu.

À ce stade, notez qu'il est possible de re-convertir la signature reçue en base64 vers du binaire :

openssl base64 -d -in base64-sign.txt -out sign.sha256

Tout d'abord cette personne doit se procurer la signature sign.sha256, ainsi que la clé publique public.pem, bien entendu.

Elle peut alors vérifier la signature du fichier avec les mots clés dgst et -verify :

openssl dgst -sha256 -verify public.pem -signature sign.sha256 program-signed.cpp
Enter fullscreen mode Exit fullscreen mode
Verified OK
Enter fullscreen mode Exit fullscreen mode

Vous pouvez toujours vous amuser à changer juste un caractère à l'intérieur de ce fichier afin de volontairement le falsifier :

openssl dgst -sha256 -verify public.pem -signature sign.sha256 FALSE-program-signed.cpp
Enter fullscreen mode Exit fullscreen mode
Verification failure
Enter fullscreen mode Exit fullscreen mode

La vérification d'authenticité échoue bien. Ouf, on a évité un logiciel potentiellement malveillant ! 😅

Recommandations en termes de sécurité

En ce début d'année 2026, voici quelques recommandations importantes de sécurité vis-à-vis du processus de signature et de ses paramètres :

  • Bien utiliser l'algorithme de hachage SHA-256 ou SHA-512 (famille des SHA-2) plutôt que les 'SHA-1' et 'MD5' qui sont maintenant considérés comme compromis.
  • Pour le format de la clé, choisir une longueur minimum de 4096 bits pour l'algorithme de chiffrement RSA, afin d'anticiper la prochaine obsolescence du 2048 bits.
  • Créer une API de signature sur un serveur avec un accès restreint à une faible quantité de personnes et avec des accès temporaires (token et multifacteurs).
  • La clé privée doit être chiffrée avec mot de passe, placée dans un coffre-fort numérique, et n'être accessible que par le script de signature le temps de l'opération. Jamais par l'API (voire placer le script en question directement à l'intérieur du coffre-fort !). Exemple d'implémentation de l'API de signature :

Exemple d'implémentation d'API de signature

Conclusion

Voilà, maintenant vous savez tout ce qu'il faut savoir pour sécuriser vos programmes ou packages, et protéger les utilisateurs qui recevront vos fichiers 👍.

Sachez que le système de signature est très utilisé aujourd'hui dès qu'il y a un déploiement de programme inter-plateformes.
Les gestionnaires de packages du monde UNIX (apt-get ou dnf) utilisent même une vérification d'identité en complément de la signature brute que nous venons de voir.

Par ailleurs, nous avons ici utilisé l'algorithme de chiffrement RSA largement répandu, mais il faut savoir qu'il en existe d'autres comme le EdDSA ou les ECDSA qui ont la particularité de présenter un niveau de sécurité similaire pour des clés beaucoup plus petites. Cela réduit la complexité algorithmique à l'exécution. Idéal donc pour des environnements limités comme l'embarqué !

Un système de chiffrage post-quantique est même en préparation à l'heure où nous parlons : le Post-quantum Cryptography (PQC) pour prévenir les attaques des ordinateurs quantiques.
Très avant-gardiste, mais on n'est jamais trop prudents !



1 (sources : World Economic Forum 2025)

Top comments (0)