La Fondation Linux a lancé un service gratuit que les développeurs peuvent utiliser pour signer numériquement leurs versions et leurs autres objets logiciels, images de containers et code binaire. Le projet vise à renforcer la sécurité et l’auditabilité de la chaîne d’approvisionnement du logiciel open source, qui fait face ces dernières années à un nombre d’attaques sans précédent. Le code Sigstore sur lequel s’appuie ce service a été développé en partenariat avec Google, Red Hat et l’Université Purdue. Il sera maintenu à l’avenir par la communauté. Toutes les signatures et les événements liés seront stockés dans un journal public infalsifiable qui peut être monitoré pour découvrir de potentiels abus.

Sigstore utilise le protocole d’authentification OpenID pour attacher les certificats aux identités. Cela signifie qu’un développeur peut utiliser son adresse email ou son compte avec un fournisseur d’identité OpenID pour signer son logiciel. Cela diffère de la signature de code traditionnelle qui nécessite d’obtenir un certificat d’une autorité de certification (CA) qui est reconnue par les éditeurs ou responsables d’un écosystème logiciel particulier, par exemple Microsoft ou Apple. L’obtention d’un certificat de signature de code traditionnel nécessite de suivre des procédures spéciales qui incluent la vérification d’identité ou la participation à un programme de développement.

Une PKI géré par la Fondation Linux

Le client de signature sigstore génère une paire de clés éphémères de courte durée et contacte l’infrastructure de clé publique (PKI) sigstore qui sera gérée par la Fondation Linux. Le service de PKI vérifie que la connexion OpenID a bien été accordée et délivre un certificat basé sur la paire de clé qui sera utilisée pour signer le logiciel. L’événement de signature est enregistré dans le journal public de logs et les clés sont ensuite supprimées. Il s’agit ici d’une autre différence par rapport à la signature numérique existante parce que chaque événement de signature génère une nouvelle paire de clés et un certificat. Finalement, l’objectif est d’avoir une preuve publique qu’une identité particulière a signé un fichier à un moment donné. C’est à la communauté de bâtir ensuite des outils utilisant ces informations pour créer des politique et des mécanismes d’application.

« C’est simplement basé sur les autorités de certification X.509 normales, afin que chacun puisse ajouter sa propre autorité de certification racine », indique Dan Lorenc, membre de l’équipe de sécurité open source de Google et contributeur du projet. « Il est possible de se débarrasser de la nôtre si on ne veut pas lui faire confiance, chacun peut ajouter ses propres intermédiaires », a-t-il expliqué à CSO. Les développeurs peuvent utiliser le service PKI public et le journal de transparence ou bien ils peuvent déployer leur propre système de signature interne pour leur organisation. Le code du service de journalisation, baptisé Rekor, et celui de l’autorité de certification racine, Fulcio, sont en open source, disponible sur GitHub.

Contrer les attaques de référentiels de packages

De façon générale, la signature de code logiciel est utilisé pour fournir des garanties sur la provenance du logiciel, en apportant la preuve qu’une portion de code vient bien d’un développeur ou d’une organisation en qui l’utilisateur a confiance. Les solutions de liste blanche d’applications, par exemple, utilisent ces informations pour appliquer les politiques d’utilisation sur les logiciels et leur provenance lorsque l’un d’eux va s’exécuter sur un système particulier. Ces politiques peuvent être étendues de la même façon aux gestionnaires de packages. Tout logiciel moderne est construit à l’aide de composants open source tiers qui constituent souvent la majeure partie de leur base de code. C’est pour cette raison qu’il y a eu des attaques contre des référentiels de packages open source comme npm, PyPi ou Ruby Gems.

L’une des techniques d’attaques récemment révélée est la confusion de dépendance. Elle agit en trompant les gestionnaires de packages par l’installation d’une fausse variante d’un package local particulier. Pour se faire, elle publie un package ayant le même nom mais se présentant comme une version supérieure dans le référentiel public. Les politiques de sécurité construites autour des signatures numériques des logiciels peuvent aider à prévenir de telles attaques. Elles permettent aussi de contrer celles où le serveur de téléchargement ou de mise à jour utilisé par un développeur de logiciels est compromis avec des packages légitimes remplacés par des logiciels malveillants ou des attaques de type « man-in-the-middle » contre les mécanismes de mise à jour du logiciel.

Créer des outils de type HaveIBeenPwned à partir du journal

Il existe d’autres attaques, comme la compromission de l’ordinateur d’un développeur ou de l’infrastructure de construction des logiciels, ou encore l’injection de code malveillant au cours des premières étapes du développement logiciel, comme dans la récente attaque SolarWinds qui a impacté des milliers d’entreprises. La signature de code n’aurait pas nécessairement empêché cette attaque car la signature d’une version logicielle est l’une des dernières étapes avant la distribution et elle aurait été faite après l’injection de code. Cependant, un journal de transparence comme celui qui fait partie de sigstore pourrait fournir des informations précieuses aux enquêteurs sur un incident ou même conduire à la détection précoce d’une compromission.

Selon Luke Hinds, responsable de la sécurité chez Red Hat, le journal peut être utilisé pour bâtir des outils de monitoring similaires dans leur fonctionnement au service de notification de violation de données HaveIBeenPwned.com. Avec ce dernier, un utilisateur peut saisir son adresse e-mail et être averti s’il apparaît dans l’une des violations publiques qui ont été répertoriées. Les développeurs pourraient utiliser un tel outil pour être avertis chaque fois que leur adresse e-mail apparaît dans le journal sigstore. Si un tel événement se produit alors qu’ils savent qu’ils n’ont pas été actifs, c’est immédiatement un signal d’alarme indiquant que leur compte ou système a peut-être été compromis et que quelqu’un signe un logiciel en leur nom. « Le journal de transparence n’a pas la capacité de bloquer les attaques, mais il vous donne sur ces attaques des informations que vous n’avez tout simplement pas actuellement », a déclaré Luke Hinds à CSO. « Il assure la transparence autour de la supply chain logicielle ».

Des chercheurs de l’Université Purdue travaillent sur un prototype d’outil de surveillance qui utilisera le journal. Les responsables de ce projet espèrent qu’au fur et à mesure la communauté open source et les acteurs privés de la sécurité vont construire des outils autour du service sigstore. Par exemple, les entreprises évoluant dans le développement pourraient déployer le système et créer des contrôles de sécurité granulaires. « En soi, ce n’est pas un moteur d’application de politique que nous créons, mais les outils et primitives que vous pouvez utiliser pour bâtir l’un de ces moteurs d’application de politique », explique Dan Lorenc, membre de l’équipe de sécurité open source de Google. « Vous pouvez avoir 12 développeurs et décider que 7 d’entre eux doivent signer un artefact pour que celui-ci soit bon », cite-t-il en exemple. « Vous pouvez imaginer toutes sortes de scénarios comme celui-là. »

Source lemondeinformatique.fr