Introduction 

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

• 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é

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

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.

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).

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.

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

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)

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)

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.

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.

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.