Philosophie de l'ingénierie : Joanna Rutkowska

L’essentiel à retenir

• Elle a conçu un système d’exploitation de bureau en partant du principe qu’il serait compromis. Joanna Rutkowska est la chercheuse polonaise en sécurité qui a créé Qubes OS — « un système d’exploitation raisonnablement sécurisé » — autour du principe de la sécurité par compartimentation. Plutôt que de chercher à rendre le système exempt de bogues, Qubes scinde votre vie numérique en machines virtuelles isolées, les « qubes » (travail, personnel, banque, non fiable), de sorte qu’une brèche dans l’une d’elles reste circonscrite et ne puisse atteindre les autres.¹²
• Sa réputation offensive est venue en premier — elle casse les systèmes pour apprendre à les isoler. À Black Hat 2006, elle a présenté Blue Pill, un rootkit de démonstration qui exploitait la virtualisation matérielle d’AMD pour glisser un fin hyperviseur malveillant sous un OS en cours d’exécution, le piégeant dans une machine virtuelle qu’il ne pouvait pas voir. C’est en attaquant les couches les plus profondes de la plateforme qu’elle a appris à quelles couches il ne faut jamais faire confiance.³
• Elle a transformé « se méfier de l’infrastructure » en architecture. Dans une conférence intitulée « Security Through Distrusting », Rutkowska soutenait que l’habitude qu’a l’industrie de rendre des composants « de confiance » est naïve et ne passe pas à l’échelle — mieux vaut traiter n’importe quel composant comme potentiellement compromis, se méfier de la quasi-totalité d’entre eux et n’avoir aucun point de défaillance unique.⁵ Qubes, c’est cet argument compilé en un poste de travail fonctionnel.²
• Elle a sondé les couches de la plateforme auxquelles tous les autres faisaient aveuglément confiance. Au-delà de Blue Pill, elle a mené des travaux pionniers d’attaque contre le System Management Mode et la technologie Intel Trusted Execution Technology, et en 2009 elle a forgé l’attaque « Evil Maid » (la femme de chambre malveillante), qui défait le chiffrement intégral du disque, comme celui de TrueCrypt, au moyen d’un bref accès physique. Chaque attaque cartographiait une frontière de confiance qui se révélait être un mensonge.¹⁴

Le principe

« Tout logiciel contient des bogues… Plutôt que de tenter de prévenir chaque exploitation possible, Qubes part du principe que l’exploitation aura lieu et se concentre sur le confinement des dégâts. » — l’introduction de Qubes OS, paraphrasant sa raison d’être fondatrice²

La plupart des travaux d’ingénierie de sécurité poursuivent une cible impossible. Vous auditez le code, colmatez les failles, durcissez la configuration, et vous vous dites que si vous êtes assez prudent, le système sera sûr. La carrière de Rutkowska est une longue et patiente démonstration que cette cible est un mirage. Un poste de travail moderne fait tourner des dizaines de millions de lignes de code — noyau, pilotes, navigateur, lecteur PDF, microprogramme — et chacune de ces lignes est un endroit où un bogue peut se cacher. Vous ne les trouverez pas tous, et votre adversaire n’en a besoin que d’un seul. La question honnête n’est donc pas « comment rendre ceci exempt de bogues ? » mais « quand — et non si — quelque chose s’introduit, jusqu’où cela peut-il aller ? »²

La réponse que Rutkowska a construite, c’est la sécurité par isolation. Si vous ne pouvez pas empêcher une compromission, vous pouvez décider à l’avance jusqu’où elle se propage. Qubes scinde la machine en machines virtuelles distinctes — une pour le travail, une pour la banque, une pour la navigation personnelle, une pour ouvrir les pièces jointes douteuses — chacune tournant sur l’hyperviseur Xen avec sa propre frontière. Ouvrez un lien malveillant dans le qube non fiable et le maliciel atterrit dans une pièce scellée. Il n’a jamais partagé de frontière de confiance avec votre qube bancaire, il ne peut donc atteindre vos identifiants, et il vous suffit de jeter le qube compromis.¹² Le monde physique fonctionne déjà ainsi : vous ne votez pas, ne dormez pas et ne stockez pas votre argent dans une même pièce indivise, et Qubes demande pourquoi votre ordinateur, lui, le ferait.²

Le principe a une seconde moitié, et c’est la plus difficile : se méfier de l’infrastructure et réduire ce qu’on est forcé de croire fiable. Dans sa conférence « Security Through Distrusting », Rutkowska soutenait que qualifier un composant de « de confiance » n’est pas un compliment — c’est l’aveu que ce composant est « capable de détruire l’intégrité de toute ma sécurité » s’il défaille.⁵ La discipline consiste donc à traiter presque chaque composant comme potentiellement compromis, à supprimer les points de défaillance uniques et à maintenir la base informatique de confiance — le code dont tout le reste dépend pour sa correction — aussi petite que possible.⁵² Au bout du compte, vous ferez confiance à quelque chose. Tout l’art consiste à rendre ce quelque chose minuscule, inspectable et peu nombreux.

Contexte

Joanna Rutkowska est née en 1981 à Varsovie, en Pologne, et a obtenu un master en informatique à l’Université de technologie de Varsovie.¹ Elle s’est imposée non pas comme défenseure mais comme chercheuse offensive, et une chercheuse particulièrement douée — au milieu des années 2000, elle sondait les couches les plus basses et les plus dignes de confiance de la plateforme x86, celles que la sécurité défensive tient d’ordinaire pour un terrain solide.

Sa percée fut Blue Pill, présentée aux Black Hat Briefings le 3 août 2006, en parallèle de travaux montrant comment défaire les mécanismes de protection du noyau de Windows Vista. eWeek l’a désignée comme l’une des « Cinq hackers qui ont marqué 2006 ».¹³ En avril 2007, elle a fondé Invisible Things Lab à Varsovie, le cabinet de conseil et de recherche qui est devenu le foyer de ses travaux sur la sécurité des plateformes.¹ Au cours des années suivantes, elle et ses collaborateurs — Alexander Tereshkin et Rafal Wojtczuk parmi eux — ont publié des attaques contre l’hyperviseur Xen, contre la technologie Intel Trusted Execution Technology et contre le System Management Mode, le mode d’exécution hautement privilégié « ring -2 » qui se situe sous le noyau du système d’exploitation lui-même.¹ En 2009, elle a forgé l’attaque Evil Maid, une technique fondée sur un accès physique qui compromet le processus de démarrage d’un ordinateur portable pour dérober la phrase secrète d’un chiffrement intégral du disque comme celui de TrueCrypt.⁴

Puis elle a fait ce que les chercheurs offensifs font rarement : elle a bâti la défense. Les travaux sur Qubes OS ont commencé vers 2010 avec Wojtczuk, et Qubes 1.0 est sorti le 3 septembre 2012, bâti sur le principe de la sécurité par compartimentation.¹ Elle a dirigé le projet pendant des années, et l’approche a recueilli les soutiens publics de personnalités aussi diverses qu’Edward Snowden et le cryptographe Daniel J. Bernstein.² Plus tard, elle s’est orientée vers des travaux sur la confidentialité et la décentralisation ; les détails de ses projets les plus récents se lisent mieux à partir de ses propres canaux actuels qu’au travers d’un résumé de seconde main, et le présent texte s’en tient à ce qui est solidement établi.¹

Le travail

Qubes OS : la sécurité par compartimentation

Commençons ici, car Qubes est le principe transformé en quelque chose que vous pouvez réellement faire tourner. La conception débute en concédant la guerre que la plupart des outils de sécurité prétendent gagner : tout logiciel comporte des bogues, et certains de ces bogues sont exploitables.² Qubes ne cherche pas à être le système inviolable. Il cherche à être le système où une rupture n’a guère d’importance.

Le mécanisme, c’est l’hyperviseur Xen. Sous tout le reste se trouve un fin hyperviseur et un domaine administratif spécial appelé dom0, qui contrôle l’affichage et le matériel mais reste délibérément à l’écart du réseau. Au-dessus tournent vos qubes — des machines virtuelles légères, chacune cantonnée à une finalité et à un niveau de confiance.¹² Vous pourriez conserver un qube « travail », un qube « banque », un qube « personnel » et un qube « non fiable » pour ouvrir tout ce qui provient d’un inconnu. Les fenêtres de chaque qube portent une bordure colorée infalsifiable, ce qui vous permet de voir d’un coup d’œil à quel domaine de sécurité appartient une fenêtre donnée.² Point crucial, les qubes partagent leurs systèmes de fichiers racines via un système de modèles (templates), de sorte qu’ils restent légers et se mettent à jour ensemble, tandis que leurs données privées demeurent isolées.² Et pour les tâches les plus risquées, il y a les qubes jetables — des VM qui se lancent pour ouvrir un seul PDF ou un seul lien, puis s’autodétruisent, emportant avec elles toute infection.²

Pourquoi cela compte sur le plan de l’ingénierie : Qubes recadre l’unité de sécurité, qui passe de « la machine » à « le domaine ». Sur un poste de travail ordinaire, chaque application que vous lancez partage un même espace de confiance — votre navigateur, votre logiciel d’impôts et la pièce jointe que vous n’auriez pas dû ouvrir sont tous séparés les uns des autres par un seul mauvais bogue. Qubes fait de la frontière entre domaines un mur appliqué par le matériel plutôt qu’une convention pleine d’espoir. Le coût est réel — davantage de RAM, davantage de friction, la discipline de décider à quel qube appartient une tâche — et Rutkowska reconnaît franchement que la sécurité par la méfiance « n’est pas une panacée », car elle se paie au prix de la facilité d’usage.⁵ Mais le bénéfice, c’est que le pire cas cesse d’être catastrophique. Une compromission n’est plus « ils possèdent mon ordinateur ». C’est « ils possèdent une pièce jetable, que je m’apprête à supprimer ».

Casser la plateforme : Blue Pill, le SMM et l’Evil Maid

On ne peut pas concevoir de bonnes frontières d’isolation tant qu’on ne sait pas exactement quelles frontières sont factices, et Rutkowska l’a appris en les attaquant. Blue Pill, sa démonstration à Black Hat en 2006, en est le cas le plus net. Il s’agissait d’un rootkit de démonstration qui exploitait la virtualisation matérielle d’AMD (AMD-V) pour accomplir une chose audacieuse : démarrer un fin hyperviseur sur une machine en cours d’exécution et y migrer à la volée le système d’exploitation vivant dans une machine virtuelle placée sous lui.³ Depuis l’intérieur de cette VM, l’OS verrait un monde normal — mais l’hyperviseur situé en dessous pouvait intercepter « les interruptions matérielles, les demandes de données et même l’heure système », servant au système d’exploitation piégé les réponses de son choix.³

Il vaut la peine d’être précis sur ce que Blue Pill était et n’était pas. C’était une démonstration de faisabilité, pas un maliciel observé dans la nature, et son affirmation la plus audacieuse — qu’un tel rootkit d’hyperviseur pouvait être rendu « indétectable à 100 % » — a été contestée, d’autres chercheurs proposant une détection fondée sur le chronométrage.³ Mais le titre contesté n’est pas la leçon. La leçon, c’est la surface d’attaque qu’il a mise au jour : l’hypothèse, gravée dans chaque système d’exploitation, que la couche sur laquelle il tourne est bienveillante. Blue Pill a montré que la virtualisation pouvait transformer la couche la plus privilégiée en terrain de prédilection de l’attaquant — et que ce que vous croyez « en dessous » de vous est précisément ce que vous ne pouvez pas vérifier « depuis le dessus ».

Le même instinct a guidé le reste de son travail offensif. Avec des collaborateurs, elle a attaqué le System Management Mode, ce mode de microprogramme obscur et hyper-privilégié qui tourne sous le noyau, ainsi que la technologie Intel Trusted Execution Technology, une fonctionnalité dont le but entier était d’établir la confiance.¹ Et en 2009, elle a forgé l’attaque Evil Maid : laissez un ordinateur portable chiffré sans surveillance dans une chambre d’hôtel, et une « femme de chambre » disposant d’un bref accès physique peut altérer le chargeur de démarrage non chiffré de sorte qu’il capture votre phrase secrète la prochaine fois que vous la saisissez.⁴ Le chiffrement intégral du disque, comme celui de TrueCrypt, était vulnérable parce que le code de démarrage ne pouvait pas s’authentifier auprès de l’utilisateur — vous n’aviez aucun moyen de savoir que le chargeur réclamant votre phrase secrète était toujours le vôtre.⁴ Chacune de ces attaques est la carte d’une frontière de confiance qui n’a pas tenu. L’architecte défensive qui a bâti Qubes par la suite savait déjà, de l’intérieur, quels murs étaient porteurs et lesquels n’étaient que peints en trompe-l’œil.

Se méfier de l’infrastructure : réduire la base informatique de confiance

Qubes n’est pas seulement « tout faire tourner dans des VM ». Le principe de conception plus profond, c’est de minimiser la base informatique de confiance et de s’en méfier — l’ensemble des composants dont la correction conditionne la sécurité de tout le système. La conférence de Rutkowska, « Security Through Distrusting », énonce la philosophie sans détour : l’élan conventionnel qui consiste à rendre des composants « de confiance » est « excessivement naïf et non extensible », car en sécurité « de confiance » signifie en réalité qu’un composant est « capable de détruire l’intégrité de toute ma sécurité » s’il défaille.⁵ La bonne réponse est de partir du principe que n’importe quel composant peut être compromis, de se méfier de la quasi-totalité d’entre eux et de concevoir de manière à n’avoir aucun point de défaillance unique.⁵

On retrouve ce principe dans les choix concrets de Qubes. Le domaine administratif dom0 se voit délibérément refuser l’accès au réseau, car un dom0 joignable par le réseau serait un point unique dont la compromission donnerait la machine tout entière.² Le réseau et l’USB sont eux-mêmes repoussés dans leurs propres qubes isolés, de sorte qu’un bogue dans un pilote de carte réseau ou un périphérique USB malveillant atterrisse dans un bac à sable plutôt que dans le noyau auquel tout fait confiance.² Les fichiers qui passent d’un domaine à un autre sont traités sur le mode défensif — la même logique du « partons du principe qu’il est compromis » que Rutkowska appliquait à la façon dont Qubes traite les images et les PDF.⁵ Et les qubes jetables incarnent la méfiance de la manière la plus directe : plutôt que de faire confiance à un lecteur de PDF pour ne pas être exploité, vous partez du principe qu’il le sera, vous le faites tourner dans une VM que vous vous apprêtez à détruire et vous laissez l’explosion se produire dans une pièce vide.²

Le fil conducteur, c’est l’humilité à l’égard de son propre code. Un système qui fait confiance à un composant volumineux et complexe fait un pari volumineux et complexe. L’architecture de Rutkowska s’efforce de réduire le pari — de ramener la base informatique de confiance à un fin hyperviseur et à un dom0 isolé du réseau, et de traiter presque tout ce qui se trouve au-dessus comme superflu, remplaçable et présumé hostile.²⁵

Du poste de travail à la décentralisation

Rutkowska a dirigé Qubes pendant des années, puis s’est tournée vers le problème plus large que le système d’exploitation ne résout qu’en partie : même un poste de travail parfaitement compartimenté fait encore confiance à l’infrastructure qui l’entoure — le stockage dans le cloud, le réseau, les services qui détiennent vos données.¹⁵ Ses travaux ultérieurs se sont orientés vers la confidentialité et la décentralisation, étendant la même méfiance vers l’extérieur, de la machine unique aux systèmes auxquels elle parle. La forme et l’état exacts de ces projets se prennent mieux dans ses propres écrits actuels que dans une paraphrase ici ; ce qui traverse sans difficulté, c’est le principe, pas le produit. L’instinct est constant : partir du principe que l’infrastructure est compromise, et architecturer de sorte que cette hypothèse vous coûte le moins possible.⁵

La méthode

Parcourez ensemble Qubes, Blue Pill, les attaques SMM et TXT, et « Security Through Distrusting », et les mêmes engagements reviennent. La méthode de Rutkowska tient moins du slogan que d’un ensemble d’habitudes permanentes.

Partez du principe qu’il y aura compromission ; concevez pour le rayon de l’explosion. Le geste fondateur consiste à concéder que la prévention échouera et à se demander jusqu’où une brèche se propage.² À grande échelle, c’est le jumeau, côté sécurité, de ce que fait Werner Vogels pour la fiabilité — tout finit toujours par tomber en panne, alors confinez le rayon de l’explosion au lieu de prétendre pouvoir éviter la panne. La leçon se transpose bien au-delà de Qubes : n’architecturez pas pour le cas où rien ne s’introduit ; architecturez de sorte que, lorsque quelque chose s’introduit, il soit piégé dans une petite cellule jetable. C’est la barrière de la preuve appliquée à la sécurité — « personne ne s’est encore introduit » n’est pas une preuve ; « une brèche ici ne peut pas atteindre là-bas » en est une.

Méfiez-vous de l’infrastructure, et prouvez la frontière. Traitez chaque composant comme potentiellement compromis et refusez d’accorder votre confiance par défaut.⁵ C’est « Reflections on Trusting Trust » de Thompson transformé en architecture de poste de travail : vous ne pouvez pas faire confiance à ce que vous n’avez pas examiné, alors cessez de faire confiance aux couches que vous ne pouvez pas voir et cloisonnez-les. La discipline consiste à demander de chaque composant : « si celui-ci est compromis, que possède-t-il ? » — et à redessiner les frontières jusqu’à ce que la réponse soit « presque rien ».

Cassez-le vous-même avant qu’un autre ne le fasse. La défense de Rutkowska repose sur une décennie d’offensive — Blue Pill, SMM, Evil Maid — car on ne peut pas isoler une frontière dont on n’a pas d’abord prouvé qu’elle est factice.³⁴ C’est exactement l’instinct qu’Adi Shamir a apporté à la cryptographie : attaquer pour défendre, et ne faire confiance qu’à ce qui survit à une tentative sérieuse de cassure. L’habitude permanente est de coiffer d’abord le chapeau de l’attaquant, de cartographier lesquelles de vos hypothèses de confiance sont des mensonges, et de dresser les murs là où se trouvaient les mensonges.

Réduisez la base informatique de confiance. Moins votre sécurité dépend de lignes de code, plus petit est votre pari.²⁵ Un fin hyperviseur et un dom0 isolé du réseau forment une mise inspectable ; un noyau monolithique avec chaque pilote et chaque service à l’intérieur de la frontière de confiance forme une mise aveugle. C’est le produit minimum digne d’être livré appliqué à la confiance : la base de confiance la plus propre est la plus petite qui remplisse encore son unique fonction. Dépouillez la confiance jusqu’à ce qui doit être tenu pour fiable, et présumez le reste hostile.

Soyez honnête sur le compromis. Rutkowska ne survend pas — elle dit clairement que la sécurité par la méfiance « n’est pas une panacée » et se paie en facilité d’usage et en commodité.⁵ L’habitude consiste à nommer le prix de la sécurité que vous achetez plutôt qu’à le dissimuler, afin que l’ingénieur suivant puisse le soupeser. Cette franchise, c’est la qualité est la seule variable appliquée à la sécurité : la vraie garantie, énoncée avec ses coûts, vaut davantage qu’une promesse confortable qui, en silence, ne tient pas. Une frontière que vous avez comprise et choisie l’emporte sur une frontière que vous avez supposée et héritée.

Chaîne d’influence

Qui l’a façonnée

La communauté de la recherche offensive du milieu des années 2000. Rutkowska s’est élevée au sein de la culture de l’attaque des plateformes, celle de Black Hat et du hacking des systèmes de bas niveau, où le travail consistait à trouver l’hypothèse que personne ne remettait en question et à la casser.³ Le réflexe central de cette culture — se méfier de la couche à laquelle tout le monde fait confiance — est devenu la colonne vertébrale de son travail défensif. (Influence formatrice)

La vague de la virtualisation matérielle. Blue Pill n’a été possible que parce qu’AMD-V et Intel VT-x venaient tout juste de démocratiser la virtualisation matérielle.³ La technologie même qu’elle a utilisée comme arme en 2006 est devenue le fondement sur lequel elle a bâti l’isolation dans Qubes, où Xen fait passer l’hyperviseur d’outil de l’attaquant à mur du défenseur.¹² (Influence directe)

La lignée de la sécurité de Xen et des hyperviseurs. Ses années d’analyse et d’attaque de Xen lui ont appris exactement à quel point l’isolation par hyperviseur est forte — et à quel point elle est fragile —, un savoir qui a façonné la décision de Qubes de garder dom0 à l’écart du réseau et de repousser les pilotes dans des domaines isolés.¹² (Influence formatrice)

Qui elle a façonné

L’informatique soucieuse de la vie privée. Qubes est devenu le poste de travail recommandé pour les journalistes, les militants et les chercheurs en sécurité qui doivent partir du principe d’une compromission ciblée — un véritable outil pour les personnes dont le modèle de menace est un État, pas un slogan.²

L’état d’esprit de la compartimentation. « La sécurité par isolation » et « réduire la base informatique de confiance » se sont propagées bien au-delà de Qubes dans la façon dont l’industrie raisonne le bac à sable, l’isolation par conteneurs et la virtualisation par application.²⁵

Les défenseurs qui cassent d’abord. Rutkowska est un exemple permanent que les architectes défensifs les plus forts sont souvent d’anciens attaquants — que cartographier les véritables frontières de confiance en les cassant est le préalable à les dessiner correctement.³⁴

Le fil conducteur

Rutkowska est la clé de voûte de l’isolation dans cette série — la figure qui répond à « le système sera percé » non par le désespoir mais par l’architecture. Adi Shamir attaque pour défendre en cryptographie, ne faisant confiance qu’à ce qui survit à une véritable tentative de cassure ; Rutkowska fait tourner la même boucle une couche plus bas, cassant des hyperviseurs et des chaînes de démarrage afin de pouvoir bâtir un poste de travail qui survit à leur compromission.³⁴ Thompson et Ritchie nous ont légué l’avertissement qu’on ne peut pas faire confiance à ce qu’on n’a pas soi-même construit et examiné ; le « se méfier de l’infrastructure » de Rutkowska est cet avertissement transformé en système d’exploitation fonctionnel, où les couches non fiables sont cloisonnées plutôt qu’objet d’espoir.⁵ Et là où Werner Vogels dit tout finit toujours par tomber en panne, alors confinez le rayon de l’explosion pour la fiabilité, Rutkowska dit la même chose pour la sécurité : Radia Perlman a conçu des réseaux en partant du principe que le cas hostile et défaillant est le centre de la conception, et Rutkowska conçoit des machines de cette manière. Là où Vogels confine un disque défaillant et où Perlman confine un lien défaillant, Rutkowska dit : l’attaquant est déjà à l’intérieur — alors isolez chaque domaine, méfiez-vous de chaque couche, et faites de la brèche une pièce jetable dont vous pouvez vous débarrasser. (Passerelle de la série)

Ce que j’en retiens

La leçon que je garde de Rutkowska, c’est de concevoir pour la brèche, pas contre elle. Mon instinct, comme celui de la plupart des bâtisseurs, est de durcir la chose — valider l’entrée, corriger la dépendance, verrouiller la configuration — et de traiter la sécurité comme un mur que j’essaie de rendre assez haut. « Tout logiciel contient des bogues » est la réplique cinglante : le mur sera percé, parce qu’il y a toujours un bogue de plus, et la question qui compte vraiment est ce que l’attaquant atteint une fois qu’il est de l’autre côté. Alors, quand je construis quelque chose désormais — une frontière d’authentification, un service qui traite des entrées non fiables, une fonctionnalité qui touche à l’argent — j’essaie de me demander « quand ceci sera compromis, quel est le rayon de l’explosion ? » avant de me demander « comment l’empêcher d’entrer ? ». La version honnête du mot « sécurisé » n’est pas « je ne vois pas comment ceci casse ». C’est « quand cela casse, les dégâts sont piégés dans une pièce que je peux supprimer ».

La seconde leçon, c’est une paranoïa raisonnable à l’égard de ce que je suis forcé de croire fiable. Il est facile de laisser passer un composant comme « de confiance » et de passer à autre chose, mais Rutkowska a recadré ce mot pour moi : qualifier quelque chose de « de confiance », c’est admettre qu’il peut tout détruire s’il défaille. Cela a changé ma façon de tracer les frontières. Chaque bibliothèque que j’intègre, chaque service dont je dépends, chaque couche sur laquelle je tourne est un pari sur sa correction — et la taille du pari, c’est la taille de ma base informatique de confiance. J’essaie donc de garder cette base petite et inspectable, de repousser le risqué et le complexe dans des bacs à sable que je présume hostiles, et d’être honnête, comme elle l’est, sur le fait que l’isolation me coûte en commodité. La paranoïa n’est pas du pessimisme. C’est la discipline de savoir exactement ce à quoi je fais confiance, et de rendre cette liste aussi courte que possible.

FAQ

Qu’est-ce que Qubes OS ?

Qubes OS est un système d’exploitation de bureau libre, open source et orienté sécurité, créé par Joanna Rutkowska, décrit par le projet comme « un système d’exploitation raisonnablement sécurisé ».² Il utilise l’hyperviseur Xen pour scinder votre informatique en machines virtuelles isolées appelées qubes — des compartiments distincts pour des activités comme le travail, la banque, la navigation personnelle et l’ouverture de fichiers non fiables. Comme les qubes sont isolés, une compromission dans l’un ne peut atteindre les autres, de sorte que les dégâts de toute brèche unique sont confinés. Il prend également en charge des qubes jetables qui s’autodétruisent après usage, et il dote chaque domaine d’une bordure de fenêtre colorée infalsifiable, afin que vous puissiez voir à quel compartiment appartient une fenêtre.¹²

Qu’est-ce que la sécurité par isolation (compartimentation) ?

La sécurité par isolation, ou compartimentation, est le principe au cœur de Qubes : plutôt que de chercher à rendre un logiciel exempt de bogues, vous partez du principe qu’il y aura compromission et vous confinez les dégâts en divisant le système en domaines isolés.² L’introduction de Qubes file l’analogie avec la vie physique — vous séparez naturellement vos activités dans des pièces différentes — et l’applique à un ordinateur où, sans cela, tout partagerait une seule frontière de confiance.² La moitié complémentaire, c’est « se méfier de l’infrastructure » : traiter chaque composant comme potentiellement compromis, supprimer les points de défaillance uniques et maintenir la base informatique de confiance aussi petite que possible.⁵

Qu’était Blue Pill ?

Blue Pill était un rootkit de démonstration que Joanna Rutkowska a présenté à Black Hat le 3 août 2006. Il utilisait la virtualisation matérielle d’AMD (AMD-V) pour démarrer un fin hyperviseur malveillant sur une machine en cours d’exécution et y migrer le système d’exploitation vivant dans une machine virtuelle placée sous lui, de sorte que l’hyperviseur pouvait intercepter et falsifier la vision qu’avait l’OS du matériel, des interruptions et même de l’heure système.³ L’affirmation de Rutkowska selon laquelle un tel rootkit pouvait être « indétectable à 100 % » a été contestée, d’autres chercheurs proposant une détection fondée sur le chronométrage. C’était une démonstration de recherche d’une surface d’attaque — l’hypothèse que la couche située sous votre OS est bienveillante — et non un maliciel observé dans la nature.³

Qu’est-ce que l’attaque Evil Maid ?

L’attaque Evil Maid est une technique fondée sur un accès physique que Joanna Rutkowska a nommée dans un billet de blog de 2009. Si un attaquant obtient un bref accès non surveillé à un ordinateur portable chiffré laissé sans surveillance — dans une chambre d’hôtel, par exemple —, il peut altérer le code de démarrage non chiffré de sorte qu’il capture secrètement la phrase secrète de chiffrement intégral du disque de l’utilisateur la prochaine fois qu’elle est saisie.⁴ Les systèmes de chiffrement intégral du disque comme TrueCrypt étaient vulnérables parce que le chargeur de démarrage ne pouvait pas s’authentifier auprès de l’utilisateur, si bien que la victime n’avait aucun moyen de distinguer le chargeur compromis du chargeur légitime.⁴ C’est une démonstration frappante que le chiffrement à lui seul ne protège pas une machine qu’un adversaire peut toucher physiquement.

Sources