La signature de code et l'utilisation de certificats numériques sont fondamentales pour le concept de confiance dans le monde technologique moderne.
Plus précisément la signature de code, qui est utilisée pour vérifier l'identité du développeur d'un programme et son origine. Comme de nombreux certificats X.509, les certificats de signature de code se présentent sous des formes de validation standard et étendue (EV).
En signant un programme par code, les développeurs joignent simplement leur certificat numérique. Les certificats de signature de code utilisent la cryptographie à clé publique, la même technologie utilisée par d'autres types de certificats numériques. Cette approche peut être utilisée dans les systèmes d'exploitation de nombreux types de plates-formes, du mobile au bureau. Vous pouvez les trouver pour Windows de Microsoft, Mac OS X d'Apple, Linux et même iOS et Android. Ils peuvent même être trouvés dans les appareils IoT. L'intégration de ces certificats dans le code source d'un programme est un aspect important de la sécurité et de la confiance dans tout développement logiciel.
Comment implémenter la signature de code
Pour y parvenir, il faut une clé privée unique - une clé correctement hachée afin que la poignée de main de cryptage/décryptage ne puisse pas être facilement vaincue. Dans la cryptographie à clé publique, la combinaison des clés publiques et privées est au cœur du processus, permettant une communication sans accès.
Une fois qu'une nouvelle paire de clés est générée à l'aide d'une infrastructure à clé publique (PKI), la clé publique est envoyée à une autorité de certification (CA), qui vérifie l'identité du développeur et appose sa propre clé publique au certificat de signature de code. Le certificat et le code sont renvoyés au développeur d'origine qui a demandé le certificat.
Maintenant que les développeurs disposent d'un certificat de signature de code et d'une paire de clés de chiffrement, ils doivent hacher le code du logiciel avant de le chiffrer et de le signer. Le hachage est un programme dans lequel une fonction de hachage est utilisée pour convertir le code en une valeur fixe arbitraire. La sortie du hachage, appelée condensé, est ensuite chiffrée avec la clé privée. Ensuite, les développeurs combinent ce résumé avec un certificat de signature de code et une fonction de hachage pour créer quelque chose appelé un bloc de signature, qui combine essentiellement tous les éléments ci-dessus dans un morceau de code qui peut être facilement inséré dans le logiciel.
L'importance de se protéger
Le plus gros problème avec la signature de code est la protection de la clé de signature de code privée associée au certificat. Si une clé est compromise, le certificat perd sa confiance et sa valeur, compromettant le logiciel que vous signez.
De nombreuses organisations se protègent avec des coffres-forts de sécurité et des modules matériels de sécurité (HSM) pour accroître la sécurité de leurs clés privées. D'autres organisations utilisent Certificate Manager pour automatiser et sécuriser la gestion du cycle de vie de tous les certificats de signature de code. Un exemple de ceci est le gestionnaire de certificats Sectigo. L'utilisation d'un gestionnaire de certificats peut grandement contribuer à promouvoir l'intégrité des clés privées et d'autres actifs cryptographiques.
Qu'est-ce que la signature de code empêche ?
En termes simples, la signature de code empêche l'introduction de logiciels malveillants et d'autres codes malveillants dans le système d'un utilisateur final sous le couvert de fichiers ou d'événements bénins tels que les mises à jour Windows. Pour ce faire, il permet aux utilisateurs de vérifier que le fichier en cours de téléchargement provient bien de l'auteur et non d'un acteur malveillant. Cela renforce le concept de confiance au sein du système, permettant aux développeurs de garantir aux utilisateurs finaux qui téléchargent des logiciels que la source est fiable et sûre.
Les certificats de signature de code EV offrent des garanties de sécurité supplémentaires. Ils nécessitent que les clés soient stockées dans du matériel à haute assurance conforme à FIPS140-2 ou supérieur. Il existe des jetons USB qui répondent à cette exigence et ajoutent une autre couche de protection via un code PIN. Vous pouvez également stocker les clés dans le module de sécurité matériel (HSM) de votre organisation.
Les recherches du Cyber Forensics Innovation Lab de Georgia Tech montrent que l'émission et l'utilisation de certificats TLS/SSL à validation étendue (EV) offrent une probabilité de protection de 99,99 % contre les attaques de phishing et les abus.
Un moyen simple de protéger vos clés
Il existe de nombreuses façons de protéger les clés de signature de code, notamment :
Séparez vos clés de signature de test et de version
Les environnements de test sont désordonnés et occupés, mais, comme ils sont internes, les clés de signature de test n'ont généralement pas besoin d'être aussi profondément protégées que vos clés de signature de version. En fait, de nombreuses organisations utilisent des certificats auto-signés ou des autorités de certification non approuvées dans les environnements de test pour cette raison. Séparer les clés de test et de signature de version empêche les développeurs d'utiliser une clé de signature de code pendant la phase de développement, puis de publier le logiciel avec. Cependant, l'utilisation de clés de test et de version distinctes nécessite que tout programme d'installation de test soit clairement identifié pour éviter qu'il ne soit transmis aux clients.
Prenez la révocation au sérieux
Les certificats de révocation sont l'un des éléments les plus importants du suivi de vos clés de signature de code. Si des vulnérabilités sont découvertes au cours du processus de signature de code ou si des clés privées sont exposées, les clés et les certificats qui leur sont associés doivent être révoqués et réémis pour garantir correctement la confiance dans le système.
le temps est ton ami
Les certificats de signature de code expirent comme les autres certificats numériques. Cela ne signifie pas que les informations signées avec ce certificat ne sont pas valides, mais cela signifie que lorsque le système vérifie la signature de code à des fins de comparaison, il reconnaît qu'elle a expiré et envoie un message d'erreur à l'utilisateur final. Ces alertes, qui se produisent chaque fois que l'horodatage a expiré, peuvent être contournées, mais elles nuisent à la réputation du client et à la confiance dans la marque. Ces dates d'expiration imposent la discipline de continuer à renouveler les certificats, garantissant que les certificats dans le code publié sont hachés à l'aide des dernières méthodes cryptographiques et n'ont pas été compromis par des vulnérabilités cryptographiques.
Meilleures pratiques pour la signature de code
La signature de code ne rend pas le logiciel complètement à l'abri d'une utilisation abusive, d'une falsification ou d'une intention malveillante. Il y a un grand élément humain dans le processus de gestion des clés privées. La signature de code doit être une responsabilité collaborative entre les équipes de sécurité et de développement pour atteindre un objectif commun et protéger les clés sans interruption.
Le respect de certaines pratiques exemplaires standard de l'industrie peut rendre cette approche aussi efficace que possible. Voici les 10 meilleures pratiques de signature de code recommandées par Sectigo.
1. Sécurisez votre code avec un certificat de signature de code
La recommandation la plus importante est d'utiliser des certificats de signature de code dans la mesure du possible. Ces certificats vérifient l'origine et l'authenticité du code auprès de l'utilisateur final et renforcent la confiance des clients dans leur sécurité personnelle. En signant correctement votre code, vous pouvez insuffler à votre application ou programme une confiance gérée par une autorité de certification publique de confiance. Pour plus de sécurité, vous pouvez utiliser des certificats de signature de code EV.
2. Évitez de développer de mauvaises habitudes
L'utilisation correcte des certificats au sein de votre système est essentielle, mais sans appliquer les comportements pour les maintenir et les utiliser correctement, tout ce que vous ferez d'autre sera futile. Construire une culture qui comprend l'utilisation et l'importance des certificats numériques ne peut qu'améliorer votre organisation dans son ensemble.
3. Minimiser l'accès aux clés privées
Tout bon professionnel de l'informatique mettra en place autant de contrôle d'accès que possible ; cela inclut la restriction de l'accès aux clés privées et aux certificats racine sous-jacents. Vous devez autoriser très peu de personnes à accéder aux clés privées de votre organisation, et ces personnes doivent avoir une raison claire d'avoir besoin d'un accès. L'établissement d'une politique d'accès basée sur les rôles (rbac) au sein de votre organisation contribuera à limiter l'exposition possible.
4. Protégez les clés privées avec du matériel cryptographique
L'utilisation de matériel de chiffrement vous permet de protéger vos clés privées avec les derniers algorithmes de chiffrement. Ce type de matériel doit être au moins certifié FIPS 140 niveau 2. Des produits tels que les modules de sécurité matériels (HSM) empêcheront vos clés privées de tomber entre de mauvaises mains.
5. Horodater le code
L'horodatage de votre code vous donne une idée du moment où le code a été écrit par rapport au certificat sur lequel il a été écrit. Cela lui permet d'être reconfirmé comme légitime une fois que le certificat expire ou est révoqué. Il s'agit d'une relation importante à comprendre, car à mesure que la technologie et les menaces chiffrées évoluent, les protections actuelles peuvent être affaiblies ou complètement détruites.
6. La différence entre la signature de test et la signature de version
Comme mentionné ci-dessus, il est important de distinguer et de comprendre la différence entre la signature de test et les clés/certificats de signature de version. Moins de sécurité est requise pour les certificats et les clés de signature de test, qui peuvent être auto-signés par une autorité de certification de test interne privée. Ils doivent également être concaténés avec le certificat racine du produit signé par la version, et les meilleures pratiques incluent la configuration d'infrastructures de signature de code entièrement différentes pour la signature de la version et de la pré-version. Cela vous permettra de configurer des contrôles d'accès appropriés pour votre environnement de test et votre code de production.
7. Code de vérification
La signature de code ne garantit pas spécifiquement que le code est sécurisé, il indique simplement qui l'a écrit. Par conséquent, le code doit encore être entièrement certifié avant de pouvoir être diffusé de bonne foi au public. Cela garantit que vous ne propagez pas accidentellement un code incorrect ou malveillant qui pourrait nuire aux clients et nuire à votre réputation. Toutes les activités de signature de code certifiées doivent être enregistrées au cas où un type d'enquête ou de réponse à un incident serait nécessaire ultérieurement.
8. Code de scan antivirus
En plus de vérifier que votre code n'a pas été modifié, il est également important de l'analyser à la recherche de virus ou d'autres codes malveillants. Du code malveillant est souvent inséré par inadvertance par des développeurs qui réutilisent ou importent du code existant à partir de projets externes. Il est beaucoup plus facile d'attraper et de modifier les bogues avant la publication du code.
9. Limitez la réutilisation des clés
Réutiliser plusieurs fois votre clé privée pour la signature de code vous expose à un risque accru. Si une clé est compromise, toutes les signatures de code à cette date estampillées avec cette clé seront invalides et devront être renouvelées avec de nouveaux certificats de signature de code. Le maintien de l'habitude de parcourir différentes clés et certificats vous permettra de répartir les risques et de réduire l'effort et l'impact de la réémission des certificats.
10. Révocation d'un certificat compromis
La révocation est l'une des tâches les plus importantes pour assurer la sécurité de votre code. Les autorités de certification prennent la révocation plus au sérieux que quiconque, c'est pourquoi nous recommandons les meilleures pratiques comme l'horodatage de votre code.
Cependant, il est de la responsabilité de l'organisation de développement de signaler tout code, clé ou certificat compromis à votre autorité de certification afin qu'elle puisse prendre les mesures appropriées. CA demandera de révoquer le certificat de signature de code si un problème éventuel survient. Si vous horodatez votre code, seul le code avec une date de révocation postérieure à l'événement sera affecté.