Le mois dernier, le Conseil de sécurité des autorités de certification (CASC) annonçait officiellement de nouvelles exigences minimum applicables aux certificats de signature de code de confiance. Le CASC inaugure ainsi une nouvelle ère pour les autorités de certification avec l’harmonisation des règles de gestion et d’émission applicables à la signature de code. Vous retrouverez le détail de ces nouvelles exigences dans le document suivant : Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates.
Ce document présente en détail les règles que les AC doivent appliquer et couvre plusieurs sujets comme le contenu des certificats, les contrôles de révocation et d’état, les pratiques en matière de vérification, etc. En coulisses, les AC n’ont pas chômé pour se mettre en conformité avec l’ensemble de ces obligations. Quel est pour vous l’impact de ces changements ? Voyons ensemble quelles sont les répercussions de quelques-unes de ces nouvelles exigences pour ceux et celles qui signent leur code à l’aide de certificats.
Obligation d’enregistrement des clés privées sur du matériel cryptographique
Selon le CASC, la compromission des clés est l’une des principales causes derrière les attaques de signature de code. Cela se passe de la manière suivante : un tiers malveillant accède à la clé privée d’un éditeur légitime et l’utilise pour signer un fichier malveillant. En lui donnant ainsi une apparence de respectabilité, il augmente les chances pour le fichier d’être téléchargé. Au lieu de stocker les clés en local — comme c’était couramment le cas avant la publication des nouvelles exigences — il faudra donc stocker les clés sur un équipement cryptographique sécurisé (clé USB ou module de sécurité matérielle dit «module HSM») pour réduire le risque de compromission des clés.
Nous prônons depuis un certain temps déjà une protection renforcée des clés privées, ce qui est l’une des exigences de la validation étendue (EV, Extended Validation) des certificats de signature de code depuis leur introduction en 2014. D’ailleurs, en vertu des nouvelles recommandations, le renforcement de la protection des clés est une obligation pour TOUS les certificats de signature de code. Plus précisément, toutes les clés privées devront être stockées soit sur un module HSM FIPS 140-2 de niveau 2, soit sur un équipement physique sur site équivalent, ou via un service de signature basé dans le cloud. Après le 30 janvier 2017, les nouvelles commandes de signature de code GlobalSign seront toutes assorties d’une clé USB pour permettre de stocker le certificat et protéger la clé privée.
Contrôles d’identités stricts et normalisés
D’après le CASC, les attaques contre les signatures de code seraient largement imputables à l’émission de certificats pour des éditeurs malveillants, qui utilisent ensuite les certificats pour signer des virus ou autres malwares. Pour éviter cela, les nouvelles exigences définissent les précautions à prendre pour les autorités de certification avant d’émettre leurs certificats :
- Vérification stricte de l’identité de l’éditeur, y compris son identité juridique, son adresse, les renseignements sur sa constitution, etc.
- Vérification croisée avec les listes d’entités connues ou soupçonnées de publier, produire et distribuer des programmes malveillants
- Maintien d’une liste noire et croisement des données avec cette liste interne de certificats révoqués pour avoir été utilisés afin de signer du code suspect et de certificats précédemment rejetés par l’AC
Si de nombreuses AC respectent déjà une grande partie de ces procédures, la normalisation complique la tâche de certains éditeurs malveillants qui, après avoir été rejetés par d’autres autorités de certification, se mettraient en quête d’une AC moins regardante sur les contrôles.
Obligations de signalement et réaction à tenir face au détournement de certificats ou tout code suspect
En plus d’essayer d’empêcher l’émission de certificats frauduleux, les nouvelles obligations exigent aussi des AC qu’elles mettent en place un système de «signalement des problèmes avec les certificats». Ce système doit permettre à des partenaires tiers (organisations anti-malware, parties utilisatrices, éditeurs de logiciels...) de faire part de leurs «soupçons de compromission des clés privées, de détournement de certificats, d’utilisation de certificats pour signer du code suspect, d’attaques de prise de pouvoir (« takeover attacks ») ou tout autre type de fraudes, violations, usage malhonnête, mauvaise conduite, ou tout autre problème en lien avec les certificats.»
Face aux problèmes qui font l’objet d’un signalement, les autorités de certification sont tenues de réagir selon des règles très strictes. Elles doivent par exemple lancer leurs investigations dans les 24 heures et communiquer sur les incidents 24h/24 et 7j/7. La révocation obéit également à des consignes très strictes et à un calendrier très précis dès le moindre soupçon de malware ou d’utilisation abusive.
Pour signaler un problème à GlobalSign, cliquez ici.
Avec les nouveaux systèmes de signalement, même si un éditeur malveillant passe à travers les mailles du filet des procédures de vérification, leurs certificats peuvent être rapidement signalés, étudiés et révoqués.
L’horodatage, une obligation pour toutes les AC
Autre nouveauté susceptible d’intéresser les développeurs : toutes les autorités de certification doivent désormais exploiter une autorité d’horodatage (AH) conforme à la RFC-3161 et la tenir à la disposition de tous les clients de certificats de signature de code. Cela signifie qu’un horodatage de confiance peut être inclus dans chaque signature. (Remarque : GlobalSign a toujours fourni un service d’horodatage à ses clients de certificats de signature de code.)
Principal avantage : lorsque le certificat expire, la signature reste valide — ce qui ne serait pas le cas sans le sceau d’horodatage. Les signatures restent valables pendante toute la durée de vie du certificat horodaté, soit 135 mois maximum, comme le précisent les exigences.
En cas de compromission des clés, et de la révocation de certificat qui en découle, l’horodatage présente un avantage clair. Si votre clé a été utilisée pour signer un code légitime, mais qu’elle est ultérieurement compromise et utilisée pour signer un code malveillant, vous pouvez fixer la révocation à une date comprise entre les deux événements. Ainsi, votre code légitime inspire toujours confiance, contrairement au code malveillant.
Un avenir plus sûr pour la signature de code
Les nouvelles normes et exigences marquent une étape essentielle vers la réduction des attaques contre les signatures de code. Microsoft est le premier éditeur de logiciels d’applications à adopter les recommandations qu’il mettra en œuvre au 1er février 2017. D’ici là, tous les certificats de signature de code GlobalSign seront conformes aux nouvelles exigences.
Pour toutes vos questions sur ces changements, n’hésitez pas à nous contacter. Nous vous recommandons également la lecture de ce livre blanc du CASC pour approfondir les normes et bonnes pratiques applicables à la signature de code : Livre blanc sur la signature de code : What It Is, Best Practices, and Why It’s Important [Définition, bonnes pratiques, et pourquoi est-ce important].
