Code Signing (Signature de Code)

Définition

Le code signing (signature de code) est un mécanisme cryptographique qui permet de garantir deux propriétés fondamentales d'un logiciel distribué : son authenticité (il provient bien de l'éditeur revendiqué) et son intégrité (il n'a pas été altéré depuis sa publication). Concrètement, l'éditeur appose une signature numérique sur son binaire, son package ou son image conteneur à l'aide d'une clé privée ; le système d'exploitation, le gestionnaire de paquets ou le magasin d'applications vérifie cette signature avec la clé publique associée, généralement portée par un certificat X.509 émis par une autorité de certification reconnue.

La signature de code n'est pas une garantie de qualité ni d'innocuité : un malware signé reste un malware. Elle établit uniquement une chaîne de responsabilité vérifiable entre un artefact et une identité.

Fonctionnement technique

Le processus repose sur la cryptographie asymétrique et suit toujours le même schéma :

• Condensat : une empreinte du binaire est calculée avec une fonction de hachage (SHA-256 aujourd'hui, SHA-1 étant proscrit).
• Chiffrement du condensat : cette empreinte est signée avec la clé privée de l'éditeur (RSA-3072/4096 ou ECDSA P-256).
• Encapsulation : la signature et le certificat sont intégrés au fichier (structure PKCS#7 dans la table de certificats du format PE pour Windows) ou stockés dans un fichier détaché (.sig, .asc).
• Horodatage (timestamping) : un serveur RFC 3161 atteste la date de signature. Sans lui, la signature devient invalide dès l'expiration du certificat ; avec lui, elle reste vérifiable au-delà.
• Vérification : le vérifieur recalcule l'empreinte, valide la signature, remonte la chaîne de certification jusqu'à une racine de confiance, puis contrôle la révocation via CRL ou OCSP.

Écosystèmes et implémentations

Chaque plateforme impose son propre dispositif :

• Windows : Authenticode, signé avec signtool.exe. Les pilotes noyau exigent depuis Windows 10 une signature via le portail Microsoft Hardware Dev Center (attestation ou WHQL) — une contrainte qui a donné naissance aux attaques BYOVD (Bring Your Own Vulnerable Driver), où un attaquant charge un pilote légitimement signé mais vulnérable.
• macOS / iOS : codesign puis notarisation auprès d'Apple, contrôlée à l'exécution par Gatekeeper. Sans cela, l'application est bloquée.
• Android : APK Signature Scheme v2/v3/v4, avec rotation de clé possible depuis la v3 et gestion déléguée via Play App Signing.
• Paquets Linux : signatures GPG des dépôts apt/yum, vérifiées par le gestionnaire de paquets.
• Conteneurs et artefacts cloud-native : Notary v2 / Notation (projet CNCF) et surtout Sigstore, qui a bouleversé les usages avec cosign. Sigstore repose sur des certificats éphémères délivrés par Fulcio après authentification OIDC, et sur un journal de transparence public en append-only, Rekor. Ce modèle de keyless signing supprime le problème du stockage de clés longue durée : la clé vit quelques minutes, la preuve reste publiquement auditable.

Cas concrets et enjeux de sécurité

L'histoire des compromissions montre la valeur d'un certificat de signature aux yeux d'un attaquant. Stuxnet utilisait des pilotes signés avec des certificats volés à Realtek et JMicron. L'attaque ShadowHammer a distribué une porte dérobée via l'outil de mise à jour ASUS, dûment signé. SolarWinds a vu un implant injecté dans la chaîne de build avant l'étape de signature — la signature était donc parfaitement valide. Les fuites de certificats de Nvidia (2022) ont immédiatement été réutilisées pour signer des charges malveillantes.

La leçon est constante : signer un artefact déjà compromis ne fait que légitimer la compromission. Le code signing doit donc être pensé comme le maillon final d'une chaîne de confiance couvrant l'intégralité du pipeline, aux côtés du SBOM, des frameworks SLSA et in-toto, et de la sécurisation des runners CI/CD.

Bonnes pratiques

• Protection matérielle obligatoire : depuis juin 2023, le CA/Browser Forum impose que les clés de signature de code soient générées et stockées dans un module conforme FIPS 140-2 niveau 2 ou Common Criteria EAL4+ — HSM, token USB ou service cloud type Azure Key Vault, AWS KMS, GCP KMS.
• Ne jamais signer depuis un poste de développement : centraliser la signature dans un service dédié, isolé, appelé par le pipeline, avec journalisation exhaustive de chaque opération.
• Horodater systématiquement toutes les signatures de production.
• Séparer les environnements : certificats distincts pour les builds internes, les préproductions et les releases publiques.
• Reproductibilité : viser des reproducible builds pour qu'un tiers puisse recompiler et comparer l'empreinte signée.
• Préparer la révocation : disposer d'une procédure documentée et testée de révocation et de rotation, activable en quelques heures.
• Surveiller les journaux de transparence (Rekor) pour détecter une signature émise sous votre identité sans votre accord.
• Anticiper la cryptographie post-quantique : les algorithmes à base de réseaux (ML-DSA) commencent à être intégrés aux formats de signature.