Dans le monde numérique d’aujourd’hui, assurer l’authenticité des logiciels est plus crucial que jamais. Avec les cybermenaces qui évoluent rapidement, comment pouvons-nous savoir que les applications que nous téléchargeons n’ont pas été altérées ? C’est là qu’entre en jeu la signature de code—un mécanisme de sécurité qui aide à vérifier qu’un logiciel est authentique et n’a pas été modifié depuis qu’il a été signé par le développeur.

Mais le simple fait de posséder des certificats de signature de code ne suffit pas. S’ils ne sont pas gérés adéquatement, ces certificats peuvent tomber entre de mauvaises mains et être utilisés par des attaquants pour signer des logiciels malveillants, menant à des attaques de chaîne d’approvisionnement et à d’importantes violations de sécurité. Pour éviter cela, le CA/Browser Forum (Forum CA/B) est intervenu avec des normes industrielles strictes pour l’émission et la gestion des certificats de signature de code.

Qu’est-ce que la signature de code et pourquoi est-ce important ?

La signature de code est comme un « sceau d’approbation » numérique pour les logiciels. Elle utilise des techniques cryptographiques pour prouver qu’une application ou un exécutable provient d’une source fiable et n’a pas été modifié après signature. Lorsque vous installez un logiciel sous Windows ou macOS et voyez une fenêtre indiquant « Cette application provient d’un développeur vérifié », c’est la signature de code en action. Sans elle, il n’y a aucun moyen de confirmer si une mise à jour logicielle est légitime ou si un pirate y a injecté un logiciel malveillant. Les attaquants volent ou utilisent souvent à mauvais escient des certificats de signature de code faiblement protégés pour faire passer leur logiciel malveillant pour un logiciel fiable, c’est pourquoi il est tout aussi important de sécuriser ces certificats que de les utiliser.

Qui est le Forum CA/B et pourquoi s’en soucier ?

Le Forum CA/B est un regroupement d’autorités de certification (CA), de fournisseurs de navigateurs (comme Microsoft, Google et Mozilla) et d’autres intervenants en cybersécurité qui définissent les pratiques exemplaires pour l’émission et la gestion des certificats numériques.

Ils établissent les règles que les CA doivent respecter afin de s’assurer que les certificats SSL/TLS, S/MIME et de signature de code sont émis de façon sécuritaire et ne peuvent être facilement utilisés à mauvais escient. Leurs exigences de base pour la signature de code décrivent des politiques strictes pour prévenir l’abus de certificats et améliorer la sécurité logicielle. À une époque où les logiciels malveillants et les attaques par chaîne d’approvisionnement sont en augmentation, les certificats de signature de code sont essentiels pour sécuriser la distribution logicielle. Le Forum CA/B a établi des exigences de base rigoureuses pour garantir l’intégrité des certificats de signature de code et prévenir les abus.

Le besoin de pratiques de signature de code plus solides

La signature de code est un contrôle de sécurité essentiel permettant aux utilisateurs de vérifier l’authenticité des logiciels. Cependant, les cybercriminels abusent souvent de certificats volés ou faiblement protégés pour signer des logiciels malveillants. Les exigences de base v3.9 du Forum CA/B visent à atténuer ces risques grâce à des politiques plus strictes en matière d’émission, d’entreposage et de révocation.

1. Fini les vérifications d'identité faibles; une vérification renforcée est essentielle

   Avant de délivrer un certificat de signature de code, les AC doivent vérifier strictement l'identité du demandeur. Cela inclut :

   1. La confirmation de l'existence légale d'une entreprise ou d'un individu.
   2. La validation de la propriété du domaine pour le certificat.
   3. La vérification des pièces d'identité émises par le gouvernement.

   Cela aide à empêcher les fraudeurs d'obtenir des certificats valides qu’ils pourraient utiliser pour signer des logiciels malveillants.

2. Dites adieu aux clés facilement volées; le stockage sécurisé est obligatoire

   Le vol de clé privée est l’un des risques de sécurité les plus importants en signature de code. Si une clé privée tombe entre de mauvaises mains, un attaquant peut l’utiliser pour signer des logiciels malveillants comme s’ils provenaient d’un développeur de confiance. Pour éviter cela, le CA/B Forum exige maintenant que les clés privées soient générées, stockées et utilisées dans un module matériel cryptographique certifié répondant aux directives de la norme FIPS 140-2 Niveau 2 ou Common Criteria EAL 4+ pour -

   1. Les modules matériels de sécurité (HSM) pour la sécurité sur site.
   2. Les modules de plateforme de confiance (TPM) pour la sécurité des points de terminaison.
   3. Les systèmes de gestion de clés dans le nuage (KMS) pour la signature infonuagique.

   Suivre ces normes signifie que les développeurs ne peuvent plus stocker les clés privées dans des formats logiciels non sécurisés comme les fichiers PFX, qui sont des cibles faciles pour les pirates.

3. Durée de vie des certificats plus courte et politiques de révocation

   Aucun certificat de signature de code ne pouvait auparavant durer jusqu’à cinq ans. Bien que ce fût pratique, cela signifiait également que si un certificat était volé ou mal utilisé, les attaquants pouvaient continuer à l’utiliser pendant des années avant son expiration.

   Pour limiter ce risque, le CA/B Forum a réduit la validité maximale à 39 mois. Cela assure que les entreprises subissent des revalidations d’identité fréquentes, rendant plus difficile l'utilisation prolongée de certificats volés.

   Révocation plus rapide : Si un certificat est compromis ou utilisé pour des logiciels malveillants, l’AC doit le révoquer immédiatement, parfois dans les 24 heures pour les cas à haut risque. Cela garantit que les certificats compromis ne continuent pas à être utilisés pour des attaques.

   De plus, les AC doivent maintenant :

   1. Utiliser les journaux Certificate Transparency (CT) pour suivre les certificats émis.
   2. Analyser les logiciels à la recherche de maliciels avant de délivrer un certificat.

   Cela aide à détecter une activité suspecte tôt et empêche les acteurs malveillants d’abuser des certificats de signature de code.

4. Horodatage : Prolonger la confiance au-delà de l’expiration

   Un logiciel signé avec un certificat de signature de code peut devenir invalide une fois le certificat expiré. Pour remédier à cela, le CA/B Forum exige l’utilisation d’horodatages conformes à la RFC 3161, assurant que le logiciel signé demeure digne de confiance même après l’expiration du certificat.

5. Analyse de maliciels avant la délivrance

   Un ajout révolutionnaire est l’analyse de maliciels avant la délivrance du certificat. Cela empêche les développeurs malveillants d’obtenir des certificats de signature de code valides pour distribuer des logiciels malveillants, ce qui réduit considérablement les risques dans la chaîne d’approvisionnement.

Réflexions finales : Un pas vers un écosystème logiciel plus sûr

Les exigences de base mises à jour du CA/B Forum représentent un progrès considérable vers un écosystème logiciel plus sécuritaire et digne de confiance. En imposant une vérification rigoureuse de l'identité, un entreposage sécuritaire des clés, des politiques strictes de révocation et l'obligation d'horodatage, les nouvelles lignes directrices rendent beaucoup plus difficile l'utilisation abusive des certificats de signature de code par les attaquants. Pour les développeurs et les entreprises, cela signifie :

• Confiance accrue dans les logiciels signés.
• Risque réduit de vol et de mauvaise utilisation de certificats.
• Une défense plus solide contre les logiciels malveillants et les attaques de la chaîne d’approvisionnement.

Dans un monde où les menaces numériques ne cessent de croître, ces mesures contribuent à assurer que les logiciels demeurent sécurisés, vérifiés et à l'épreuve de toute falsification.