Renforcer la confiance dans l’authenticité des logiciels open source

Les logiciels open source – les logiciels distribués gratuitement, avec leur code source, afin que des copies, des ajouts ou des modifications puissent être facilement effectués – sont « partout », pour citer le rapport 2023 sur la sécurité et l'analyse des risques de l'Open Source. Parmi les programmes informatiques utilisés par les principales industries, 96 % incluent des logiciels open source, et 76 % de ces programmes sont constitués de logiciels open source. Mais le pourcentage de progiciels « contenant des failles de sécurité reste extrêmement élevé », prévient le rapport.

L'une des préoccupations est que “le logiciel que vous avez obtenu d'un développeur que vous pensez être fiable a été compromis d'une manière ou d'une autre”, déclare Kelsey Merrill, ingénieur logiciel qui a obtenu une maîtrise plus tôt cette année au Département de génie électrique et d'informatique du MIT. . “Supposons que quelque part dans la chaîne d'approvisionnement, le logiciel ait été modifié par un attaquant malveillant.”

Le risque d’une telle faille de sécurité n’est en aucun cas abstrait. En 2020, pour prendre un exemple notoire, la société texane SolarWinds a réalisé une mise à jour logicielle de son programme très utilisé appelé Orion. Des pirates ont pénétré dans le système, insérant du code pernicieux dans le logiciel avant que SolarWinds ne livre la dernière version d'Orion à plus de 18 000 clients, dont Microsoft, Intel et environ 100 autres sociétés, ainsi qu'une douzaine d'agences gouvernementales américaines, dont le ministère de l'Environnement. État, Défense, Trésorerie, Commerce et Sécurité intérieure.

Dans ce cas, le produit corrompu provenait d'une grande entreprise commerciale, mais des défaillances peuvent être encore plus susceptibles de se produire dans le domaine de l'open source, explique Merrill, « où des personnes d'horizons divers, dont beaucoup sont des amateurs sans aucune formation en sécurité. – peut publier des logiciels utilisés dans le monde entier.

Elle et trois collaborateurs : son ancienne conseillère Karen Sollins, scientifique principale au Laboratoire d'informatique et d'intelligence artificielle du MIT ; Santiago Torres-Arias, professeur adjoint d'informatique à l'Université Purdue ; et Zachary Newman, ancien étudiant diplômé du MIT et actuel chercheur chez Chainguard Labs, ont développé un nouveau système appelé Speranza, qui vise à rassurer les consommateurs de logiciels sur le fait que le produit qu'ils obtiennent n'a pas été falsifié et provient directement d'une source. ils ont confiance. L'article est publié sur le arXiv serveur de préimpression.

“Ce que nous avons fait”, explique Sollins, “c'est développer, prouver que c'est correct et démontrer la viabilité d'une approche qui permet aux responsables (de logiciels) de rester anonymes.” Préserver l’anonymat est évidemment important, étant donné que presque tout le monde – y compris les développeurs de logiciels – accorde de l’importance à la confidentialité. Cette nouvelle approche, ajoute Sollins, “permet simultanément aux utilisateurs (de logiciels) d'avoir l'assurance que les responsables sont, en fait, des responsables légitimes et, en outre, que le code téléchargé est, en fait, le code correct de ce responsable.”

Alors, comment les utilisateurs peuvent-ils confirmer l’authenticité d’un progiciel afin de garantir, comme le dit Merrill, « que les responsables sont bien ceux qu’ils prétendent être ? » La manière classique de procéder, inventée il y a plus de 40 ans, consiste à utiliser une signature numérique, qui est analogue à une signature manuscrite, mais avec une sécurité intégrée bien plus grande grâce à l'utilisation de diverses techniques cryptographiques.

Pour réaliser une signature numérique, deux « clés » sont générées en même temps, chacune étant un nombre composé de zéros et de uns, composé de 256 chiffres. Une clé est désignée « privée », l'autre « publique », mais elles constituent une paire mathématiquement liée.

Un développeur de logiciels peut utiliser sa clé privée, ainsi que le contenu du document ou du programme informatique, pour générer une signature numérique attachée exclusivement à ce document ou programme. Un utilisateur de logiciel peut ensuite utiliser la clé publique, ainsi que la signature du développeur et le contenu du package qu'il a téléchargé, pour vérifier l'authenticité du package.

La validation se présente sous la forme d'un oui ou d'un non, d'un 1 ou d'un zéro. “Obtenir un 1 signifie que l'authenticité a été assurée”, explique Merrill. “Le document est le même que lorsqu'il a été signé et est donc inchangé. Un 0 signifie que quelque chose ne va pas et vous ne voudrez peut-être pas vous fier à ce document.”

Bien que cette approche vieille de plusieurs décennies soit éprouvée dans un sens, elle est loin d’être parfaite. L'un des problèmes, note Merrill, “est que les gens ne parviennent pas à gérer les clés cryptographiques, qui sont constituées de très longs chiffres, de manière sécurisée et pour éviter qu'elles ne se perdent”. Les gens perdent constamment leurs mots de passe, explique Merrill. “Et si un développeur de logiciels perdait la clé privée et contactait ensuite un utilisateur en lui disant : “Hé, j'ai une nouvelle clé”, comment saurez-vous de qui il s'agit réellement ?”

Pour répondre à ces préoccupations, Speranza s'appuie sur « Sigstore », un système introduit l'année dernière pour renforcer la sécurité de la chaîne d'approvisionnement en logiciels. Sigstore a été développé par Newman (qui a lancé le projet Speranza) et Torres-Arias, ainsi que John Speed ​​Meyers de Chainguard Labs. Sigstore automatise et rationalise le processus de signature numérique. Les utilisateurs n'ont plus à gérer de longues clés cryptographiques mais reçoivent à la place des clés éphémères (une approche appelée « signature sans clé ») qui expirent rapidement (peut-être en quelques minutes) et n'ont donc pas besoin d'être stockées.

Un inconvénient de Sigstore vient du fait qu'il a renoncé aux clés publiques de longue durée, de sorte que les mainteneurs de logiciels doivent plutôt s'identifier – via un protocole appelé OpenID Connect (OIDC) – d'une manière qui peut être liée à leurs adresses e-mail. Cette fonctionnalité, à elle seule, peut entraver l'adoption généralisée de Sigstore, et elle a servi de facteur de motivation et de raison d'être pour Speranza. “Nous prenons l'infrastructure de base de Sigstore et la modifions pour offrir des garanties de confidentialité”, explique Merrill.

Avec Speranza, l'intimité s'obtient à travers une idée originale qu'elle et ses collaborateurs appellent des « co-engagements identitaires ». Voici, en termes simples, comment fonctionne l'idée : l'identité d'un développeur de logiciels, sous la forme d'une adresse e-mail, est convertie en un soi-disant « engagement » qui consiste en un grand nombre pseudo-aléatoire. (Un nombre pseudo-aléatoire ne répond pas à la définition technique du terme “aléatoire” mais, en pratique, il est à peu près aussi bon que aléatoire.) Pendant ce temps, un autre grand nombre pseudo-aléatoire – l'engagement (ou co-engagement) qui l'accompagne – est généré et est associé à un progiciel que ce développeur a créé ou a reçu l'autorisation de modifier.

Afin de démontrer à un utilisateur potentiel d'un progiciel particulier qui a créé cette version du progiciel et l'a signé, le développeur autorisé publierait une preuve établissant un lien sans équivoque entre l'engagement qui représente son identité et l'engagement attaché à le produit logiciel. La preuve effectuée est d'un type spécial, appelée preuve à connaissance nulle, qui est une manière de montrer, par exemple, que deux choses ont une limite commune, sans divulguer de détails sur ce que sont ces choses – comme la valeur du développeur. adresse e-mail – le sont en fait.

“Speranza garantit que les logiciels proviennent de la bonne source sans obliger les développeurs à révéler des informations personnelles telles que leurs adresses e-mail”, commente Marina Moore, titulaire d'un doctorat. candidat au Centre pour la cybersécurité de l'Université de New York. “Cela permet aux vérificateurs de voir que le même développeur a signé un package plusieurs fois sans révéler qui est le développeur ou même les autres packages sur lesquels il travaille. Cela offre une amélioration de la convivialité par rapport aux clés de signature à long terme et un avantage en matière de confidentialité par rapport aux autres OIDC- solutions basées sur Sigstore.

Marcela Mellara, chercheuse scientifique au sein du groupe de recherche sur la sécurité et la confidentialité d'Intel Labs, est du même avis. “Cette approche présente l'avantage de permettre aux utilisateurs de logiciels de vérifier automatiquement que le package qu'ils obtiennent à partir d'un référentiel compatible Speranza provient d'un mainteneur attendu, et d'avoir l'assurance que le logiciel qu'ils utilisent est authentique.”