La signature de code est le procédé cryptographique par lequel un éditeur de logiciels appose une signature numérique sur un artefact logiciel au moyen d’une clé privée dont la clé publique correspondante est certifiée par une autorité de certification. La signature permet au consommateur du logiciel de vérifier que l’artefact a été signé par le détenteur de la clé privée et qu’il n’a pas été modifié depuis sa signature. La signature de code est un contrôle précieux de l’intégrité de la chaîne d’approvisionnement : elle empêche l’altération des logiciels en transit, permet d’attribuer les artefacts au détenteur de la clé et fournit un mécanisme de détection des corruptions survenues pendant la distribution. Elle ne protège pas contre un scénario où la clé privée de signature est compromise.
Le modèle de menace de la compromission de clé est la limite déterminante. La signature de code empêche toute altération par des parties qui n’ont pas accès à la clé de signature. Elle n’offre aucune protection si l’attaquant a obtenu la clé privée, car une signature produite avec une clé compromise est cryptographiquement impossible à distinguer d’une signature légitime. Un attaquant qui vole la clé privée de signature de code d’un fournisseur peut signer n’importe quel logiciel avec cette clé, et tout consommateur qui fait confiance au certificat acceptera cette signature comme authentique. Une signature valide signifie que la clé privée a signé l’artefact ; elle ne signifie pas que le processus de compilation du fournisseur l’a produit.
Le problème de la révocation des certificats constitue la lacune opérationnelle. Lorsqu’une clé de signature de code est compromise, la réponse appropriée consiste à révoquer le certificat, pour informer l’écosystème que les signatures produites avec cette clé après la compromission ne doivent plus être considérées comme fiables. En pratique, la révocation des certificats est imparfaite : les listes de révocation (CRL) et les réponses OCSP subissent des délais de mise en cache, les logiciels qui vérifient le statut de révocation peuvent ne pas le faire en temps réel, et de nombreux systèmes acceptent les signatures sans vérifier du tout le statut de révocation. L’intervalle entre la compromission de la clé et sa révocation est une période pendant laquelle des signatures malveillantes paraissent valides.
Pourquoi c’est important
Les limites de la signature de code comptent pour la TPRM, car les entreprises qui exigent la signature de code comme contrôle de sécurité de la chaîne d’approvisionnement peuvent avoir un faux sentiment d’assurance quant à l’authenticité des logiciels signés. L’entreprise qui confirme qu’un fournisseur signe ses versions et qui vérifie les signatures avant le déploiement a mis en place un contrôle précieux, mais pas un contrôle qui protège contre les attaques les plus sophistiquées de la chaîne d’approvisionnement, qui reposent généralement sur la compromission d’une clé plutôt que sur des artefacts malveillants non signés.
- Signature de code acceptée comme contrôle complet de l’authenticité des artefacts
- Modèle de menace de la compromission de clé non pris en compte : artefacts signés présumés authentiques
- Statut de révocation des certificats non vérifié en temps réel
- Sécurité de la gestion des clés du fournisseur non évaluée en plus des pratiques de signature
- Vérification par journal de transparence absente : signatures non confrontées au journal public
À quoi ressemblent les bonnes pratiques
Les programmes de signature de code matures associent la vérification des signatures à la consultation d’un journal de transparence (en particulier le journal de transparence Rekor de Sigstore, qui fournit un registre immuable de tous les événements de signature et permet de détecter les certificats utilisés en dehors de leurs paramètres attendus), et incluent l’évaluation de la sécurité de la gestion des clés en plus de la confirmation des pratiques de signature.
- Vérification des signatures pour tous les artefacts logiciels
- Vérification du journal de transparence : Sigstore Rekor ou équivalent pour l’audit des événements de signature
- Statut de révocation des certificats vérifié au moment du déploiement
- Sécurité de la gestion des clés du fournisseur évaluée : comment les clés privées de signature sont-elles protégées ?
- Politique de rotation des clés de signature : fréquence de rotation des clés et modalités de divulgation d’une compromission
Outils
Transparence : Sigstore Rekor pour la vérification du journal de transparence ; cosign pour la vérification des signatures et des attestations
Le journal de transparence Rekor de Sigstore fournit un registre en ajout seul des événements de signature, qui permet de vérifier qu’une signature a été produite à un moment précis par un certificat valide à ce moment-là. Pour les professionnels TPRM, demander si les versions des fournisseurs sont consignées dans Sigstore Rekor permet de poser une question d’assurance sur la transparence qui va au-delà de la seule vérification des signatures.
Gestion des clés : signature basée sur un HSM, AWS KMS, Azure Key Vault pour la protection des clés de signature
La gestion des clés fondée sur des modules matériels de sécurité garantit que les clés privées de signature ne peuvent pas être exportées, ce qui apporte la protection des clés qui empêche le scénario de compromission décrit en introduction. Pour les professionnels TPRM, demander si les clés de signature de code des fournisseurs sont stockées dans des HSM ou des services dédiés de gestion des clés permet de poser une question sur la protection des clés qui touche à la limite fondamentale de la signature de code.
Enjeux de gouvernance
En matière de signature de code, l’enjeu de gouvernance tient au problème du retard de divulgation. Les fournisseurs qui découvrent que leur clé de signature a été compromise subissent une forte pression pour retarder la divulgation, car celle-ci déclenche des obligations de révocation immédiate, des notifications aux clients et des coûts de correction potentiellement importants. La réponse en matière de gouvernance consiste à exiger des fournisseurs qu’ils s’engagent à divulguer immédiatement toute compromission d’une clé de signature de code et à fournir, en pratique courante, la vérification par journal de transparence.
- Exiger dans les contrats fournisseurs un engagement de divulgation en cas de compromission de clé
- Évaluer la sécurité de la gestion des clés du fournisseur : HSM ou équivalent pour les clés de signature
- Exiger la vérification par journal de transparence pour les versions signées
- Vérifier le statut de révocation des certificats au moment du déploiement
- Inclure la politique de rotation des clés dans l’évaluation de la sécurité des fournisseurs
Si vous êtes une petite équipe
Pour ceux de vos fournisseurs de logiciels qui livrent des versions signées, posez deux questions auxquelles la seule vérification des signatures ne répond pas. Premièrement : vos clés privées de signature de code sont-elles stockées dans des HSM ou des services dédiés de gestion des clés qui empêchent leur exportation ? Deuxièmement : les signatures de vos versions sont-elles consignées dans Sigstore Rekor ou un journal de transparence équivalent ? La première question porte sur la prévention de la compromission des clés. La seconde porte sur la détection de l’utilisation d’une clé compromise, car une clé compromise utilisée pour signer une version malveillante apparaîtra dans le journal de transparence d’une manière qui diffère du schéma de signature habituel du fournisseur.
- Demander si les clés de signature sont protégées par un HSM
- Demander si les versions sont consignées dans Sigstore Rekor
- Vérifier le statut de révocation des certificats au déploiement
- Inclure la sécurité de la gestion des clés dans l’évaluation des fournisseurs
Ce qu’il faut exiger
Demandez directement :
« Vos clés privées de signature de code sont-elles stockées dans des modules matériels de sécurité qui empêchent leur exportation, et les signatures de vos versions sont-elles consignées dans Sigstore Rekor ou un journal de transparence équivalent qui permettrait de détecter une compromission ? »
Preuves attendues
- Confirmation de la protection des clés par HSM ou équivalent
- Confirmation de l’utilisation d’un journal de transparence
- Politique de rotation des clés de signature
- Engagement de divulgation en cas de compromission de clé
Un fournisseur qui confirme signer son code doit être interrogé sur la protection de ses clés et sur la journalisation de transparence. La vérification des signatures confirme que la clé a signé l’artefact. La protection des clés empêche la compromission. La journalisation de transparence détecte la compromission. Les trois sont nécessaires pour une assurance significative en matière de signature de code.
Comment le prouver
- Dossiers d’évaluation de la sécurité de la gestion des clés
- Mise en œuvre de la vérification par journal de transparence
- Mise en œuvre de la vérification de la révocation des certificats
- Obligation de divulgation des compromissions de clé dans les contrats fournisseurs
À retenir
Signature du code : valide. Certificat : émis par une CA reconnue. Clé de signature : compromise 11 mois auparavant. Toutes les versions depuis : signées par la personne qui détenait la clé compromise. Vérification des signatures du début à la fin : correcte. La signature confirmait que la clé privée avait signé l’artefact. Elle ne confirmait rien quant au fait que le processus de compilation du fournisseur avait produit ce que la clé privée avait signé. La signature de code empêche toute altération par des parties qui ne détiennent pas la clé. Elle n’offre aucune protection contre celles qui la détiennent. Les clés protégées par un HSM empêchent l’exportation des clés. Les journaux de transparence détectent les schémas d’utilisation de clés compromises. Les deux sont nécessaires pour que l’assurance apportée par la signature de code s’étende au modèle de menace de la compromission de clé.