La fin d'une époque. Skype ferme définitivement ses portes.
Que se passe-t-il lorsque vous appuyez sur ce bouton d'appel bleu lumineux ? Pour la plupart des utilisateurs de Skype, qui se comptaient autrefois par centaines de millions, cette question n'a jamais traversé l'esprit. La magie opérait. Une connexion s'est formée à travers les continents, les pare-feu, les systèmes de sécurité des entreprises, offrant une communication cryptée limpide lorsque d'autres technologies échouaient.
Mais pour certains d'entre nous, ces boîtes noires de la technologie sont des énigmes irrésistibles qui ne demandent qu'à être résolues.
L'homme derrière le clavier
“Qu'est-ce que vous faites en réalité ? C'est une question à laquelle j'ai été confronté un nombre incalculable de fois, même de la part de membres de ma famille, et à laquelle je peux rarement répondre de manière exhaustive.
Certains d'entre vous me connaissent peut-être grâce à mon travail sur la Cicada 3301 puzzles en 2012-Ces mystères cryptiques de l'internet qui ont captivé les esprits les plus brillants du monde. D'autres me reconnaîtront peut-être pour mes recherches sur la sécurité menées en public : j'ai parlé des techniques d'exploitation du noyau à BlackHat et Defcon, j'ai présenté “Hacking the Hacker” à la conférence RSA, ou j'ai peut-être participé à un documentaire de Netflix sur le piratage d'Ashley Madison, dans lequel j'ai dirigé l'enquête technique.
Mon équipe et moi-même avons parcouru le monde pour participer aux finales de compétitions internationales de piratage informatique, de Codegate en Corée du Sud à DefCamp en Roumanie et Defcon à Las Vegas. J'ai refusé plus d'occasions de parler que je ne peux m'en souvenir.
Mais ces entreprises publiques, aussi stimulantes qu'elles puissent paraître, ont toujours été un jeu d'enfant par rapport aux projets auxquels j'ai participé et qui mettaient en jeu des questions de sécurité nationale. Ce travail - le travail vraiment passionnant - reste largement classifié, n'existant que sous forme de sections expurgées dans des rapports invisibles.
L'importance de ce travail caché n'est pas passée inaperçue aux yeux des adversaires. Il y a quelques années, j'ai été la cible de pirates informatiques parrainés par l'État nord-coréen, non pas une mais deux fois, au cours de leurs campagnes coordonnées contre les chercheurs en sécurité à la fin de 2020 et à nouveau en 2021. Heureusement, ces deux tentatives se sont avérées vaines.
Ce que je m'apprête à partager est un rare aperçu de cet autre monde, celui qui existe dans l'ombre de la technologie. À l'instar de Cicada 3301, ce voyage a comporté de nombreux niveaux, rebondissements et virages. Toutefois, contrairement à ces énigmes, ce défi a exigé beaucoup plus de compétences techniques et de persévérance, avec des implications dans le monde réel qui vont bien au-delà de la curiosité intellectuelle.
Pour des raisons évidentes, de nombreux détails doivent rester secrets. Mais ce qui suit est peut-être la réponse la plus proche que je puisse fournir à cette question persistante : “Qu'est-ce que vous faites réellement ?”
Premier contact
En 2004, Skype était révolutionnaire : un système de communication qui semblait défier les règles conventionnelles de la mise en réseau. Il pouvait établir des connexions entre des ordinateurs qui n'auraient pas dû pouvoir se joindre, il promettait un cryptage que personne ne pouvait briser et il gardait ses secrets derrière des couches de protection sophistiquées.
C'était top secret, mais à ce stade, je suppose que cela n'a plus vraiment d'importance. Du moins, pas lorsqu'il s'agit des aspects techniques liés à la raison pour laquelle je suis devenu très intimement familier avec Skype.
J'ai commencé à faire de la rétro-ingénierie sur Skype en 2004, il y a un peu plus de 20 ans. La société disposait d'un protocole propriétaire prétendument crypté et utilisait diverses techniques pour compliquer considérablement la vie de ceux qui voulaient y jeter un coup d'œil.
Ce qui m'a attiré chez Skype, ce n'est pas seulement la curiosité technique. Il y avait quelque chose de presque provocateur dans la façon dont ils avaient verrouillé leur système, comme s'ils lançaient un défi à ceux d'entre nous qui pensent que la compréhension du fonctionnement de notre technologie est un droit fondamental. Dans un monde de plus en plus construit sur des systèmes fermés, Skype représentait une forteresse de code à laquelle des millions de personnes confiaient leurs communications les plus privées sans savoir ce qui se passait sous la surface.
Chaque fois que j'entendais la sonnerie caractéristique de Skype, je ne pouvais m'empêcher de me demander ce qui se passait réellement derrière cette interface conviviale. Quels mécanismes étaient à l'œuvre pour faire circuler les voix et les messages à travers l'étendue numérique ? Et, ce qui est peut-être le plus important, était-ce aussi sûr que tout le monde le croyait ?
J'étais loin de me douter qu'en tirant sur ce fil, je découvrirais une tapisserie technologique plus complexe et plus ingénieuse que je ne l'avais imaginé. Une tapisserie qui allait nécessiter d'innombrables heures d'exploration pendant des années, me conduisant au cœur de ce qui était alors le système de communication peer-to-peer le plus sophistiqué au monde.
Voici comment j'ai percé l'un des secrets les mieux gardés d'Internet, une instruction d'assemblage à la fois.
Franchir la première couche
Ma première rencontre avec les composants internes de Skype m'a donné l'impression d'ouvrir une poupée russe. Chaque couche révélait un autre défi plus complexe.
Comme pour la plupart des logiciels protégés, les défenses extérieures de Skype se présentent sous la forme d'un “ packer ” personnalisé, un programme qui compresse et crypte le code exécutable réel et ne se déploie qu'au moment de l'exécution. Il s'agit d'un camouflage numérique conçu pour déjouer les regards curieux comme le mien.
L'empaqueteur a utilisé du code auto-modifiant, une technique dans laquelle le programme réécrit littéralement des parties de lui-même pendant qu'il s'exécute. C'est comme un document qui change de contenu au moment où vous essayez de le lire - élégant mais frustrant pour quelqu'un qui essaie de comprendre ce qu'il contient.
Heureusement, ce premier gardien avait une faiblesse. En définissant un point d'arrêt matériel (une instruction spéciale qui interrompt l'exécution à un moment précis sans modifier le code), j'ai pu attendre patiemment que le processus de déballage s'achève. Une fois que Skype s'est entièrement “déballé” dans la mémoire, je peux extraire le code et les segments de données désormais décryptés pour les analyser.
Le coffre-fort numérique s'était ouvert juste assez pour qu'on puisse y jeter un coup d'œil. J'ai transféré le vidage de la mémoire vers IDA Pro, le désassembleur standard de l'industrie à l'époque. Nous étions en 2004, et je me trouvais donc face à du code assembleur brut, le langage le plus fondamental que parlent les ordinateurs. Il n'y a pas de traduction pratique vers des langages de programmation de niveau supérieur, ni d'abstractions utiles. Il ne s'agissait que d'instructions brutes, énigmatiques et nombreuses.
Ce qui aurait dû être un moment de triomphe a rapidement fait place à une prise de conscience qui donne à réfléchir. Le binaire propre et décrypté révélait un obscurcissement sélectif mais sophistiqué. Si la majeure partie du code était “lisible” avec un peu de patience, certaines sections critiques - précisément les plus intéressantes - étaient protégées par des couches de confusion délibérée.
Les développeurs avaient utilisé des techniques telles que des prédicats opaques et des instructions qui se chevauchaient, ce qui aurait fait échouer les désassembleurs linéaires, qui auraient mal interprété ce qui était du code et ce qui était des données. Les centaines de fonctions impliquées dans les opérations cryptographiques étaient particulièrement bien protégées, ce qui témoigne de leur importance.
La nature même du C++ - un labyrinthe d'appels indirects, de tables de fonctions virtuelles et de hiérarchies d'objets complexes - est venue s'ajouter au défi. Pour déterminer quelles méthodes appartenaient à quelles classes et ce que représentait chaque champ de leur structure, il fallait tracer d'innombrables chemins d'exécution dans ce paysage délibérément confus.
Il ne s'agissait pas d'un simple logiciel, mais d'un logiciel conçu par des personnes qui s'attendaient à ce que quelqu'un comme moi vienne y jeter un coup d'œil. Et ils avaient délibérément fortifié les parties les plus précieuses de leur forteresse numérique.
Alors que je parcourais des milliers d'instructions d'assemblage, le message est devenu clair : l'emballeur n'était qu'un simple portier. Les véritables gardiens des secrets de Skype se trouvaient à l'intérieur, et ils surveillaient chacun de mes mouvements.
Mais ce n'était que le début...
Au fond du trou du lapin
La coque extérieure de Skype étant fissurée, je me suis aventuré plus profondément dans son labyrinthe numérique. J'ai découvert un système de sécurité qui ne se contente pas de protéger, mais qui se défend activement.
Comme tout explorateur prudent, j'ai apporté mon outil préféré : un débogueur, un logiciel qui vous permet d'interrompre l'exécution du code et d'examiner son état. Mais Skype avait anticipé cette approche. Il était truffé de mesures anti-débogage, de fils de fer numériques conçus pour détecter et contrecarrer les outils d'analyse.
La plupart de ces contre-mesures étaient classiques dans le monde de la protection des logiciels - ennuyeuses mais gérables. Mais j'ai ensuite rencontré quelque chose de bien plus sophistiqué : des centaines de contrôles d'intégrité polymorphes obfusqués disséminés dans le code.
Imaginez des pièges qui non seulement détectent que vous les avez dérangés, mais qui changent activement d'apparence après chaque rencontre. Ces contrôles vérifient en permanence que le code de Skype n'a pas été modifié, en effectuant des sommes de contrôle sur différentes parties du programme. Dès que j'essayais de modifier quoi que ce soit, même en plaçant temporairement un point d'arrêt, le programme se plantait de façon spectaculaire.
Ce qui rendait ces contrôles d'intégrité particulièrement sournois, c'était leur conception. Lorsque l'un d'eux se déclenchait, il ne se contentait pas d'afficher un message d'erreur. Au lieu de cela, le programme continuait à fonctionner avec des données corrompues, provoquant un crash ailleurs, loin du point d'altération réel. L'équivalent numérique d'une mine à retardement.
Plus insidieux encore : chaque contrôle ne se contentait pas de vérifier l'intégrité du code - il utilisait le résultat de la somme de contrôle comme une valeur réelle dans les opérations suivantes. Cela signifie que je ne pouvais pas simplement désactiver les contrôles ; je devais les remplacer par un code qui produisait exactement les valeurs attendues.
Après avoir découvert et corrigé un contrôle, un autre se déclenchait. Puis un autre. Et encore un autre. Des centaines de ces bâtards polymorphes obfusqués étaient disséminés dans le code, et les traiter un par un prendrait un temps fou. Il s'agissait d'un scénario classique de type "Whack-a-Mole", sauf que la manipulation de chaque taupe nécessitait une précision chirurgicale.
Je devais passer à la vitesse supérieure. Oubliez le jeu Whack-a-Mole, j'allais le faire à la manière des Pokémon : Il faut tous les attraper !
J'ai créé un outil spécialisé - un désassembleur minimal couplé à un minuscule émulateur - conçu spécifiquement pour reconnaître et neutraliser ces contrôles. Au lieu de traiter toutes les instructions possibles du processeur, j'ai soigneusement cartographié et implémenté uniquement le sous-ensemble spécifique d'instructions utilisées dans les contrôles d'intégrité. En identifiant les schémas distinctifs de ces instructions, j'ai pu analyser automatiquement l'ensemble de la section de code, émuler chaque contrôle pour déterminer la sortie attendue et la remplacer par une instruction simple qui fournit la valeur requise.
C'était comme créer un vaccin contre le système immunitaire de Skype, lui apprendre à accepter ma présence sans déclencher ses défenses.
Mon outil a fonctionné à merveille. D'un seul coup, il a neutralisé des centaines de contrôles d'intégrité, remplaçant le code de vérification complexe par de simples affectations de valeurs. Non seulement je pouvais désormais déboguer le programme librement, mais je pouvais également injecter mon propre code pour observer et manipuler le fonctionnement interne de Skype.
De plus, comme j'avais gardé l'outil si ciblé et efficace, il était suffisamment petit pour être ensuite incorporé directement dans les charges utiles des exploits pour les correctifs en mémoire, et pas seulement pour la modification statique des binaires.
Les barrières de protection sont tombées, révélant le niveau suivant du labyrinthe : le protocole propriétaire et le système cryptographique de Skype. Un autre mystère qui attend d'être élucidé.
L'art de l'archéologie numérique
Une fois les protections de Skype neutralisées, la véritable archéologie a commencé. Tel un explorateur découvrant une civilisation ancienne, je devais reconstituer le fonctionnement de ce monde numérique en examinant ses artefacts.
Les rétroingénieurs modernes disposent d'un luxe que je n'avais pas en 2004 : des décompilateurs sophistiqués qui transforment le code machine en langages de programmation lisibles. À l'époque, le processus était beaucoup plus manuel : il s'agissait de traduire les instructions d'assemblage en concepts de plus haut niveau, ligne par ligne, en reconstruisant des structures de données complexes et en cartographiant les relations entre les fonctions.
C'est comme si on vous remettait un livre écrit dans une langue morte où chaque mot peut représenter un concept entier, et vous devez reconstruire non seulement le texte, mais aussi la grammaire et le contexte culturel qui le sous-tendent.
Quelques années plus tard, lorsque la première version du décompilateur Hex-Rays a été publiée pour IDA Pro, j'ai eu l'honneur d'être l'un des bêta-testeurs de la préversion. Cela a changé la donne pour la communauté de la rétro-ingénierie : ce qui prenait des jours pouvait soudain être réalisé en quelques heures. J'étais absolument ravi : c'était comme si on me remettait une pierre de Rosette après des années de traduction manuelle. Mais en 2004, de tels outils n'étaient encore qu'un rêve.
Les outils standard n'allaient pas suffire. J'avais besoin d'un outil spécialement conçu pour les particularités de Skype. J'ai donc créé non pas un, mais deux débogueurs Skype personnalisés, l'un pour Windows et l'autre pour Linux, des outils conçus pour répondre à mes questions spécifiques tout en naviguant dans le code labyrinthique de Skype.
Mon approche était méthodique. Tout d'abord, j'ai injecté des crochets dans toutes les fonctions de journalisation internes de Skype, un code qui redirigeait ces fonctions vers mon propre code. Cela a révélé des messages qui n'étaient pas censés être vus, des informations de débogage que les développeurs avaient laissées derrière eux. La version Linux de Skype s'est avérée particulièrement utile, car elle contient une journalisation plus verbeuse que son homologue Windows.
Ces outils personnalisés m'ont donné une visibilité sans précédent. Je pouvais :
- Suivre les appels de fonction avec des crochets de trampoline en ligne, en les redirigeant vers mon propre code
- Manipuler les paramètres et les valeurs de retour pour tester les hypothèses
- Intercepter les appels de bibliothèques externes avec les techniques LD_PRELOAD ou IAT-patching
- Définir des points d'arrêt ciblés pour examiner ou manipuler les registres et le contenu de la mémoire à des moments précis
Chaque fois que j'ai élargi ma panoplie d'outils, j'ai acquis de nouvelles connaissances. Chacune d'entre elles a donné lieu à de nouvelles questions, qui ont débouché sur de nouveaux outils, créant ainsi un cercle vertueux de découvertes.
Mais il ne s'agissait pas seulement de regarder les rouages tourner. Mon objectif était global : documenter le protocole utilisé par Skype, comprendre ses primitives cryptographiques et, enfin, interagir avec le réseau Skype de manière indépendante.
Au fur et à mesure que je comprenais mieux, ma carte de la structure interne de Skype s'est développée. Fonction par fonction, structure de données par structure de données, je reconstruisais le plan d'un système qui n'avait jamais été documenté publiquement. Chaque pièce du puzzle révélait un peu plus le tableau d'ensemble : comment Skype connectait les utilisateurs sur Internet, contournait les pare-feu et sécurisait les communications.
Les techniques que je développais se sont révélées particulièrement précieuses à des stades ultérieurs de mon enquête. Par exemple, j'ai découvert par la suite qu'il était relativement simple d'analyser le tas de mémoire de Skype à la recherche de clés AES étendues - les clés cryptographiques utilisées pour les communications sécurisées - en raison de leurs schémas distinctifs. Cela s'est avéré crucial lorsque j'ai eu besoin d'intercepter des conversations supposées sécurisées.
Je ne me contentais plus de regarder par le trou d'une serrure, je marchais dans les couloirs de l'architecture de Skype, ouvrant des portes qui étaient censées rester fermées.
Moments de rupture
Plus je m'aventurais dans l'architecture de Skype, plus je faisais des découvertes fascinantes. Chaque découverte me donnait l'impression de résoudre une boîte de puzzle qui en révélait une autre, plus complexe, à l'intérieur.
J'ai fait une révélation cruciale en découvrant comment Skype chiffrait sa couche de signalisation, c'est-à-dire le trafic entre les utilisateurs et les supernodes, et entre les supernodes eux-mêmes. Contrairement au chiffrement de bout en bout utilisé pour les appels et les messages, cette couche utilise RC4, un chiffrement en continu dont les faiblesses sont connues. Plus intéressant encore, la manière dont les clés RC4 étaient générées.
Plutôt que d'utiliser un échange de clés approprié, Skype a obtenu les clés par le biais d'un algorithme déterministe mais fortement obscurci. Le processus commence par une graine aléatoire de 32 bits envoyée par le supernode de réception. Cette graine était introduite dans des centaines de petites fonctions obscurcies qui effectuaient chacune diverses opérations bituelles et arithmétiques sur une mémoire tampon de clé.
La difficulté réside dans le fait que le flux d'exécution lui-même, c'est-à-dire les fonctions appelées et l'ordre dans lequel elles le sont, dépend de la valeur de la graine. Il n'était donc pas possible de créer simplement une représentation aplatie des opérations qui fonctionneraient pour n'importe quelle graine. Le parcours de l'algorithme à travers ces fonctions changeait dynamiquement en fonction de l'entrée, créant un labyrinthe où les murs eux-mêmes se déplaçaient avec chaque nouvelle graine.
La complexité était déconcertante. Bien que j'aie fini par procéder à une rétro-ingénierie de l'ensemble de l'algorithme - en cartographiant chaque fonction et chaque flux de contrôle - il s'agissait d'un processus graduel d'analyse minutieuse qui prenait beaucoup de temps. Mais je n'ai pas eu besoin d'attendre d'avoir une vue d'ensemble pour faire des progrès significatifs. Au fur et à mesure que j'avançais vers une compréhension totale, j'ai créé ce que j'ai appelé un “oracle de clé RC4”, un service qui prendrait une graine de 32 bits en entrée et renverrait la clé RC4 complète en appelant la fonction de dérivation de clé réelle à partir du binaire Skype d'origine.
Cet oracle est devenu la base de ma prochaine percée : un plugin personnalisé pour Ethereal (aujourd'hui connu sous le nom de Wireshark), l'analyseur de protocole réseau. Grâce à ce plugin, j'ai pu décrypter et analyser en temps réel l'ensemble du trafic de signalisation sur le réseau Skype. Soudain, l'invisible est devenu visible.
Lorsque Ethereal a changé de nom pour devenir Wireshark en 2006, j'ai maintenu et mis à jour mon plugin en conséquence. Il ne s'agissait pas d'un outil ponctuel, il a fait partie de mon arsenal analytique pendant des années.
J'ai par la suite développé des dissecteurs de protocole similaires pour d'autres enquêtes, y compris mon travail de rétro-ingénierie des RAT (Remote Access Trojans) qui étaient utilisés dans des attaques parrainées par des États-nations contre des cibles politiques et stratégiques. Ce travail allait au-delà de la simple compréhension de leurs protocoles : j'ai également identifié les vulnérabilités de ces outils et développé des exploits qui nous ont permis de “pirater les pirates”, en retournant leurs propres outils contre eux. J'ai présenté les résultats de ces travaux lors de la conférence RSA de 2008 dans mon exposé intitulé “Hacking the Hacker” (pirater le pirate), quelques années après que ces attaques ont eu lieu.
Je me souviens encore de la première fois où j'ai vu le protocole décrypté de Skype apparaître dans ma fenêtre Ethereal personnalisée. Les messages qui étaient auparavant du charabia se sont transformés en données structurées sous mes yeux. Les recherches d'utilisateurs, les demandes de connexion, les informations sur la topologie du réseau - tous les mécanismes qui permettaient au réseau supposé impénétrable de Skype de fonctionner étaient désormais exposés.
Pouvoir lire le protocole n'était qu'un début. L'étape suivante consistait logiquement à le parler moi-même. Ayant compris comment Skype communiquait, j'ai développé des outils autonomes capables d'interagir directement avec le réseau Skype. L'une des capacités particulièrement utiles que cela m'a permis d'acquérir est la possibilité de rechercher l'adresse IP actuelle de n'importe quel utilisateur de Skype en connaissant simplement son nom d'utilisateur. Cette capacité avait des implications significatives : elle pouvait potentiellement être utilisée pour suivre la localisation d'une personne ou explorer des vecteurs d'attaque non liés à Skype dans leur environnement réseau.
Chaque découverte s'est appuyée sur la précédente. Ce qui a commencé comme une enquête technique ciblée a évolué vers quelque chose qui donne à réfléchir : la reconnaissance que ce système de communication auquel des millions de personnes faisaient confiance contenait des vulnérabilités exploitables. Il ne s'agissait pas seulement de faiblesses théoriques, mais de vecteurs d'attaque pratiques qui pouvaient être exploités par quelqu'un ayant suffisamment de connaissances et de détermination.
Un moment clé a été la découverte de vulnérabilités liées à la corruption de la mémoire dans la couche de signalisation. Il ne s'agissait pas seulement de bogues, mais de passerelles potentielles pour l'exécution de codes à distance. Avec suffisamment d'efforts, un pirate pouvait prendre le contrôle complet d'un client Skype à l'insu de l'utilisateur.
Une étape difficile et nécessaire a été de trouver comment exploiter ces vulnérabilités sans faire planter le client Skype. Cela a nécessité une manipulation délicate de la mémoire - nettoyer après l'exploit et reconstruire ce qui avait été écrasé afin que le programme puisse continuer à fonctionner comme si rien ne s'était passé.
Lorsque j'ai finalement réussi, les implications étaient claires et troublantes. Cette capacité pouvait contourner n'importe quel périmètre de défense, accéder à l'ordinateur d'un utilisateur et maintenir cet accès sans être détecté. Le tout par le biais d'un canal crypté qu'aucun système de sécurité ne pouvait inspecter.
Il ne s'agissait plus d'une simple rétro-ingénierie. Il s'agissait de la découverte d'un passe-partout numérique.
Révélation des motifs cachés
Au fur et à mesure que ma carte de l'architecture interne de Skype devenait plus complète, j'ai commencé à comprendre non seulement comment il fonctionnait, mais aussi pourquoi il avait été conçu de cette façon, et ce que cela signifiait pour des millions d'utilisateurs dans le monde entier.
L'intelligence de la conception originale du réseau Skype résidait dans sa véritable nature pair-à-pair. Ce qui apparaissait aux utilisateurs comme une simple application de messagerie était en fait un système distribué sophistiqué. Tout client Skype pouvait être promu silencieusement à un “supernode” s'il disposait d'une adresse IP publique et d'une bande passante suffisante. Ces supernodes constituaient l'épine dorsale du réseau - des points de relais interconnectés qui traitaient les recherches des utilisateurs et géraient les connexions entre les clients ordinaires.
Cette architecture a permis de résoudre un problème fondamental de la communication Internet. Lorsque deux utilisateurs souhaitaient se connecter, même s'ils se trouvaient derrière des pare-feu d'entreprise ou des configurations NAT complexes, Skype pouvait presque toujours établir une connexion. Si des chemins directs n'étaient pas disponibles, le trafic était relayé par ces supernodes, créant ainsi des tunnels virtuels à travers les obstacles de l'internet.
Le système était élégant, résistant et presque entièrement invisible pour les utilisateurs. Vous ne saviez jamais si votre client Skype était devenu un supernode, acheminant silencieusement les tentatives de connexion d'inconnus. Vous ne saviez jamais si vos appels allaient directement à votre ami ou s'ils étaient renvoyés par l'ordinateur de quelqu'un d'autre à l'autre bout du monde.
Les créateurs de Skype ont maintenu une flotte de leurs propres supernodes pour garantir la capacité du réseau, mais ceux-ci étaient techniquement identiques aux supernodes gérés par les utilisateurs. Cette décentralisation a rendu le système remarquablement résistant aux pannes ou aux attaques : il n'y avait pas de point de défaillance unique.
Mais cette architecture avait des implications profondes que la plupart des utilisateurs n'avaient jamais envisagées.
Tout d'abord, bien que tous les messages et appels soient cryptés de bout en bout à l'aide de la technologie AES, la conception du réseau a créé des points de surveillance naturels. Tout ordinateur servant de supernode pouvait observer les schémas de connexion et les métadonnées - qui parlait à qui, quand et pendant combien de temps.
Lorsque Microsoft a racheté Skype en 2012, cette architecture a été fondamentalement modifiée. Les clients ordinaires ne pouvaient plus devenir des supernodes ; à la place, des serveurs contrôlés par Microsoft ont pris en charge toutes les fonctions de relais et de consultation. Cette centralisation signifiait qu'une entité contrôlait désormais l'ensemble de la topologie du réseau et pouvait surveiller tous les schémas de connexion.
Pour les utilisateurs soucieux du respect de leur vie privée, il s'agissait d'un changement important. Bien que le contenu reste crypté, Microsoft a désormais la capacité technique d'observer toutes les métadonnées de connexion. Et s'il le souhaitait, il pouvait s'assurer que le trafic à destination ou en provenance d'utilisateurs spécifiques était toujours acheminé via ses serveurs.
Les mêmes caractéristiques architecturales qui ont rendu Skype si efficace - sa capacité à établir des connexions là où d'autres applications échouent, ses canaux cryptés qui contournent les pare-feu - en ont également fait un vecteur idéal pour les attaques ciblées.
En déployant des clients supernodes modifiés, un attaquant peut se positionner dans le réseau Skype pour intercepter les connexions. En exploitant les vulnérabilités de la couche de signalisation, il peut compromettre le client d'une cible à son insu. Enfin, en extrayant les clés de session, il peut surveiller en silence des communications censées être privées.
Comme tant d'autres fois auparavant, cette affaire a servi d'exemple clair d'une vérité inconfortable : l'écart important entre la perception de la sécurité et la réalité. Des millions d'utilisateurs ont confié à Skype leurs communications les plus sensibles, croyant aux promesses de confidentialité du cryptage, sans jamais soupçonner que l'architecture même du système créait des points de vulnérabilité susceptibles d'être exploités par des personnes disposant de connaissances techniques suffisantes.
Le système n'était pas cassé, il fonctionnait exactement comme prévu. Mais cette conception, une fois bien comprise, a révélé des compromis entre commodité et sécurité dont les utilisateurs n'ont jamais été informés. La boîte noire, une fois ouverte, contenait des surprises qui soulevaient de sérieuses questions sur la confidentialité et la confiance dans le monde numérique.
Réflexions
Vingt ans se sont écoulés depuis que j'ai commencé à percer les mystères de Skype. Au cours de cette période, nous avons assisté à des transformations remarquables dans la façon dont nous communiquons. Skype lui-même est passé d'un système peer-to-peer révolutionnaire à une plate-forme de messagerie contrôlée par une entreprise, avant de tomber en désuétude.
Le parcours que j'ai décrit représente d'innombrables heures de travail méticuleux, des heures passées à regarder des instructions d'assemblage, à fabriquer des outils personnalisés, à tester des hypothèses et à reconstituer progressivement le puzzle. Ce qui n'était au départ qu'une curiosité technique s'est transformé en quelque chose de plus profond : une fenêtre sur la relation complexe entre la technologie, la vie privée et le pouvoir.
Pour moi, cette exploration a révélé une vérité fondamentale sur notre monde numérique : les systèmes auxquels nous faisons le plus confiance sont souvent ceux que nous comprenons le moins. Nous plaçons nos conversations les plus intimes dans des boîtes noires, nous nous fions à des étiquettes telles que “crypté” et “sécurisé” sans nous demander ce que ces affirmations signifient réellement dans la pratique.
L'architecture originale de Skype a été brillamment conçue pour la résilience et la connectivité, mais cette même conception a créé par inadvertance des vecteurs de surveillance et d'attaque. Les caractéristiques mêmes qui l'ont rendu révolutionnaire - sa capacité à traverser les pare-feu, ses canaux cryptés, sa nature distribuée - pourraient être utilisées comme arme contre ses utilisateurs par ceux qui disposent des connaissances et des ressources suffisantes.
Cette dualité existe dans presque toutes les technologies. Le cryptage qui protège les journalistes et les dissidents protège également les communications criminelles. Les vulnérabilités qui permettent une recherche légitime en matière de sécurité peuvent être exploitées à des fins de surveillance ou de sabotage. La même connaissance qui donne du pouvoir peut aussi mettre en danger.
J'ai toujours cru fermement au droit de chaque individu à la vie privée. Je m'oppose à la surveillance de masse sous toutes ses formes, en particulier aux portes dérobées imposées par le gouvernement, qui affaiblissent inévitablement la sécurité de tous. Cependant, je reconnais également que nous vivons dans un monde complexe où les principes généraux se heurtent parfois à des réalités urgentes. Il y a des moments où un accès ciblé aux communications peut permettre d'éviter des dommages immenses.
Les capacités que j'ai développées lors de la rétro-ingénierie de Skype auraient pu être utilisées de différentes manières. Elles auraient pu permettre des violations généralisées de la vie privée si elles avaient été déployées à grande échelle. Elles auraient pu compromettre la sécurité d'innombrables utilisateurs. Mais elles auraient également pu être utilisées avec une précision chirurgicale pour accéder aux communications de ceux qui prévoyaient de faire du mal, ce qui aurait permis de sauver des vies.
À tous ceux qui travaillent dans le domaine de la sécurité offensive, en particulier ceux qui développent des capacités pour les États-nations, je propose cette réflexion : Choisissez vos clients avec soin. Les connaissances que vous acquérez et les outils que vous construisez vous confèrent un pouvoir énorme - le pouvoir de protéger ou de compromettre, de défendre ou d'exploiter. Ce pouvoir s'accompagne d'une responsabilité correspondante.
Alors que Skype se ferme définitivement, je ressens une certaine nostalgie pour ces premiers jours de découverte. Il y avait quelque chose de pur dans le défi de comprendre un système qui ne voulait pas être compris, de cartographier un terrain qu'aucune personne extérieure n'avait jamais documenté. C'était une forme d'exploration qui est devenue de plus en plus rare dans notre monde de logiciels libres et de documentation détaillée.
Mais je ressens aussi de l'espoir. Chaque génération de technologie apporte de nouveaux défis et de nouvelles opportunités. Les leçons tirées de l'architecture de Skype ont influencé la manière dont nous concevons aujourd'hui des systèmes de communication sécurisés. Les vulnérabilités découvertes ont été corrigées dans des protocoles plus récents. Et les questions essentielles soulevées - concernant la transparence, la confiance et l'équilibre entre sécurité et commodité - continuent de façonner notre paysage numérique en constante évolution.
En fin de compte, le résultat le plus précieux de ce voyage n'a peut-être pas été la connaissance technique acquise, mais la perspective qu'il a offerte : une appréciation plus profonde de ce qui se trouve sous les surfaces de notre monde numérique, et une conscience accrue à la fois de la merveille et de l'avertissement que ces profondeurs contiennent.
