Navigation – Plan du site

AccueilNuméros11DossierL'autonomie de l'écriture informa...(Dé)coder la sécurité de l’inform...

Dossier
L'autonomie de l'écriture informatique en question

(Dé)coder la sécurité de l’information entre maintenance et innovation : le cas d’OpenPGP

(De)coding information security between maintenance and innovation: the case of OpenPGP
Sylvain Besençon

Résumés

La sécurité de l’information est devenue un enjeu majeur des sociétés contemporaines. Cet article vise à mieux comprendre comment la sécurité est codée dans les programmes informatiques en s’appuyant sur une étude de cas autour du standard OpenPGP, notamment utilisé pour protéger les emails. Globalement peu étudié du point de vue des sciences sociales, le travail ordinaire et routinier de soin du code est au cœur de l’analyse. Celle-ci se base sur la manière dont les différentes personnes impliquées dans la maintenance du code tâchent de réaliser leur « projet-sécurité » tout en faisant face à la constante émergence de bugs. Le propos suit particulièrement la trajectoire de la série de vulnérabilités EFAIL rendue publique en mai 2018. Cet article montre comment le code informatique, en tant qu’objet de sollicitude, est collectivement produit et sans cesse transformé dans un souci constant de vigilance, d’attention et de soin. Issu d’une recherche ethnographique de plusieurs années parmi des codeur·se·s et chercheur·se·s en sécurité, l’article insiste sur les pratiques collaboratives et peu visibles de maintenance et d’innovation qui assurent la sécurité du code. Cet article commente ainsi le cycle qui lie sécurité et insécurité et propose la notion de processus d’(in)sécurisation pour rendre compte de ces transformations quotidiennes.

Haut de page

Texte intégral

Introduction 

  • 1 La science est un processus collectif. Je tiens à remercier chaleureusement les codeur·se·s qui m’o (...)

1La sécurité de l’information attire de plus en plus l’attention des médias, des politiques et du grand public1. Allant de la protection des données personnelles à la sécurité nationale en passant par la sécurité matérielle du hardware, la sécurité de l’information est tantôt décrite en termes de vulnérabilités informatiques (Spencer, 2021), de malware (Balzacq & Dunn Cavelty, 2016), de protection de la vie privée (Diffie & Landau, 2010) ou de menaces géopolitiques sur le territoire national (Dunn Cavelty, 2007 ; Saco, 1999). Si l’emphase est souvent mise sur les moments de crises et de « désastres numériques » (Hansen & Nissenbaum, 2009), d’autres études ont cherché à montrer « le travail ordinaire de la sécurité » (Denis & Kessous, 2012). Plusieurs analyses ont conceptualisé ce travail comme un travail de soin, souvent invisibilisé, peu valorisé, et néanmoins essentiel (Denis, 2012 ; Kocksch et al., 2018 ; Puig de la Bellacasa, 2010). Toutefois, le travail des codeur·se·s qui fabriquent la sécurité de l’information demeure peu étudié en sciences sociales. Basé sur une recherche en cours sur la maintenance du standard cryptographique OpenPGP, cet article propose une réflexion sur la façon dont la sécurité transforme le code au quotidien.

2Clé de voûte essentielle pour garantir la confidentialité et l’intégrité des données, la cryptographie est omniprésente au sein des sociétés numériques. Elle « permet de garantir la responsabilité, l’équité, l’exactitude et la confidentialité. Elle peut prévenir la fraude dans le commerce électronique et garantir la validité des transactions financières. Elle peut prouver votre identité ou protéger votre anonymat. Elle peut empêcher les malfaiteurs de modifier votre page Web et empêcher les concurrents industriels de lire vos documents confidentiels » (Schneier, 1997 : 1, ma traduction).

3La cryptographie constitue un objet multidimensionnel complexe qui englobe aussi bien des notions mathématiques (Blanchette, 2012 ; Schneier, 1997), des processus de construction de confiance (Bruun et al., 2020 ; Ruh, 2018), des discours et idéologies politiques (Bozzini, 2016 ; Gürses et al., 2016 ; Hellegren, 2017 ; West, 2018), des batailles juridique (Levy, 2001), ainsi que des enjeux stratégiques de renseignement (Diffie & Landau, 2010). En ce qui concerne la sécurité des systèmes cryptographiques, c’est généralement le point de vue de l’ingénierie mathématique qui prime (Blanchette, 2012). Or, l’observation des pratiques de maintenance du code de programmes cryptographiques révèlent pourtant un autre versant de la sécurité, très éloigné d’une quelconque pureté mathématique et beaucoup plus proche du « bazar » propre aux communautés open source (Raymond, 2001) : une incessante collaboration et un apprentissage réciproque entre différentes communautés de pratiques (Lave & Wenger, 1991).

4Malgré un croissant intérêt en anthropologie sur les questions de sécurité (Goldstein, 2010 ; Low & Maguire, 2019 ; Maguire et al., 2014), peu d’études ethnographiques ont prêté une attention particulière à la sécurité de l’information (Bozzini, 2016 ; Denis, 2009 ; 2012 ; Kocksch et al., 2018 ; Korn & Wagenknecht, 2017). Afin de contribuer à une meilleure compréhension de la fabrique sociale de la sécurité, cet article se concentre sur la vision des personnes qui la font et la défont au quotidien. Cette emphase sur la construction quotidienne de la sécurité permet de dégager deux niveaux de sécurité. Il y a d’un côté la stabilité du code lui-même : est-il bien conçu, présente-t-il des failles, est-il fiable ? De l’autre, il y a la sécurité que cherche à produire ce code : protège-t-il efficacement les données chiffrées et, par extension, les personnes concernées par ces données ? Aussi, le code devient à la fois objet et acteur de l’(in)sécurité. Dans les deux cas, la sécurité est questionnée et négociée continuellement par les développeur·se·s et les autres personnes impliquées. Dès lors, cet article se distancie de toute définition normative de la sécurité en se focalisant sur le côté processuel, évolutif et réflexif de la sécurité telle qu’elle est perçue par les personnes qui la codent au quotidien.

5Ma démarche s’inscrit dans un dialogue entre deux champs de recherche : d’une part, les travaux documentant les processus complexes d’écriture du code informatique dans les milieux open source (Couture, 2012 ; Demazière et al., 2011 ; Marino, 2020 ; Méadel & Sire, 2017 ; von Krogh et al., 2003) et, d’autre part, le concept de « sécurisation ». Développé à l’origine par des scientifiques en relations internationales (Buzan et al., 1998), le concept de sécurisation propose une vision constructiviste de la sécurité en tant qu’acte de langage performatif. Selon cette approche, un acte de sécurisation combine trois conditions : la construction d’une trame narrative articulant une menace avec des scénarios possibles et une solution ; une position d’autorité de laquelle est énoncé ce discours ; et des objets généralement perçus comme menaçants (Macleod, 2004). Le champ d’application de ce concept, d’abord utilisé dans un contexte militaire et de sécurité nationale, a été élargi à de nombreux autres domaines, y compris la sécurité de l’information (Balzacq & Dunn Cavelty, 2016). Par ailleurs, la vision de la sécurisation en tant que pure construction discursive a également été étendue en insistant notamment sur les pratiques qui produisent la sécurité (Balzacq, 2011 ; Hansen & Nissenbaum, 2009). En l’appliquant à la production de code informatique, je propose de poursuivre cet élargissement du concept de sécurisation dans deux directions.

6D’une part, je considère les différentes temporalités en jeu. Certaines pratiques, comme la révélation publique de failles de sécurité, créent des événements extraordinaires (Bensa & Fassin, 2002 ; Nora, 1974) qui correspondent en tout point à la trame narrative de la sécurisation. Toutefois, il me paraît important de considérer la fabrique de la sécurité de l’information au-delà de la rhétorique de crise (Roitman, 2014) et l’étudier en tant que « pratique ordinaire, en régime non pas de crise, mais de "justesse" au sein duquel activités et dispositifs sont déployés sans justifications majeures et ajustés aux situations sur le mode de la coordination quotidienne » (Denis, 2012, §7).

7D’autre part, je tâche d’étendre la notion de sécurisation par un changement de perspective. En effet, la plupart des études en sciences sociales sur la sécurité de l’information questionnent comment des programmes informatiques sécurisent (ou insécurisent, dans le cas des virus par exemple) les utilisateur·trice·s, la société ou l’État (Balzacq & Dunn Cavelty, 2016 ; Hansen & Nissenbaum, 2009 ; Suchman et al., 2017). En suivant l’injonction de porter une plus grande attention aux pratiques quotidiennes de soin face à la fragilité des systèmes informatiques (Denis & Kessous, 2012 ; Kocksch et al., 2018), cet article renverse la question et analyse ce que la sécurité fait au code informatique. On peut dès lors se demander quels sont les objets, pratiques et discours sécuritaires qui contribuent à transformer le code. Prenant acte de la constante oscillation du code entre sécurité et insécurité, je souhaite faire le récit de ses transformations parfois quotidiennes en mobilisant le concept d’(in)sécurisation. De quoi le travail des codeur·se·s de tels programmes est-il fait ? Comment de nouvelles lignes de code peuvent-elles à la fois sécuriser et insécuriser le produit final ? Comment la production d’(in)sécurité se déroule-t-elle ?

Méthodologie de recherche

8Pour répondre à ces questions, je m’appuie sur une étude ethnographique commencée en 2018 auprès de personnes qui écrivent, testent, maintiennent et attaquent des programmes implémentant le standard OpenPGP. La période de production des données ethnographiques de cette recherche menée à la fois en ligne et hors ligne est divisée en deux temps. J’ai commencé par une exploration non-participante de différents sites. Cela comprend d’une part une ethnographie en ligne sur des sites d’information spécialisés, des forums, différentes listes de diffusions, des discussions ayant lieu sur Twitter ou d’autres plateformes de chat, ainsi que des plateformes de partage de code telles que GitLab et GitHub. D’autre part, cette exploration s’est aussi faite en assistant à des conférences de sécurité de l’information où j’ai aussi participé à des ateliers et formations. Cette première phase m’a permis de me familiariser avec le champ de recherche, et notamment son jargon technique, ainsi que de cerner les principaux enjeux des discussions à propos d’OpenPGP.

9La seconde phase de mon terrain a débuté en 2019 quand j’ai activement commencé à interagir avec la communauté OpenPGP grâce à des interviews, des échanges écrits sur différents canaux ainsi qu’une observation participante lors de différentes réunions de travail. Ainsi, durant près d’une année, j’ai assisté à la plupart des deux séances de travail hebdomadaires d’une équipe de développement, ainsi qu’aux séances du groupe de travail du standard OpenPGP. Du fait de la pandémie mondiale de coronavirus, ces observations ont été faites principalement en ligne en assistant à des visioconférences. L’inconvénient principal de ce terrain en ligne est bien entendu l’absence de moments informels avant, pendant et après ces séances où il est d’ordinaire possible de créer et d’entretenir des liens plus forts avec les participant·e·s à la recherche, ainsi que d’avoir un retour à chaud lors des pauses. Je souligne néanmoins que l’expérience que j’ai eue correspond à celle de mes participant·e·s à la recherche, qui regrettaient aussi ces moments informels. Par ailleurs, un avantage certain du télétravail réside dans la facilité d’accès à un nombre très important de séances de travail.

10Pour la rédaction de cet article, j’ai également mobilisé 21 entretiens semi-directifs cumulant plus de 30 heures de conversation. Ces entretiens ont été menés avec dix codeur·se·s de différents programmes implémentant OpenPGP, quatre chercheurs qui ont trouvé des failles de sécurité, quatre membres du groupe de travail d’OpenPGP à l’IETF, ainsi que deux cryptographes et un journaliste ayant écrit sur EFAIL. Je mène également plusieurs discussions moins formalisées à travers différents canaux de chat en ligne (principalement dans des salons IRC) qui me permettent de suivre l’actualité du standard OpenPGP et de creuser certains aspects du travail d’(in)sécurisation.

11Cet article a pour fil rouge EFAIL, une série de failles de sécurité affectant OpenPGP qui a été révélée publiquement en mai 2018. En mobilisant le concept d’(in)sécurisation, j’analyse comment ces failles ont tour à tour contribué à sécuriser et insécuriser le code. J’explore comment les codeur·se·s ont tenté de réduire l’insécurité qu’apportaient ces failles et comment leurs solutions ont parfois fait émerger d’autres failles ailleurs dans le code. Le propos de cet article est divisé en trois sections. Dans la première, je clarifie plusieurs éléments qui permettent de comprendre le contexte de mon analyse. J’y présente notamment OpenPGP et décris les trois implémentations sur lesquelles se base cet article. La deuxième section est dédiée à un événement majeur de l’histoire d’OpenPGP : la divulgation des vulnérabilités d’EFAIL. J’analyse comment cette série de failles a engendré une importante controverse ainsi que de nombreuses transformations du code. Dans la troisième section, je me tourne vers les personnes qui sont derrière le travail de sécurisation du code. J’analyse particulièrement l’incessant dialogue au travers duquel la sécurité et l’insécurité sont négociées et coconstruites par les différent·e·s contributeur·trice·s. Commentant le cycle qui lie sécurité et insécurité, je termine en proposant la notion de processus d’(in)sécurisation pour conceptualiser ces pratiques de transformation du code.

1. OpenPGP et ses implémentations

  • 2 L’IETF est un organisme de standardisation des protocoles internet, notamment la suite de protocole (...)
  • 3 Les références précédées d’un astérisque renvoient aux sources ethnographiques issues de mon terrai (...)
  • 4 Pour un historique des différentes versions du standard à l’IETF, voir (*CVA, 2021).

12OpenPGP est un protocole de chiffrement standardisé par l’Internet Engineering Task Force (IETF)2. Toutefois, si OpenPGP est le nom officiel du standard, PGP est son nom historique et informellement utilisé pour parler de cette technologie. PGP est l’acronyme de Pretty Good Privacy. Il s’agit d’un programme informatique développé par Philip R. Zimmermann, codeur et activiste anti-nucléaire états-unien qui a partagé le code de son programme sur une liste de diffusion une nuit de juin 1991 (*Zimmermann, 19993). PGP a été une révolution dans le domaine de la vie privée numérique puisqu’il est le premier programme librement accessible qui implémente la technologie de cryptographie à clé publique à des fins civiles (Coleman & Golub, 2008 ; Levy, 2001). Depuis, le programme de Zimmermann a non seulement donné naissance à un standard de l’IETF4, mais également à de nombreux programmes implémentant ce standard. Dès lors, plutôt que de désigner un programme précis (qui n’est d’ailleurs pratiquement plus utilisé de nos jours), PGP désigne généralement cet ensemble d’implémentations regroupées autour du standard OpenPGP.

  • 5 Si n’importe qui a la possibilité d’envoyer des questions ou commentaires sur la liste de diffusion (...)
  • 6 Chiffrer un message correspond à en protéger le contenu grâce à des opérations mathématiques qui le (...)

13Il est utile de noter que comme tous les standards produits par l’IETF, OpenPGP se matérialise sous la forme d’un document public qui décrit les spécificités de ce standard (*RFC 4880). Écrit principalement par et pour les développeur·se·s de programmes5, ce document décrit les directives à suivre pour chiffrer et signer6 des données dans un format interopérable qui puisse être lu et interprété par différents systèmes et programmes. OpenPGP n’est donc pas écrite en code informatique mais en anglais, et n’est pas destinée à être lue par des machines mais par des humains. Dans la hiérarchie infrastructurelle d’Internet, OpenPGP est donc un élément sur lequel reposent les implémentations de ce standard. Ces dernières, sont, quant à elles, codées en différents langages informatiques et leur code source, après avoir été compilé en code binaire, est lu par des machines.

  • 7 Voir par exemple la liste de diffusion des utilisateur·trice·s de GnuPG (*GnuPG-Users).
  • 8 Plusieurs personnes m’ont également assuré que je faisais aussi partie de cette communauté en tant (...)
  • 9 Non seulement, le tutoriel de 12 minutes posté sur Vimeo par anon108 en janvier 2013 a été attribué (...)

14Les implémentations d’OpenPGP partagent la volonté explicite de respecter les spécifications du standard, garantissant ainsi qu’un message chiffré avec l’une de ces implémentations pourra être lu et interprété par les autres : il s’agit du principe d’interopérabilité, central dans la philosophie de l’IETF. Ce souci de l’interopérabilité participe à un sentiment d’appartenance à la « communauté OpenPGP ». La « communauté OpenPGP » est un terme emique qu’utilisent les personnes que j’ai interviewées pour parler d’un ensemble assez flou et hétérogène de personnes concernées par OpenPGP. Selon les opinions, cela peut comprendre non seulement les codeur·se·s des différentes implémentations et les membres du groupe de travail de l’IETF, mais également de nombreux·ses utilisateur·trice·s qui forment un public récursif particulièrement actif (Kelty, 2008)7. Par ailleurs, certaines personnes n’hésitent pas à inclure également d’autres acteur·trice·s qui interviennent de près ou de loin dans les affaires d’OpenPGP. Il s’agit par exemple des chercheur·se·s universitaires qui travaillent sur ce standard notamment pour y trouver des failles8, des cryptographes et autres expert·e·s qui défendent ou critiquent le standard publiquement (par exemple sous forme de blog, de tweets ou de conférences), et des utilisateur·trice·s particulièrement médiatisé·e·s, comme cela a par exemple été le cas avec Edward Snowden9.

  • 10 Une liste complète des implémentations d’OpenPGP peut être consultée sur le site internet du standa (...)

15Parmi cette communauté hétérogène, cet article se focalise sur les trois implémentations suivantes10 :

  • Gnu Privacy Guard, abrégé GnuPG (ou simplement GPG), est un programme en ligne de commande codé en C. GnuPG sert également de base à la librairie GnuPG Made Easy (GPGME), utilisée par de nombreux clients email. Son histoire remonte à 1997 lorsque Werner Koch a codé une version open source du programme PGP de Zimmermann. GnuPG a son siège en Allemagne où est employé le noyau dur de l’équipe de développement du projet, même si des contributeur·trice·s se trouvent dispersé·e·s sur tout le globe. Le code source se trouve sur le site de GnuPG (*GnuPG, GIT).

  • OpenPGP.js est une librairie implémentant le standard en JavaScript, un langage informatique destiné à être exécuté au sein de navigateurs web. Cela rend possible l’utilisation d’OpenPGP sans avoir à installer un programme spécifique sur l’ordinateur car le code est interprété directement par le navigateur au sein d’une application web. C’est l’entreprise ProtonMail, basée en Suisse, qui maintient officiellement cette librairie open source dont le code est disponible sur GitHub (*GitHub, OpenPGP.js). Cette librairie est également utilisée par de nombreux autres projets, dont Mailvelope, GlobalLeaks et FlowCrypt.

  • Sequoia PGP est la dernière venue de ses implémentations : il s’agit d’une librairie open source débutée en 2017 qui implémente OpenPGP en RUST, un nouveau langage informatique axé sur la performance et la sécurité. Sequoia PGP vise explicitement à créer une implémentation plus performante, légère et simple à utiliser que GnuPG. Sequoia PGP emploie une demi-douzaine de personnes en Europe mais reçoit également des contributions de codeur·se·s d’Amérique du Nord et d’Asie. Son code source se trouve sur sa plateforme GitLab (*GitLab, Sequoia).

2. Des vulnérabilités qui (in)sécurisent le code

16Qu’est-ce qui crée de la sécurité ou de l’insécurité ? D’où viennent les failles de sécurité ? Qui les trouve et qui les corrige dans le code ? Si répondre à ces questions nécessite d’étudier chaque cas séparément, les observations que j’ai menées auprès des différentes implémentations d’OpenPGP indiquent que des failles sont trouvées et corrigées quotidiennement. J’ai très vite compris comment la sécurité était perçue par les personnes qui la codent non pas comme un état mais comme un objectif vers lequel tendre sans jamais pouvoir l’atteindre complètement. En effet, les codeur·se·s passent une grande partie de leur temps à tâcher de prendre soin de problèmes qui ne cessent d’arriver. C’est pourquoi je préfère parler de « projet-sécurité » pour souligner le côté relationnel et non définitif de la sécurité. La présentation de l’histoire de la révélation d’EFAIL et ce qui s’en est suivi permet d’illustrer comment la sécurité et l’insécurité sont en oscillation constante.

17Le cycle de vie d’une vulnérabilité est idéalement le suivant : une vulnérabilité est trouvée soit par l’expérimentation d’un problème, soit par une recherche active. Ce sont souvent les codeur·se·s elles·eux-mêmes qui la trouvent, mais si ce n’est pas le cas, la vulnérabilité est révélée aux personnes responsables (par exemple via GitHub ou GitLab, dans un rapport d’audit ou lors d’une communication directe). Les codeur·se·s se saisissent du problème, codent un correctif, le testent et l’appliquent au code en créant une nouvelle version. Puis, pour terminer le cycle, une mise à jour doit être installée sur les machines des utilisateur·trice·s. Ce scénario correspond à un scénario idéal où tout se passe bien. C’est le cas de nombreux bugs qui entraînent des pratiques quotidiennes et routinières de maintenance et d’innovation que l’on peut notamment observer sur les plateformes de partage de code utilisées par les développeur·se·s (notamment GitHub et GitLab ; voir aussi la sous-section 2.2. sur la CVE-2020-25125). Cependant, il arrive que certaines vulnérabilités créent des problèmes et attirent beaucoup plus l’attention. Ce sont généralement des événements extraordinaires qui marquent un « changement de rythme […] qui altère les rapports au passé et à l’avenir » (Bensa & Fassin, 2002, § 19), comme cela a été le cas de la révélation publique d’EFAIL.

2.1. EFAIL, un événement critique et critiqué

  • 11 CVE est l’abréviation de « Common Vulnerability and Exposure », le registre le plus utilisé pour tr (...)

18Avant de parler de la controverse suscitée par la révélation publique d’EFAIL, il semble important d’expliquer ce qu’est EFAIL. Or, ce terme renvoie à une grande diversité d’interprétations. Objet-frontière (Leigh Star, 2010 ; Star & Griesemer, 1989 ; Trompette & Vinck, 2009) qui circule entre les mondes des universitaires, des développeur·se·s et des utilisateur·trice·s, le nom d’EFAIL peut, selon le contexte, se référer à des réalités très différentes : une série de problèmes techniques à corriger dans le code ou au niveau du standard à l’IETF, une recherche scientifique définissant un nouveau type d’attaques cryptographiques, une urgente menace pour les utilisateur·trice·s, un fiasco de communication commis par une équipe d’universitaires et critiqué par de nombreuses personnes, un argument de plus pour ne plus utiliser OpenPGP, ou encore un article scientifique, un numéro CVE11, un logo et un nom de domaine (Besençon & Bozzini, 2020).

19Sans perdre de vue cette flexibilité interprétative, il faut toutefois commencer quelque part. Ainsi, selon la page internet qui lui est dédiée, « EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails » (*efail.de, 2018). « EFAIL » est donc d’abord un nom, celui que des chercheurs en cryptographie (tous des hommes) ont donné à un article présentant une série de vulnérabilités dans des protocoles de chiffrement d’email. EFAIL peut être considérée comme le fruit d’un projet de recherche scientifique de longue haleine, comme me l’a expliqué un des responsables du projet :

  • 12 TLS est un autre standard de l’IETF qui est utilisé pour sécuriser une connexion entre deux serveur (...)
  • 13 Tous les entretiens cités dans cet article ont été menés en anglais et toutes les citations sont le (...)

Nous avions déjà pas mal analysé TLS et y avions trouvé des vulnérabilités critiques12. OpenPGP, S/MIME et TLS partagent certaines constructions cryptographiques et nous voulions savoir s’il y avait des attaques similaires qui fonctionneraient contre OpenPGP et les emails. (Chercheur A, email du 27 septembre 2019)13

  • 14 Il ne me semble pas nécessaire de saisir les détails techniques des vulnérabilités d’EFAIL pour la (...)

20L’extrait ci-dessus rend explicite la volonté des chercheurs de trouver des vulnérabilités dans des systèmes cryptographiques connus. Cette logique s’inscrit dans une logique académique. En effet, casser des protocoles cryptographiques, c’est-à-dire y trouver des vulnérabilités et les exploiter, est une réussite professionnelle pour l’équipe de chercheurs et une avancée pour la science. Dans le cas d’EFAIL, les scientifiques ont par exemple mis au point une nouvelle technique nommée « malleability gadgets » qui permet la modification des données chiffrées dans le but d’obtenir un résultat lors du déchiffrement14.

21On peut ici ouvrir une parenthèse et se demander d’où viennent les failles d’EFAIL : les chercheurs les ont-ils simplement révélées ou les ont-ils créées ? Il est certain que le code lui-même était déjà vulnérable avant l’intervention des chercheurs puisque ces derniers ne l’ont absolument pas modifié. De ce point de vue, les chercheurs n’ont fait que révéler des défauts déjà existants dans le code. Pourtant, EFAIL peut aussi être considérée comme une création des chercheurs en cela qu’ils l’ont imaginée, recherchée, théorisée, et exploitée via de preuves de concept [proofs of concept]. De ce point de vue, bien qu’ils n’aient pas modifié le code, les chercheurs ont bel et bien créé EFAIL en tant qu’objet insécurisant OpenPGP.

22Mais EFAIL est-elle seulement un élément insécurisant ? Lors d’un entretien un des chercheurs m’a expliqué que localiser des failles dans OpenPGP était pour lui une manière de contribuer à renforcer la sécurité du standard en augmentant ce que l’on sait sur lui, et notamment ses surfaces d’attaques (chercheur B, 27 décembre 2019). Son argument était qu’il était préférable que ces failles soient trouvées par une équipe de chercheurs honnêtes plutôt que par une agence de renseignement ou un groupe de hackers puisque, dans un tel cas, les failles auraient certainement été exploitées sans être rendues publiques. La sécurité par l’insécurité est un argument très présent dans de nombreux discours des professionnel·le·s de la sécurité de l’information.

  • 15 Un consensus existe à propos d’un délai de 90 jours qui laisserait suffisamment de temps aux dévelo (...)

23Les chercheurs m’ont affirmé avoir toujours été conscients des risques encourus par les cibles potentielles des attaques présentées dans leur article scientifique. C’est pourquoi ils ont décidé de faire une révélation responsable [responsible disclosure] en avertissant un maximum de codeur·se·s en avance et en leur donnant un délai de plusieurs mois pour publier un correctif avant l’annonce publique des résultats de leur recherche (voir la chronologie établie par *Ptacek, 2018)15.

24Voyant que certaines implémentations tardaient à résoudre ces problèmes alors que le délai avait déjà été étendu plusieurs fois, les chercheurs ont décidé de révéler publiquement EFAIL. Afin de prévenir les utilisateur·trice·s sans leur faire courir un trop grand risque, ils ont opté pour une stratégie en deux temps tout à fait inhabituelle : avertir la communauté via Twitter qu’ils avaient trouvé des vulnérabilités en suggérant de désactiver le déchiffrement automatique de messages, et, le lendemain, publier les détails des attaques sous forme de site web (illustration 1). Les chercheurs ont coordonné cette annonce avec l’Electronic Frontier Foundation (EFF), l’une des organisations les plus réputées en matière de protection des droits sur Internet, qui a publié un billet de blog expliquant comment se protéger contre EFAIL (*EFF, 2018).

Illustration 1. Les deux premiers tweets du thread du Professeur Sebastian Schinzel annonçant la découverte d’une série de vulnérabilités critiques dans OpenPGP et renvoyant au blog d’EFF.

Illustration 1. Les deux premiers tweets du thread du Professeur Sebastian Schinzel annonçant la découverte d’une série de vulnérabilités critiques dans OpenPGP et renvoyant au blog d’EFF.

Source : *Schinzel, 2018.

25L’annonce de la vulnérabilité sur Twitter n’a pas eu l’effet escompté par les chercheurs et leur stratégie n’a guère été comprise. Au contraire, le tweet a été le déclencheur d’une intense controverse. Plusieurs critiques ont été émises à l’égard de cette stratégie de communication des chercheurs, bien que quelques rares voix ont également affirmé que ces derniers n’avaient pas eu beaucoup d’alternatives (*Schneier, 2018). De nombreuses personnes ont accusé les chercheurs de faire primer leurs intérêts personnels sur la sécurité des utilisateur·trice·s. L’illustration 2 donne un exemple parmi les dizaines de tweets critiquant la communication des chercheurs.

Illustration 2. Exemple de critiques à la suite de la révélation publique d’EFAIL, capture d’écran sur Twitter

Illustration 2. Exemple de critiques à la suite de la révélation publique d’EFAIL, capture d’écran sur Twitter

Source : Twitter, Mai 2018

26Plutôt que d’adopter une posture normative face à ces débats, il me semble nécessaire de prendre du recul sur ce qui s’est passé en réfléchissant à la question suivante : qu’est-ce qu’EFAIL a fait à la « sécurité » d’OpenPGP ? Les guillemets rappellent ici que la sécurité n’est pas définie de manière absolue mais de manière contextuelle.

27Il faut d’abord noter le grand sentiment d’incertitude et de confusion ressenti par de nombreux·ses utilisateur·trice·s. Cette incertitude était principalement nourrie par le manque d’information fournie par les chercheurs, qui a donné place à la formulation de nombreuses hypothèses qui ont renforcé l’impression de vulnérabilité. Par ailleurs, quelques heures après les premiers tweets, et alors que des informations concernant les attaques d’EFAIL commençaient à circuler (par exemple *Koch, 2018), les chercheurs ont décidé de révéler publiquement les failles et de mettre en ligne le site web qu’ils avaient préparé pour l’occasion (*Müller, 2018). Suite à cela, des tentatives de minimisation de la gravité des vulnérabilités d’EFAIL contrebalançaient – sans pour autant l’annuler – le mouvement de panique suscité par les premiers tweets de Schinzel. Un exemple de minimisation concerne l’extrait ci-dessous, qui a été beaucoup cité sur Twitter notamment. Il s’agit d’une déclaration officielle de GnuPG envoyée sur la liste de diffusion des utilisateur·trice·s de GnuPG, toujours ce 14 mai 2018 :

1. This paper is misnamed.

2. This attack targets buggy email clients.

3. The authors made a list of buggy email clients. (*Hansen, 2018)

28Cette formulation désinvolte est intéressante en ce qu’elle contraste fortement avec le ton alarmiste et spectaculaire de l’annonce conjointe des chercheurs et d’EFF. Par exemple, l’expression « buggy email clients » s’oppose aux « critical vulnerabilities » des chercheurs. Ce type d’affirmations contradictoires s’est d’ailleurs répété ailleurs : par exemple, le magazine Wired proclamait la mort du standard OpenPGP (*Wired, 2018) alors que ProtonMail affirmait ne pas être vulnérable aux attaques d’EFAIL (*ProtonMail, 2018). Ainsi, durant plusieurs jours, des discussions souvent houleuses ont eu lieu sur Twitter et d’autres forums spécialisés, et de nombreux articles de blogs et de journaux ont été publiés, alimentant l’incertitude au sujet d’EFAIL (*CVA, 2019 ; voir aussi Besençon & Bozzini, 2020).

29Si je m’arrête ici sur ce qui peut sembler des détails, c’est surtout pour insister sur un point important : EFAIL a été un événement insécurisant majeur comparable aux « grandes crises [...] qui remettent en cause les solutions déployées jusqu’ici et ouvrent les débats à de nombreux acteurs hétérogènes ; des contaminations qui déstabilisent des systèmes entiers qu’il faut ensuite remettre en ordre » (Denis, 2012 : 180). Or, il est intéressant de constater que l’insécurité ressentie par beaucoup ne venait pas tant des failles elles-mêmes que des débats et narrations contradictoires qui faisaient naître une grande incertitude et beaucoup de confusion à leur sujet. Alors que les théories de la sécurisation conceptualisent la sécurité en tant que construction discursive cohérente énoncée depuis une position d’autorité, le cas d’EFAIL échappe à cette définition étant donné la multiplication de points de vue. C’est pourquoi il me semble plus pertinent de concevoir EFAIL d’abord comme un processus d’insécurisation qui a nécessité des mois voire des années de « remise en ordre » et qui est dans une certaine mesure toujours en cours à l’heure où j’écris ces lignes.

30En effet, EFAIL ne saurait se résumer à ces quelques jours d’agitation sur des réseaux sociaux. Au-delà de l’événement de la révélation publique sur Twitter, EFAIL peut se lire un long et complexe processus qui s’étale en amont et en aval bien au-delà de sa révélation publique. Non seulement les chercheurs ont contacté des dizaines de clients emails implémentant OpenPGP des mois avant la publication des tweets (*Ptacek, 2018), mais EFAIL a également participé à transformer le code des implémentations et les spécifications du standard, et ce des mois voire des années après la révélation publique. La sous-section suivante propose une illustration de comment EFAIL a motivé certaines transformations en profondeur, tout en montrant aussi comment un processus de sécurisation produit toujours le risque d’une nouvelle insécurisation du code.

2.2. La CVE-2020-25125, un non-événement ordinaire entre sécurisation et insécurisation

  • 16 L’AEAD est l’acronyme de authenticated encryption with associated data : il s’agit d’un mécanisme q (...)

31En tant que série de vulnérabilités, EFAIL a été décortiquée en une multitude de problèmes spécifiques à corriger dans le code et le standard. Ainsi, le mode d’authentification des données chiffrées comptait parmi les points problématiques soulevés par les chercheurs. Un mois après la révélation publique, un des chercheurs de l’équipe d’EFAIL a envoyé un email sur la liste de diffusion d’OpenPGP de l’IETF dont l’objet était « AEAD mode chunk size » (*Brinkmann, 2018). Cet email proposait une mesure de mitigation d’EFAIL consistant en une implémentation plus rigoureuse de l’AEAD16. Cet email a généré une discussion de plusieurs années sur la liste de diffusion d’OpenPGP et ce n’est qu’en été 2021 qu’un compromis sur la définition de la chunk size semblait enfin pouvoir parvenir à un consensus au sein du groupe de travail (*OpenPGP-DT, 2021). Notons toutefois qu’en janvier 2022, cette solution n’était toujours pas entérinée par un consensus formel au sein du groupe de travail de l’IETF.

  • 17 « Le commit est un acte informatique qui consiste à valider formellement une modification du code s (...)

32Cette négociation théorique a été menée en parallèle avec un travail fait d’essais et d’erreurs dans le code des différentes implémentations. L’exemple qui suit montre comment l’adoption par défaut de l’AEAD a engendré de multiples processus d’écriture et de réécriture du code. Par exemple, le 9 juillet 2020, GnuPG a annoncé la disponibilité d’une nouvelle version de son code (v.2.2.21) (*GnuPG, 2020a). Parmi les changements mentionnés dans la note de version, on notera le suivant : « Support decryption of AEAD encrypted data packets ». Cette nouvelle version représente donc une des nombreuses étapes dans l’adoption de l’AEAD, discutée depuis deux ans sur la liste de diffusion d’OpenPGP. Cette mise à jour peut a priori être vue comme un pas de plus dans la sécurisation d’EFAIL. Or, le 7 septembre 2020, une nouvelle mise à jour de GnuPG (v.2.2.23) a été publiée pour sécuriser une « vulnérabilité critique » affectant les deux sous-versions précédentes (*GnuPG, 2020b). Cette vulnérabilité, assignée au numéro CVE-2020-25125 (*Mitre, 2020), concernait justement la partie du code liée à l’AEAD. La vulnérabilité a été révélée puis discutée en coulisse, mais une partie de ces échanges peut être consultée en ligne (*GnuPG, 2020c ; *Bugzilla, 2020), de même que bien évidemment le commit17 aeb8272ca8aa, nommé « gpg: Fix AEAD preference list overflow », qui a résolu le problème en modifiant une (seule) ligne de code (*Koch, 2020) :

Illustration 3. Capture d’écran du commit aeb8272ca8aa sur la plateforme GIT de GnuPG. On remarque que seule la ligne 2484 du code a été modifiée pour corriger cette vulnérabilité sévère.

Illustration 3. Capture d’écran du commit aeb8272ca8aa sur la plateforme GIT de GnuPG. On remarque que seule la ligne 2484 du code a été modifiée pour corriger cette vulnérabilité sévère.

Source : *Koch, 2020a

33Contrairement à EFAIL, la CVE-2020-25125 n’a pas été recherchée volontairement mais constatée suite à l’expérimentation d’un problème survenu après une mise à jour. Autrement dit, elle a été introduite involontairement par l’ajout d’un mécanisme censé sécuriser le code. Il a ensuite fallu identifier sa cause et rechercher une solution. Le commit aeb8272ca8aa est une étape certes ordinaire mais cruciale dans la transformation du code. Ordinaire car il ne s’agit « que » d’un commit parmi les milliers d’autres et que la CVE-2020-25125 n’a attiré l’attention d’aucun média ; cruciale car cette contribution a corrigé une vulnérabilité qui affectait de manière critique le code. Cet exemple illustre comment la sécurité est un processus dynamique où sécurité et insécurité s’entremêlent sans cesse, entre suppression, correction et ajout de lignes de code.

34Beaucoup d’éléments opposent les vulnérabilités d’EFAIL et la CVE-2020-25125 : la première est une série de vulnérabilités qui affectent l’ensemble des implémentations tandis que la seconde est un « accident » survenu entre deux sous-versions de GnuPG. EFAIL a été spectaculairement révélée au grand public tandis que la CVE-2020-25125 a été gérée très discrètement. Finalement, EFAIL a été recherchée et créée par une équipe de chercheurs qui s’étaient donné la mission explicite de trouver des failles dans OpenPGP, tandis que la seconde a été découverte « par hasard », dans une version du code qui justement tentait de sécuriser les failles d’EFAIL. Toutefois, un point commun relie ces vulnérabilités : elles ont généré des pratiques de sécurisation du code. Dans la section suivante, je propose d’analyser ces pratiques de maintenance et innovation qui produisent la sécurité du code au quotidien.

3. Les pratiques de transformation du code, entre maintenance et innovation

35Dans mon analyse des deux vulnérabilités ci-dessus, j’ai insisté sur les objets et discours qui insécurisaient OpenPGP. Ce faisant, j’ai laissé provisoirement dans l’ombre les personnes qui collaboraient étroitement pour prendre soin du code. J’aimerais maintenant me pencher sur le travail des développeur·se·s pour tâcher de répondre à deux questions : quelles sont les pratiques de maintenance et d’innovation mises en œuvre par les codeur·se·s pour sécuriser le code et quelles sont les modalités de collaboration entre les différentes personnes impliquées ?

3.1. Vigilance, soin et modernisation du code

36En tant qu’« objet de sollicitude » [matter of care] (Kocksch et al., 2018), le code ne cesse d’être modifié pour s’adapter aux nouvelles conditions de son existence, comme la découverte de failles ou la nécessité d’ajouter un mécanisme comme l’AEAD. Ces transformations entremêlent deux logiques a priori différentes : celle de la maintenance, composant avec le passé du code, et celle de l’innovation, orientée vers l’avenir. Or, ce que permet la perspective du care est justement de dépasser de telle logique et d’observer comment des temporalités fort différentes peuvent s’entremêler dans les pratiques d’écriture et de réécriture du code informatique dans un « perpétuel recommencement » (Denis & Pontille, 2010). Une porte d’entrée pour comprendre cette dynamique est d’analyser comment les codeur·se·s considèrent leur travail de maintenance du code. Discutant de cela avec l’un·e des employé·e·s de Sequoia, nous avons abordé ses difficultés à comprendre le code de GnuPG avec lequel il lui fallait composer pour avancer dans son propre projet :

C’est très dur d’innover dans OpenPGP à cause de ses vieilleries [old craft] et de ses vieilles idées. Ce sont surtout de vieilles idées. Coder, c’est comme écrire des idées. Si tu réécris un logiciel, tu jettes des idées du passé. Donc de mon point de vue, écrire du code, c’est comme communiquer avec les personnes qui ont écrit avant toi. (Employé·e A de Sequoia, interview du 25 août 2020)

  • 18 La notion de dialogue est encore renforcée quand on considère que chaque codeur·se a son propre sty (...)

37Sa métaphore du code comme médiateur d’une communication asynchrone entre codeur·se·s d’hier et d’aujourd’hui et son insistance sur les vieilles idées sont particulièrement illustratives d’une difficulté majeure : le code hérité du passé, appelé « legacy code » en anglais (*Lopian, 2018), est souvent considéré comme un poids car il est prisonnier d’une infrastructure sur laquelle il est difficile d’intervenir. Or, ce que nous dit cette citation est que le code n’est pas un artefact purement technique et objectif, mais au contraire la traduction d’une idée humaine en langage informatique18. De ce point de vue, maintenir le code, c’est comprendre quelles idées a voulu exprimer le·la developpeur·se dans le passé et adapter ce message au projet-sécurité actuel. Or, la maintenance est rendue d’autant plus ardue que le code se complexifie en vieillissant à cause des multiples transformations qu’il a subies, qui sont autant de couches dont il s’agit de comprendre les raisons d’être. Ce souci d’intelligibilité et de compréhension du code est explicitement exprimé par les développeur·se·s elles·eux-mêmes, par exemple dans les discussions sur GitHub (voir illustration 4).

Illustration 4. Capture d’écran de la page GitHub d’OpenPGP.js. Il s’agit d’une réponse à un·e contributeur·trice sur GitHub qui partageait sa crainte de voir la librairie devenir de plus en plus complexe

Illustration 4. Capture d’écran de la page GitHub d’OpenPGP.js. Il s’agit d’une réponse à un·e contributeur·trice sur GitHub qui partageait sa crainte de voir la librairie devenir de plus en plus complexe

Source : *OpenPGP.js, 2019a.

38Revenons à la citation de l’employé·e A. J’ai maladroitement traduit les mots « old craft » par « vieilleries ». Une meilleure traduction (mais plus lourde) aurait été « ancien artisanat » car cette formulation souligne la manière dont le codage s’identifie à un art manuel qui évolue. Une autre citation permet d’approfondir cette vision de la maintenance du code en tant que savoir-faire manuel. Elle est tirée d’une conversation par email avec un·e autre codeur·se de Sequoia :

[…] il y a en ce moment une discussion sur la liste de diffusion [d’OpenPGP] sur la manière de procéder pour moderniser OpenPGP. Mais le travail ici n’est pas unique : tu dois introduire de nouveaux éléments qui n’étaient pas là quand le vieux protocole OpenPGP a été conçu (par exemple le chiffrement authentifié AEAD) et tu dois commencer à déprécier [deprecating] les mauvaises choses et finalement les supprimer […]. C’est comme si tu maintenais un vélo : tu montes des nouvelles et meilleures pièces, et tu nettoies ce qui s’est accumulé sur les choses [the cruft on things] qui se sont abîmées quand tu l’utilisais. (Employé·e B de Sequoia, email du 22 octobre 2020)

  • 19 « Cruft » signifie, dans le jargon hacker, « anything that is left over, redundant and getting in t (...)

39L’analogie avec la maintenance d’une bicyclette n’est pas anodine et souligne bien l’aspect manuel voire salissant du travail de maintenance. J’aimerais insister ici sur les termes utilisés dans cet extrait : « moderniser », « introduire de nouveaux éléments », « déprécier », « cruft »19, « s’abîmer ». Cette manière de décrire le travail de maintenance souligne le fossé entre le legacy code et le projet-sécurité actuel des développeur·se·s qui discutent des nouvelles spécifications du standard. Aux éléments inutiles, défectueux ou qui font obstacle (« cruft ») s’oppose la modernisation du projet-sécurité qui nettoierait, polirait et huilerait les engrenages rouillés d’une infrastructure vieillissante mais encore fonctionnelle et utile.

40Il faut toutefois noter que le passé d’OpenPGP n’est pas toujours perçu comme négatif, comme l’indique l’extrait suivant qui nuance cette vision du legacy code. Lors de cet entretien, j’ai voulu savoir quelles valeurs un·e employé·e de Sequoia voyait dans OpenPGP alors que beaucoup de voix critiques aimeraient le voir disparaître de l’écosystème d’Internet (*Cryptologinie.net, 2020 ; *Latacora, 2019). Ce·tte codeur·se m’a répondu en insistant sur la valeur que pouvait représenter l’âge du standard :

Être vieux est globalement une bonne propriété pour un système de sécurité dans le sens que cela prouve qu’il suscite de l’intérêt, qu’il répond à un besoin, et qu’il a évolué et continue de le faire. OpenPGP va avoir 30 ans et toutes les primitives cryptographiques qui ont été introduites il y a 30 ont plus ou moins été supprimées. C’est comme un être humain qui voit toutes les cellules de son corps être remplacées sur une période de – je ne sais pas – 10 ans. Je pense que c’est une propriété qui est magnifique : remplacer véritablement toutes les parties et pourtant rester fonctionnel. Et je pense qu’en ce sens, le standard s’est révélé très impressionnant. (Employé·e C de Sequoia, interview du 21 janvier 2021)

41Cet extrait est intéressant à plus d’un titre. D’une part, il insiste sur la valeur que peut donner le temps à un standard de sécurité. D’autre part, cette citation explicite l’intrication entre maintenance et innovation : remplacer toutes les primitives cryptographiques nécessite de (re)construire et de (re)négocier les spécificités du standard en l’alignant sur l’état actuel des connaissances cryptographiques et du contexte informatique. Cela souligne la constante vigilance et l’apprentissage permanent nécessaires à la maintenance. Mais plus important encore, cet extrait souligne que la solidité du standard est le fruit d’un travail humain : la sécurité ne provient pas du fait que le standard soit intrinsèquement bon et qu’il utilise les bons algorithmes, mais du fait que des humains s’y intéressent et le fassent évoluer. La sécurité n’est donc pas donnée, elle est travaillée dans la durée. Elle demande une vigilance à l’égard des nouvelles insécurités comme EFAIL et la CVE-2020-25125, mais également des connaissances à la fois théoriques pour comprendre les problèmes, historiques pour comprendre le legacy code, et techniques pour réussir à bricoler un correctif. Je précise que « bricoler », « to hack », est ici à prendre au sens le plus noble du terme, dans la ligne des pratiques d’improvisation propre au travail du care : « L’ordre des choses, la stabilité des technologies, sont maintenus au jour le jour par des personnes qui traitent les objets au nom de leurs vulnérabilités et prennent soin d’eux » (Denis, 2012 : 181 ; voir aussi Denis & Pontille, 2015 ; Kocksch et al., 2018).

42Ce soin du code nécessite également un important travail de collaboration entre différentes personnes. Les trois citations ci-dessus, malgré des opinions divergentes, s’accordent sur l’idée que ce sont des pratiques collaboratives qui font évoluer le code : dialoguer via le code, négocier à l’IETF, ou simplement intéresser. Regardons comment cela se passe concrètement.

3.2. Le travail collaboratif de soin du code

Je dirais qu’il y a deux aspects [dans le travail de maintenance d’une librairie]. Le premier concerne l’implémentation de nouvelles fonctionnalités et l’autre aspect est peut-être le fait de garder un œil sur GitHub, et essayer de gérer les issues que les personnes créent. (Employé·e A de ProtonMail, interview du 19 août 2019)

43Cette citation provient d’un entretien que j’ai conduit avec un·e codeur·se de ProtonMail qui m’expliquait en quoi consistait son travail quotidien de maintenance de la librairie OpenPGP.js. Devant son ordinateur, nous avons parcouru des dizaines d’échanges qui avaient eu lieu principalement sur GitHub ainsi que sur des canaux IRC ou des chat rooms liées. Cette citation, en plus de souligner une fois de plus que maintenance et innovation sont les deux faces d’une même médaille, relève le rôle crucial des plateformes de collaboration telles que GitHub et GitLab.

44Basées sur le logiciel de version Git, ces plateformes ont pour but non seulement de partager le code, mais également de faciliter la collaboration entre codeur·se·s (Couture, 2012). De plus, chaque proposition de modification du code y laisse une trace sous la forme d’un commit (Geiger & Ribes, 2010). Il est alors intéressant de souligner un paradoxe intéressant : alors que le travail de soin du code passe généralement inaperçu des utilisateur·trice·s et est souvent considéré comme invisible, ces plateformes servent justement à rendre visible et intelligible chaque étape de la transformation du code.

  • 20 Les issues peuvent être assimilées à des questions et commentaires faits par les codeur·se·s ou les (...)

45Ainsi, les commits et issues20 sont une source précieuse d’information pour comprendre comment la sécurité et la stabilité du code sont négociées au quotidien. Il s’agit parfois d’un simple questionnement qui ne demande que quelques clarifications sur certains aspects du code (par exemple *OpenPGP.js, 2019a) ; d’autre fois, ces issues entraînent des modifications importantes du code qui peuvent parfois être dues à des bugs survenus ailleurs dans le code (par exemple. *OpenPGP.js, 2019b). Ces deux exemples montrent un élément crucial : la sécurité n’est ici pas du tout perçue en termes d’attaque et de défense mais selon la logique du soin, où l’entraide et le dialogue entre développeur·se·s priment :

Illustration 5. Capture d’écran d’une issue de la page GitHub de OpenPGP.js. Trois personnes collaborent à propos d’un problème. On notera le caractère cordial, bienveillant et informel de ces échanges.

Illustration 5. Capture d’écran d’une issue de la page GitHub de OpenPGP.js. Trois personnes collaborent à propos d’un problème. On notera le caractère cordial, bienveillant et informel de ces échanges.

Source : OpenPGP.js, 2019b

46D’ailleurs, l’employé·e de ProtonMail cité·e ci-dessus m’a expliqué lors du même entretien comment son travail consistait non seulement à produire du code pour répondre à l’agenda de son entreprise, mais également à aider ses concurrent·e·s à résoudre des problèmes liés à l’utilisation de « sa » librairie :

Cette personne [d’un autre projet] rencontrait des erreurs mais n’était pas sûr pourquoi. […] J’ai alors écrit un code qui a supprimé l’erreur et nous avons commencé à comprendre d’où elle venait. […] Et je le vois bien, dans un sens, c’est juste moi qui essaie de l’aider. Je pense que d’une façon, cela fait partie du travail de maintenir une librairie, juste pour que d’autres personnes aient envie de l’utiliser. […] C’est vrai, ça ne nous est pas directement bénéfique. Mais comme je te l’ai dit avant, nous voulons que les gens supportent l’AEAD, et nous voulons que les gens utilisent notre librairie. Alors c’est sympa de les aider. (Employé·e A de ProtonMail, interview du 19 août 2019)

47La dernière partie de cette citation me semble particulièrement intéressante : pourquoi cet·te employé·e tient à ce que d’autres personnes supportent l’AEAD et utilisent « sa » librairie ? Et pourquoi engager tant d’effort dans ce genre de dialogue ? Il existe bien entendu une réponse purement technique : l’AEAD est ce mécanisme qui permet de pallier certaines des vulnérabilités d’EFAIL et il est techniquement légitime de vouloir qu’il soit pris en charge par un maximum d’implémentations afin de réduire d’autant la surface d’attaque d’EFAIL. Cela dit, il existe une autre réponse d’ordre idéologique : ProtonMail est une librairie open source par choix et non par nécessité. Vouloir que d’autres utilisent son travail ne doit donc pas surprendre. Une fois de plus, ce n’est pas une logique de compétition mais d’entraide qui prévaut dans ce contexte.

48Cet exemple, parmi tant d’autres, illustre bien comment les développeur·se·s collaborent via des vulnérabilités, bugs et autres issues. Ce sont en effet grâce à ces objets qui sont négociés, discutés et, parfois, résolus que les développeur·se·s collaborent. De même, les failles d’EFAIL ont créé un pont entre les scientifiques et les codeur·se·s. Ces vulnérabilités génèrent ce que j’ai appelé le cycle de l’(in)sécurité qui est présenté dans la dernière section de cet article.

Conclusion : le cycle de l’(in)sécurité

49On l’a vu, les multiples instances d’EFAIL dans des contextes fort différents font émerger des temporalités variables, allant d’une intense controverse de quelques jours sur Twitter à la négociation sur plusieurs années des spécificités du standard sur la liste de diffusion de l’IETF, en passant par des pratiques d’écriture et de réécriture du code qui ne s’arrêtent jamais. C’est pourquoi il est très difficile voire impossible d’affirmer avec certitude quelles ont été les conséquences d’EFAIL sur la sécurité du standard OpenPGP et de ses implémentations. Ce qui est possible de faire, en revanche, c’est d’observer ce qu’EFAIL a initié, notamment en regardant comment le code a été transformé et comment cet objet-frontière a créé des ponts entre différentes communautés. Il s’agit en quelque sorte de sortir de la rhétorique de crise afin de mettre en lumière les pratiques routinières de maintenance du code, comme l’a suggéré Denis (2012). Les pratiques de maintenance et d’innovation s’entremêlent, donnant naissance à un cycle où sécurité et insécurité se succèdent perpétuellement. Reprenons l’exemple d’EFAIL et tâchons de mieux cerner cette oscillation constante.

50À l’origine, EFAIL est d’abord un objet qui crée de l’insécurité : la première activité des chercheurs a consisté à rechercher, théoriser et exploiter des failles dans le cadre d’un projet scientifique. Or, s’il est certain que cela crée de l’insécurité, les chercheurs avaient aussi le projet de sécuriser l’écosystème en révélant de manière responsable ces failles aux développeur·se·s afin d’appliquer des correctifs. La révélation publique des failles alors que les correctifs n’avaient pas encore été tous implémentés est quant à elle un événement qui a créé un grand sentiment d’insécurité et la controverse qui a suivi a causé beaucoup d’incertitude du fait des discours contradictoires à propos des failles. À cette spectaculaire insécurisation du code, les développeur·se·s ont répondu plus discrètement par de nombreux correctifs tant au niveau du code que des spécifications du standard à l’IETF. Ces correctifs ont été imaginés, codés, testés et finalement adoptés, ce qui contribue naturellement à sécuriser le code mais aussi, plus étonnant, à l’insécuriser. En effet, ces nouvelles lignes de code ont à leur tour été sources de problèmes, comme l’atteste le cas de la CVE-2020-25125. Au final, plusieurs années après la révélation publique d’EFAIL, ce travail d’écriture et de réécriture du code se poursuit, de même que les négociations dans le groupe de travail d’OpenPGP à l’IETF. Les nouvelles fonctionnalités et les correctifs apportent aussi bien des solutions aux anciens problèmes que de nouveaux problèmes.

  • 21 David Bozzini et moi-même avons commencé à esquisser le concept d’(in)sécurisation dans le cadre du (...)

51L’oscillation entre sécurité et insécurité est donc constante. Aussi, plutôt que d’opposer sécurité et insécurité, il me paraît plus souhaitable de voir le continuum qui les relie et parler ainsi d’(in)sécurité (voir par exemple Kocksch et al., 2018 ; Suchman et al., 2017). Il devient alors possible de parler de « processus d’(in)sécurisation » pour qualifier toute pratique ou discours qui (in)sécurise différents aspects du code (son contenu, son design, les valeurs qu’il incarne, les primitives cryptographiques qu’il utilise) à travers de multiples moyens (recherche scientifique, rapports de bug, commits, critiques) par de multiples acteurs (codeur·se·s, chercheur·se·s, cryptographes, journalistes, hackers)21. La notion de « processus d’(in)sécurisation » permet d’avoir une perspective plus nuancée au sujet des objets, pratiques et discours sécuritaires en soulignant l’ambiguïté entre sécurité et insécurité dont est faite la routine des codeur·se·s interviewé·e·s. Cette analyse nous amène très loin d’une vision purement technique voire mathématique de la sécurité et permet au contraire de souligner la nature relationnelle et situationnelle de la sécurité.

52Cet article montre ainsi comment le code informatique, en tant qu’objet et acteur d’(in)sécurité, est collectivement produit et sans cesse transformé dans un souci constant de vigilance, d’attention et de soin. Le cas d’EFAIL est de ce point de vue très intéressant. En considérant cette série de vulnérabilités comme un objet-frontière à l’interface de plusieurs communautés de pratiques, il est possible d’observer comment EFAIL génère de multiples processus d’(in)sécurisation. EFAIL, qui pour beaucoup est synonyme de quelques jours de crise durant le mois de mai 2018, m’a permis de montrer comment cette controverse ne représente qu’une infime partie des processus d’(in)sécurisation engendrés. Cela a débuté des mois avant la révélation publique et n’est toujours pas entièrement terminé puisque le groupe de travail de l’IETF continue d’en discuter.

53Le spectaculaire fiasco de la révélation publique devient un élément parmi d’autres dans un contexte plus large incluant également des pratiques ordinaires de soin du code. L’étude des processus d’écriture du code en tant qu’actes collaboratifs met alors en exergue les multiples négociations derrière chaque décision prise sur les plateformes de partage de code, via les listes de diffusion, ou au sein des équipes de développement. EFAIL devient alors simultanément un moteur de sécurisation (par exemple l’implémentation de l’AEAD) et d’insécurisation (par exemple en devenant un nouvel argument dans les critiques à l’encontre du standard : *Cryptologinie.net, 2020 ; *Latacora, 2019).

54Finalement, il convient de noter que le projet-sécurité des codeur·se·s, malgré des opinions divergentes, est mené collectivement par un ensemble hétérogène de personnes (codeur·se·s, chercheur·se·s, utilisateur·trice·s et encore journalistes) qui négocient en permanence l’état actuel du code. Dans la poursuite de ce projet, la maintenance devient innovation, par exemple quand il s’agit d’implémenter l’AEAD par défaut afin d’éviter que des vulnérabilités du type d’EFAIL ne se reproduisent ; et l’innovation devient maintenance, par exemple quand une nouvelle technique qui permet de corrompre les données chiffrées (les « malleability gadgets » d’EFAIL) engendre de nombreux correctifs du code. Ainsi, cette quête jamais achevée d’(in)sécurité ôte au code toute possibilité d’être figé et le rend au contraire vulnérable et mouvant.

Haut de page

Bibliographie

Aviram Nimrod, Schinzel Sebastian, Somorovsky Juraj, Heninger Nadia, Dankel Maik, Steube Jens, Shavitt Yuval (2016). « DROWN : Breaking TLS Using SSLv2 »,. Présenté au 25th USENIX Security Symposium (USENIX Security 16), pp. 689-706.

Balzacq Thierry (2011). Securitisation Theory: How Security Problems Emerge and Dissolve. London, New York, Routledge.

Balzacq Thierry & Dunn Cavelty Myriam (2016). « A theory of actor-network for cyber-security », European Journal of International Security, 1 (2), pp. 176-198.

Bensa Alban & Fassin Eric (2002). « Les sciences sociales face à l’événement », Terrain. Anthropologie & sciences humaines, (38), pp. 5-20.

Besençon Sylvain & Bozzini David (2020). « The Ethnography of a Digital Object. An Example From Computer Security », TSANTSA – Journal of the Swiss Anthropological Association, (25), pp. 153-160.

Bialski Paula (2019). « Code Review as Communication: The Case of Corporate Software Developers », Communication, pp. 93-111.

Blanchette Jean-François (2012). Burdens of Proof. Cryptographic Culture and Evidence Law of Electronic Documents. Cambridge, Mass., London, MIT Press.

Bozzini David (2016). « Cryptographie et surveillance digitale », in Bernard Knodel, Marc-Olivier Gonseth, Yann Laville, Grégoire Mayor, & Olivier Schinz, Opacités du patrimoine culturel immatériel. Neuchâtel, Musée d’ethnographie, pp. 276-287.

Bruun Maja Hojer, Andersen Astrid Oberborbeck & Mannov Adrienne (2020). « Infrastructures of trust and distrust: The politics and ethics of emerging cryptographic technologies », Anthropology Today, 36 (2), pp. 13-17.

Buzan Barry, De Wilde Jaap & Waever Ole (1998). Security : a new framework for analysis. Boulder CO etc., Lynne Rienner.

Coleman E.Gabriella & Golub Alex (2008). « Hacker practice: Moral genres and the cultural articulation of liberalism », Anthropological Theory, 8 (3), pp. 255-277.

Couture Stéphane (2012). « L’écriture collective du code source informatique », Revue d’anthropologie des connaissances, Vol. 6, n° 1 (1), pp. 21-42.

Demazière Didier, Horn François & Zune Marc (2011). « Ethnographie de terrain et relation d’enquête. Observer les « communautés » de logiciels libres », Sociologie, 2 (2), pp. 165-183.

Denis Jérôme (2009). « Les ressorts de la sécurité informatique. Des hommes, des machines et des données », in Christian Licoppe, L’évolution des cultures numériques, de la mutation du lien social à l’organisation du travail. Paris, pp. 190-199.

Denis Jérôme (2012). « L’informatique et sa sécurité », Réseaux, n° 171 (1), pp. 161-187.

Denis Jérôme & Kessous Emmanuel (2012). « Le travail ordinaire de la sécurité. Présentation », Réseaux, n° 171 (1), pp. 9-18.

Denis Jérôme & Pontille David (2010). « Performativité de l’écrit et travail de maintenance », Réseaux, n° 163, pp. 105-130.

Denis Jérôme & Pontille David (2015). « Material Ordering and the Care of Things », Science, Technology, & Human Values, 40 (3), pp. 338-367.

Diffie Whitfield & Landau Susan (2010). Privacy on the Line. Cambridge, The MIT Press.

Dunn Cavelty Myriam Dunn (2007). Cyber-security and threat politics: US efforts to secure the information age. Routledge.

Geiger R.Stuart & Ribes David (2010). « The work of sustaining order in wikipedia: the banning of a vandal », in Proceedings of the 2010 ACM conference on Computer supported cooperative work. New York, NY, USA, Association for Computing Machinery, pp. 117-126.

Goldstein Daniel M. (2010). « Toward a Critical Anthropology of Security », Current Anthropology, 51 (4), pp. 487-517.

Gürses Seda, Kundnani Arun & Van Hoboken Joris (2016). « Crypto and empire: the contradictions of counter-surveillance advocacy », Media, Culture & Society, pp. 576-590.

Hansen Lene & Nissenbaum Helen (2009). « Digital Disaster, Cyber Security, and the Copenhagen School », International Studies Quarterly, 53 (4), pp. 1155-1175.

Hellegren Z.Isadora (2017). « A history of crypto-discourse: encryption as a site of struggles to define internet freedom », Internet Histories, 1 (4), pp. 285-311.

Kelty Christopher M. (2008). Two bits : the cultural significance of free software. Durham, N.C., Duke University Press.

Kocksch Laura, Korn Matthias, Poller Andreas & Wagenknecht Susann (2018). « Caring for IT Security: Accountabilities, Moralities, and Oscillations in IT Security Practices », Proceedings of the ACM on Human-Computer Interaction, 2 (CSCW), pp. 92:1-92:20.

Korn Matthias & Wagenknecht Susann (2017). « Friction in Arenas of Repair: Hacking, Security Research, and Mobile Phone Infrastructure », in Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing. Portland, Oregon, USA, Association for Computing Machinery, pp. 2475-2488.

Lave, Jean & Wenger Étienne, Situated Learning: Legitimate Peripheral Participation. Cambridge: Cambridge University Press, 1991.

Leigh Star Susan (2010). « This is Not a Boundary Object: Reflections on the Origin of a Concept », Science, Technology, & Human Values, 35 (5), pp. 601-617.

Levy Steven (2001). Crypto: How the Code Rebels Beat the Government Saving Privacy in the Digital Age. New York, Penguin Books.

Low Setha M. & Maguire Mark (2019). Spaces of security : ethnographies of securityscapes, surveillance, and control. New York, New York University Press.

Macleod Alex (2004). « Les études de sécurité : du constructivisme dominant au constructivisme critique », Cultures et Conflits, (54), pp. 13-51.

Maguire Mark, Fróis Catarina & Zurawski Nils (2014). The anthropology of security : perspectives from the frontline of policing, counter-terrorism and border control. London, Pluto Press.

Marino Mark C. (2020). Critical Code Studies. Cambridge, MA, MIT Press.

Méadel Cécile & Sire Guillaume (2017). « Les sciences sociales orientées programmes », Reseaux, n° 206 (6), pp. 9-34.

Nora Pierre (1974). « Le retour de l’événement », Faire de l’histoire, 1, pp. 210-228.

Poddebniak Damian, Dresen Christian, Müller Jens, Ising Fabian, Schinzel Sebastian, Friedberger Simon, Schwenk Jörg (2018). « Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels »,. Présenté à 27th USENIX Security Symposium, Baltimore, pp. 549-566.

Puig de la Bellacasa Maria (2010). « Matters of care in technoscience: Assembling neglected things: », Social Studies of Science.

Raymond Eric S. (2001). The cathedral and the bazaar musings on Linux and Open Source by an accidental revolutionary. Beijing, O’Reilly.

Roitman Janet Lee (2014). Anti-crisis. Durham, Duke University Press.

Ruh Nicolai (2018). « Trusting the Math and Mistrusting Humans. How Politically Sensitized Engineers of Cryptographic Systems Cope with Ontological Insecurity in the Digitally Augmented Life-World », in Florian Mühlfried, Mistrust. Ethnographic Approximations. Bielefield, transcript Verlag, pp. 23-48.

Saco Diana (1999). « Colonizing Cyberspace:‘National Security’and the Internet », in Jutta Weldes, Mark Laffey, Hugh Gusterson, & Raymond Duvall, Cultures of insecurity: States, communities, and the production of danger. Minneapolis, London, University of Minnesota Press, Vol. 14, pp. 261-292.

Schneier Bruce (1997). « Why cryptography is harder than it looks », in EDI FORUM-OAK PARK-. THE EDI GROUP, LTD., Vol. 10, pp. 87-90.

Spencer Matt (2021). « Creative Malfunction: Finding fault with Rowhammer », Computational Culture, (8).

Star Susan Leigh & Griesemer James R. (1989). « Institutional Ecology, `Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39 », Social Studies of Science, 19 (3), pp. 387-420.

Suchman Lucy, Follis Karolina & Weber Jutta (2017). « Tracking and Targeting: Sociotechnologies of (In)security », Science, Technology, & Human Values, 42 (6), pp. 983-1002.

Trompette Pascale & Vinck Dominique (2009). « Retour sur la notion d’objet-frontière », Revue d’anthropologie des connaissances, Vol. 3, n° 1 (1), pp. 5-27.

von Krogh Georg, Spaeth Sebastian & Lakhani Karim R. (2003). « Community, joining, and specialization in open source software innovation: a case study », Research Policy, 32 (7), pp. 1217-1241.

West Sarah Myers (2018). « Cryptographic imaginaries and the networked public », Internet Policy Review, 7 (2).

Haut de page

Annexe

Sources ethnographiques

Tous les liens ont été vérifiés le 29 octobre 2021.

Brandom, 2014 : https://www.theverge.com/​2014/​12/​28/​7458159/​encryption-standards-the-nsa-cant-crack-pgp-tor-otr-snowden

Brinkmann, 2018 : https://mailarchive.ietf.org/​arch/​msg/​openpgp/​t79iRZ80KHuVTEyVVLAoCLl4Rwc

Bugzilla, 2020 : https://bugzilla.suse.com/​show_bug.cgi?id=1176034#c5

Cryptologinie.net, 2020 : https://www.cryptologie.net/​article/​487/​a-history-of-end-to-end-encryption-and-the-death-of-pgp

CVA, 2019 : https://cva.unifr.ch/​content/​trajectory-vulnerability-named-efail

CVA, 2021 : https://cva.unifr.ch/​content/​la-carri%C3%A8re-dopenpgp-%C3%A0-lietf

EFAIL, 2018 : https://efail.de

EFF, 2018 : https://www.eff.org/​deeplinks/​2018/​05/​attention-pgp-users-new-vulnerabilities-require-you-take-action-now

GitHub, OpenPGP.js : https://github.com/​openpgpjs/​openpgpjs

GitLab, Sequoia : https://gitlab.com/​sequoia-pgp/​sequoia

GitLab, RFC4880bis : https://gitlab.com/​openpgp-wg/​rfc4880bis

GnuPG, GIT : https://git.gnupg.org/​cgi-bin/​gitweb.cgi?p=gnupg.git

GnuPG, 2020a : https://lists.gnupg.org/pipermail/gnupg-announce/2020q3/000446.html ; voir aussi https://dev.gnupg.org/​T4897

GnuPG, 2020b : https://dev.gnupg.org/​T5045

GnuPG, 2020c : https://dev.gnupg.org/​T5050

GnuPG-Users : https://lists.gnupg.org/​mailman/​listinfo/​gnupg-users

Google, 2015 : https://googleprojectzero.blogspot.com/​2015/​02/​feedback-and-data-driven-updates-to.html

Hannob, 2020 : https://github.com/​hannob/​pgpbugs

Hansen, 2018 : https://lists.gnupg.org/​pipermail/​gnupg-users/​2018-May/​060334.html

IETF, OpenPGP : https://www.ietf.org/​mailman/​listinfo/​openpgp

Koch, 2018 : https://lists.gnupg.org/​pipermail/​gnupg-users/​2018-May/​060315.html

Koch, 2020a : https://dev.gnupg.org/​rGaeb8272ca8aad403a4baac33b8d5673719cfd8f0

Latacora, 2019 : https://latacora.singles/​2019/​07/​16/​the-pgp-problem.html

Lopian, 2018 : https://dzone.com/​articles/​defining-legacy-code

Marlinspike, 2018 : https://media.ccc.de/​v/​36c3-11086-the_ecosystem_is_moving

Mitre, 2020 : https://cve.mitre.org/​cgi-bin/​cvename.cgi?name=CVE-2020-25125

Müller, 2018 : https://twitter.com/​jensvoid/​status/​995966114466234369

OpenPGP, 2021 : https://mailarchive.ietf.org/​arch/​msg/​openpgp/​9uPRgtbWMQZoho-AfxdBlSpGPZc

OpenPGP-DT, 2021 : https://mailarchive.ietf.org/​arch/​msg/​openpgp-dt/​3tnIRWJ0UT6JLdjlIVJyioOvwgI

OpenPGP.js, 2019a : https://github.com/​openpgpjs/​openpgpjs/​issues/​916

OpenPGP.js, 2019b : https://github.com/​openpgpjs/​openpgpjs/​issues/​924

Ptacek, 2018 : https://cva.unifr.ch/​content/​unified-timeline-efail-pgp-disclosure-events

Peterson, 2014 : https://www.washingtonpost.com/​news/​the-switch/​wp/​2014/​05/​14/​edward-snowden-sent-glenn-greenwald-this-video-guide-about-encryption-for-journalists-greenwald-ignored-it

ProtonMail, 2018 : https://protonmail.com/​blog/​pgp-vulnerability-efail

RFC 1991 : https://tools.ietf.org/​html/​rfc1991

RFC 2440 : https://tools.ietf.org/​html/​rfc2440

RFC 4880 : https://tools.ietf.org/​html/​rfc4880

Schinzel, 2018 : https://twitter.com/​seecurity/​status/​995906576170053633

Sequoia, 2021 : https://tests.sequoia-pgp.org

RFC 4880bis : https://datatracker.ietf.org/​doc/​draft-ietf-openpgp-rfc4880bis

Twitter, 2018 : https://twitter.com/​ADHSjoe/​status/​996090542751657984

Wikipédia, Cruft : https://en.wikipedia.org/​wiki/​Cruft

Wired, 2018 : https://www.wired.co.uk/​article/​efail-pgp-vulnerability-outlook-thunderbird-smime

Zimmermann, 1999 : https://www.philzimmermann.com/​EN/​essays/​index.html

Haut de page

Notes

1 La science est un processus collectif. Je tiens à remercier chaleureusement les codeur·se·s qui m’ont accueilli dans leur quotidien, partagé leurs connaissances et donné leur temps. Je remercie également. les relecteur·trice·s anonymes de RESET, les coordinateurs de ce numéro Gabriel Alcaras et Antoine Larribeau, ainsi que David Bozzini, Francesca Musiani, Estelle Pannatier, Nina Khamsy et Jean Ceppi pour leurs stimulantes remarques et suggestions.

2 L’IETF est un organisme de standardisation des protocoles internet, notamment la suite de protocoles internet TCP/IP. Il s’agit d’un organisme ouvert sans critère d’adhésion et tous les participant·e·s sont des bénévoles. Les participant·e·s se réunissent trois fois par année lors d’une réunion de sept jours et, le reste du temps, communiquent au travers de listes de diffusion.

3 Les références précédées d’un astérisque renvoient aux sources ethnographiques issues de mon terrain en ligne. Les liens sont présentés dans la section 6. « Sources ethnographiques », après la bibliographie.

4 Pour un historique des différentes versions du standard à l’IETF, voir (*CVA, 2021).

5 Si n’importe qui a la possibilité d’envoyer des questions ou commentaires sur la liste de diffusion du groupe de travail (*IETF, OpenPGP), le haut niveau de technicité des échanges font que seules les personnes les plus familières avec le standard contribuent aux discussions. Depuis l’été 2021, une design team a été élue pour simplifier les négociations d’une nouvelle version du standard (*OpenPGP, 2021).

6 Chiffrer un message correspond à en protéger le contenu grâce à des opérations mathématiques qui le rendent illisible pour quiconque n’en détient pas la clé. Déchiffrer est le processus inverse, possible seulement avec la clé de déchiffrement. Signer un message correspond à l’authentifier en effectuant une opération mathématique que seule la personne qui détient la clé privée peut réaliser mais que tout le monde peut vérifier.

7 Voir par exemple la liste de diffusion des utilisateur·trice·s de GnuPG (*GnuPG-Users).

8 Plusieurs personnes m’ont également assuré que je faisais aussi partie de cette communauté en tant que chercheur l’analysant.

9 Non seulement, le tutoriel de 12 minutes posté sur Vimeo par anon108 en janvier 2013 a été attribué à Edward Snowden (*Peterson, 2014), mais les documents qu’il a révélés semblent indiquer qu’OpenPGP restait inviolée par la NSA en 2013 (*Brandom, 2014).

10 Une liste complète des implémentations d’OpenPGP peut être consultée sur le site internet du standard : https://www.openpgp.org/software/ (consulté le 29 octobre 2021).

11 CVE est l’abréviation de « Common Vulnerability and Exposure », le registre le plus utilisé pour traquer les vulnérabilités informatiques publiquement connues.

12 TLS est un autre standard de l’IETF qui est utilisé pour sécuriser une connexion entre deux serveurs. Nous l’utilisons des dizaines de fois par jour : il s’agit notamment du « s » de « https » (pour plus de détails, voir Aviram et al., 2016).

13 Tous les entretiens cités dans cet article ont été menés en anglais et toutes les citations sont le fruit de ma traduction.

14 Il ne me semble pas nécessaire de saisir les détails techniques des vulnérabilités d’EFAIL pour la compréhension du présent article. Toutefois, certaines personnes seront peut-être curieuses de consulter le site internet dédié à l’explication de la vulnérabilité (*EFAIL, 2018) ainsi que l’article des chercheurs (Poddebniak et al., 2018).

15 Un consensus existe à propos d’un délai de 90 jours qui laisserait suffisamment de temps aux développeur·se·s pour trouver un correctif (voir par exemple *Google, 2015).

16 L’AEAD est l’acronyme de authenticated encryption with associated data : il s’agit d’un mécanisme qui permet de vérifier l’intégrité des données chiffrées.

17 « Le commit est un acte informatique qui consiste à valider formellement une modification du code source d’un logiciel » (Couture, 2012 : 23). Chaque commit est généralement accompagné d'un commentaire qui permet de comprendre la modification en question.

18 La notion de dialogue est encore renforcée quand on considère que chaque codeur·se a son propre style qui peut être reconnu par d’autres personnes (Bialski, 2019).

19 « Cruft » signifie, dans le jargon hacker, « anything that is left over, redundant and getting in the way. It is used particularly for defective, superseded, useless, superfluous, or dysfunctional elements in computer software » (* Wikipédia, Cruft).

20 Les issues peuvent être assimilées à des questions et commentaires faits par les codeur·se·s ou les utilisateur·trice·s à propos du fonctionnement du code. Il peut s'agir de questions, d’un rapport de bugs ou d'une demande de fonctionnalité.

21 David Bozzini et moi-même avons commencé à esquisser le concept d’(in)sécurisation dans le cadre du projet de recherche Windows Exposure: toward an anthropology of computer (in)security, dirigé par David Bozzini et financé par le Fonds National Suisse de la recherche scientifique. La description du projet peut être consultée dans la base de donnée du FNS: http://p3.snf.ch/project-183223 (consulté le 29 octobre 2021).

Haut de page

Table des illustrations

Titre Illustration 1. Les deux premiers tweets du thread du Professeur Sebastian Schinzel annonçant la découverte d’une série de vulnérabilités critiques dans OpenPGP et renvoyant au blog d’EFF.
Crédits Source : *Schinzel, 2018.
URL http://journals.openedition.org/reset/docannexe/image/3539/img-1.png
Fichier image/png, 71k
Titre Illustration 2. Exemple de critiques à la suite de la révélation publique d’EFAIL, capture d’écran sur Twitter
Crédits Source : Twitter, Mai 2018
URL http://journals.openedition.org/reset/docannexe/image/3539/img-2.png
Fichier image/png, 179k
Titre Illustration 3. Capture d’écran du commit aeb8272ca8aa sur la plateforme GIT de GnuPG. On remarque que seule la ligne 2484 du code a été modifiée pour corriger cette vulnérabilité sévère.
Crédits Source : *Koch, 2020a
URL http://journals.openedition.org/reset/docannexe/image/3539/img-3.png
Fichier image/png, 58k
Titre Illustration 4. Capture d’écran de la page GitHub d’OpenPGP.js. Il s’agit d’une réponse à un·e contributeur·trice sur GitHub qui partageait sa crainte de voir la librairie devenir de plus en plus complexe
Crédits Source : *OpenPGP.js, 2019a.
URL http://journals.openedition.org/reset/docannexe/image/3539/img-4.png
Fichier image/png, 59k
Titre Illustration 5. Capture d’écran d’une issue de la page GitHub de OpenPGP.js. Trois personnes collaborent à propos d’un problème. On notera le caractère cordial, bienveillant et informel de ces échanges.
Crédits Source : OpenPGP.js, 2019b
URL http://journals.openedition.org/reset/docannexe/image/3539/img-5.png
Fichier image/png, 107k
Haut de page

Pour citer cet article

Référence électronique

Sylvain Besençon, « (Dé)coder la sécurité de l’information entre maintenance et innovation : le cas d’OpenPGP  »RESET [En ligne], 11 | 2022, mis en ligne le 14 avril 2022, consulté le 14 août 2022. URL : http://journals.openedition.org/reset/3539 ; DOI : https://doi.org/10.4000/reset.3539

Haut de page

Auteur

Sylvain Besençon

ISSR, Université de Fribourg, Suisse

Haut de page

Droits d’auteur

Tous droits réservés

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search