Engineering-Philosophie: Joanna Rutkowska

Die wichtigsten Erkenntnisse

• Sie baute ein Desktop-Betriebssystem unter der Annahme, dass es kompromittiert würde. Joanna Rutkowska ist die polnische Sicherheitsforscherin, die Qubes OS schuf – „ein angemessen sicheres Betriebssystem” – rund um das Prinzip der Sicherheit durch Kompartimentierung. Statt zu versuchen, das System fehlerfrei zu machen, teilt Qubes Ihr digitales Leben in isolierte virtuelle Maschinen namens „Qubes” auf (Arbeit, Privates, Bankgeschäfte, Nichtvertrauenswürdiges), sodass ein Einbruch in eine davon eingegrenzt bleibt und die anderen nicht erreichen kann.¹²
• Ihr Ruf als Angreiferin kam zuerst – sie bricht Systeme auf, um zu lernen, wie man sie isoliert. Auf der Black Hat 2006 präsentierte sie Blue Pill, ein Proof-of-Concept-Rootkit, das die Hardware-Virtualisierung von AMD nutzte, um einen dünnen bösartigen Hypervisor unter ein laufendes Betriebssystem zu schieben und es in einer virtuellen Maschine einzusperren, die es nicht sehen konnte. Die tiefsten Schichten der Plattform anzugreifen, lehrte sie, welchen Schichten man niemals vertrauen darf.³
• Sie machte aus „Misstraue der Infrastruktur” eine Architektur. In einer Keynote mit dem Titel „Security Through Distrusting” argumentierte Rutkowska, dass die Gewohnheit der Branche, Komponenten zu „vertrauenswürdigen” zu erklären, naiv sei und nicht skaliere – besser, jede einzelne Komponente als potenziell kompromittiert zu behandeln, fast allen zu misstrauen und keinen einzelnen Ausfallpunkt zu haben.⁵ Qubes ist genau dieses Argument, kompiliert zu einem funktionierenden Desktop.²
• Sie untersuchte die Plattformschichten, denen alle anderen blind vertrauten. Über Blue Pill hinaus leistete sie Pionierarbeit beim Angriff auf den System Management Mode und Intels Trusted Execution Technology, und 2009 prägte sie den „Evil Maid”-Angriff, der Festplattenverschlüsselung wie TrueCrypt durch kurzen physischen Zugriff aushebelt. Jeder Angriff kartierte eine Vertrauensgrenze, die sich als Lüge entpuppte.¹⁴

Das Prinzip

„Jede Software enthält Fehler … Statt zu versuchen, jeden möglichen Exploit zu verhindern, geht Qubes davon aus, dass eine Ausnutzung stattfinden wird, und konzentriert sich darauf, den Schaden einzugrenzen.” – die Einführung in Qubes OS, die ihre grundlegende Begründung paraphrasiert²

Die meiste Sicherheitstechnik jagt einem unmöglichen Ziel hinterher. Sie prüfen den Code, stopfen die Löcher, härten die Konfiguration und reden sich ein, dass das System sicher sein wird, wenn Sie nur vorsichtig genug sind. Rutkowskas Laufbahn ist eine lange, geduldige Demonstration, dass dieses Ziel eine Fata Morgana ist. Ein moderner Desktop führt zig Millionen Zeilen Code aus – Kernel, Treiber, Browser, PDF-Reader, Firmware – und jede dieser Zeilen ist ein Ort, an dem sich ein Fehler verstecken kann. Sie werden nicht alle finden, und Ihr Gegner braucht nur einen einzigen. Die ehrliche Frage lautet also nicht „Wie mache ich das fehlerfrei?”, sondern „Wann – nicht ob – etwas hereinkommt, wie weit kann es reichen?”²

Die Antwort, die Rutkowska baute, ist Sicherheit durch Isolation. Wenn Sie eine Kompromittierung nicht verhindern können, können Sie im Voraus entscheiden, wie weit sie sich ausbreitet. Qubes teilt die Maschine in getrennte virtuelle Maschinen auf – eine für die Arbeit, eine für Bankgeschäfte, eine für privates Surfen, eine zum Öffnen zweifelhafter Anhänge – jede läuft mit ihrer eigenen Grenze auf dem Xen-Hypervisor. Öffnen Sie einen bösartigen Link im nichtvertrauenswürdigen Qube, landet die Schadsoftware in einem versiegelten Raum. Sie teilte nie eine Vertrauensgrenze mit Ihrem Banking-Qube, kann also Ihre Zugangsdaten nicht erreichen, und Sie können den kompromittierten Qube einfach wegwerfen.¹² Die physische Welt funktioniert bereits so: Sie wählen, schlafen und bewahren Bargeld nicht im selben ungeteilten Raum auf, und Qubes fragt, warum Ihr Computer es tut.²

Das Prinzip hat eine zweite Hälfte, und sie ist die schwierigere: Misstrauen Sie der Infrastruktur und verkleinern Sie das, dem Sie vertrauen müssen. In ihrer Keynote „Security Through Distrusting” argumentierte Rutkowska, dass es kein Kompliment sei, eine Komponente „vertrauenswürdig” zu nennen – es sei ein Eingeständnis, dass die Komponente „in der Lage ist, meine gesamte Sicherheitsintegrität zu zerstören”, falls sie versagt.⁵ Die Disziplin besteht also darin, nahezu jede Komponente als potenziell kompromittiert zu behandeln, einzelne Ausfallpunkte zu beseitigen und die Trusted Computing Base – den Code, von dessen Korrektheit alles andere abhängt – so klein wie nur möglich zu halten.⁵² Am Ende werden Sie irgendetwas vertrauen. Die Kunst besteht darin, dieses Etwas winzig, prüfbar und gering an Zahl zu machen.

Kontext

Joanna Rutkowska wurde 1981 in Warschau, Polen, geboren und erwarb einen Masterabschluss in Informatik an der Technischen Universität Warschau.¹ Sie kam nicht als Verteidigerin auf, sondern als offensive Forscherin – und eine notorisch gute. Mitte der 2000er-Jahre untersuchte sie die tiefsten, vertrauenswürdigsten Schichten der x86-Plattform, jene Schichten, die die defensive Sicherheit gewöhnlich als festen Boden behandelt.

Ihr Durchbruch war Blue Pill, vorgeführt auf den Black Hat Briefings am 3. August 2006, zusammen mit Arbeiten, die zeigten, wie sich die Kernel-Schutzmechanismen von Windows Vista aushebeln lassen. eWeek zählte sie zu den „Five Hackers who Put a Mark on 2006”.¹³ Im April 2007 gründete sie in Warschau Invisible Things Lab, die Beratungs- und Forschungswerkstatt, die zur Heimat ihrer Plattform-Sicherheitsarbeit wurde.¹ In den folgenden Jahren veröffentlichten sie und ihre Mitstreiter – darunter Alexander Tereshkin und Rafal Wojtczuk – Angriffe auf den Xen-Hypervisor, auf Intels Trusted Execution Technology und auf den System Management Mode, den zutiefst privilegierten Ausführungsmodus „Ring -2” unterhalb sogar des Betriebssystem-Kernels.¹ 2009 prägte sie den Evil-Maid-Angriff, eine Technik mit physischem Zugriff, die den Boot-Vorgang eines Laptops kompromittiert, um die Passphrase einer Festplattenverschlüsselung wie TrueCrypt zu stehlen.⁴

Dann tat sie das, was offensive Forscher selten tun: Sie baute die Verteidigung. Die Arbeit an Qubes OS begann um 2010 zusammen mit Wojtczuk, und Qubes 1.0 erschien am 3. September 2012, errichtet auf dem Prinzip der Sicherheit durch Kompartimentierung.¹ Sie leitete das Projekt jahrelang, und der Ansatz erhielt öffentliche Unterstützung von so unterschiedlichen Persönlichkeiten wie Edward Snowden und dem Kryptografen Daniel J. Bernstein.² In späteren Jahren wandte sie sich der Arbeit an Datenschutz und Dezentralisierung zu; die Einzelheiten ihrer jüngsten Projekte liest man am besten aus ihren eigenen aktuellen Kanälen, statt sie aus zweiter Hand zusammenzufassen, und dieser Beitrag hält sich an das, was fest belegt ist.¹

Das Werk

Qubes OS: Sicherheit durch Kompartimentierung

Beginnen Sie hier, denn Qubes ist das Prinzip, umgesetzt in etwas, das Sie tatsächlich ausführen können. Der Entwurf beginnt damit, den Krieg einzuräumen, den die meisten Sicherheitswerkzeuge zu gewinnen vorgeben: Jede Software hat Fehler, und manche dieser Fehler sind ausnutzbar.² Qubes versucht nicht, das unzerbrechliche System zu sein. Es versucht, das System zu sein, bei dem ein Bruch nicht sehr viel ausmacht.

Der Mechanismus ist der Xen-Hypervisor. Unter allem liegt ein dünner Hypervisor und eine besondere Verwaltungsdomäne namens dom0, die Anzeige und Hardware steuert, aber bewusst vom Netzwerk getrennt gehalten wird. Darüber laufen Ihre Qubes – leichtgewichtige virtuelle Maschinen, jede auf einen Zweck und eine Vertrauensstufe zugeschnitten.¹² Sie könnten einen „Arbeits”-Qube, einen „Banking”-Qube, einen „Privat”-Qube und einen „nichtvertrauenswürdigen” Qube zum Öffnen von allem führen, was von einem Fremden eintraf. Die Fenster jedes Qubes tragen einen fälschungssicheren farbigen Rahmen, sodass Sie auf einen Blick erkennen, zu welcher Sicherheitsdomäne ein bestimmtes Fenster gehört.² Entscheidend ist, dass die Qubes ihre Root-Dateisysteme über ein Template-System teilen, sodass sie schlank bleiben und gemeinsam aktualisiert werden, während ihre privaten Daten isoliert bleiben.² Und für die riskantesten Aufgaben gibt es Einweg-Qubes – VMs, die hochfahren, um ein einziges PDF oder einen einzigen Link zu öffnen, und sich dann selbst zerstören und jede Infektion mitnehmen.²

Warum es als Ingenieurskunst zählt: Qubes verschiebt die Einheit der Sicherheit von „der Maschine” zu „der Domäne”. Auf einem normalen Desktop teilen sich alle Anwendungen, die Sie ausführen, einen Adressraum des Vertrauens – Ihr Browser, Ihre Steuersoftware und der Anhang, den Sie nicht hätten öffnen sollen, sind alle nur einen schlimmen Fehler voneinander entfernt. Qubes macht die Grenze zwischen Domänen zu einer hardwaregestützten Mauer statt zu einer hoffnungsvollen Konvention. Der Preis ist real – mehr RAM, mehr Reibung, die Disziplin zu entscheiden, in welchen Qube eine Aufgabe gehört – und Rutkowska sagt offen, dass Sicherheit durch Misstrauen „kein Allheilmittel” sei, weil sie auf Kosten der Benutzerfreundlichkeit geht.⁵ Doch der Ertrag ist, dass der schlimmste Fall aufhört, katastrophal zu sein. Eine Kompromittierung heißt nicht länger „sie besitzen meinen Computer”. Sie heißt „sie besitzen einen Einwegraum, den ich gleich löschen werde”.

Die Plattform aufbrechen: Blue Pill, SMM und die Evil Maid

Sie können keine guten Isolationsgrenzen entwerfen, bevor Sie genau wissen, welche Grenzen falsch sind, und Rutkowska lernte das, indem sie sie angriff. Blue Pill, ihre Black-Hat-Demonstration von 2006, ist der klarste Fall. Es war ein Proof-of-Concept-Rootkit, das AMDs Hardware-Virtualisierung (AMD-V) ausnutzte, um etwas Verwegenes zu tun: einen dünnen Hypervisor auf einer laufenden Maschine zu starten und das lebende Betriebssystem im laufenden Betrieb in eine virtuelle Maschine darunter zu migrieren.³ Aus dieser VM heraus würde das Betriebssystem eine normale Welt sehen – doch der Hypervisor darunter konnte „Hardware-Interrupts, Datenanfragen und sogar die Systemzeit” abfangen und dem eingesperrten Betriebssystem beliebige Antworten zuspielen.³

Es lohnt sich, präzise zu sein, was Blue Pill war und was nicht. Es war ein Proof of Concept, keine in freier Wildbahn gefundene Schadsoftware, und seine kühnste Behauptung – dass ein solches Hypervisor-Rootkit „zu 100 % unentdeckbar” gemacht werden könne – war umstritten, wobei andere Forscher eine zeitbasierte Erkennung vorschlugen.³ Doch die umstrittene Schlagzeile ist nicht die Lehre. Die Lehre ist die Angriffsfläche, die es freilegte: die in jedes Betriebssystem eingebackene Annahme, dass die Schicht, auf der es läuft, gutartig ist. Blue Pill zeigte, dass Virtualisierung die privilegierteste Schicht zum Heimrevier des Angreifers machen konnte – und dass das, was Sie „unter” sich vertrauen, genau das ist, was Sie von „oben” nicht verifizieren können.

Derselbe Instinkt trieb den Rest ihrer offensiven Arbeit an. Mit Mitstreitern griff sie den System Management Mode an, den obskuren, hochprivilegierten Firmware-Modus, der unterhalb des Kernels läuft, und Intels Trusted Execution Technology, eine Funktion, deren ganzer Zweck es war, Vertrauen zu begründen.¹ Und 2009 prägte sie den Evil-Maid-Angriff: Lassen Sie einen verschlüsselten Laptop unbeaufsichtigt in einem Hotelzimmer, und ein „Zimmermädchen” mit kurzem physischem Zugriff kann den unverschlüsselten Bootloader so manipulieren, dass er Ihre Passphrase erfasst, wenn Sie sie das nächste Mal eintippen.⁴ Festplattenverschlüsselung wie TrueCrypt war verwundbar, weil sich der Boot-Code nicht gegenüber dem Benutzer authentifizieren konnte – Sie hatten keine Möglichkeit zu wissen, ob der Loader, der nach Ihrer Passphrase fragte, noch der Ihre war.⁴ Jeder einzelne dieser Angriffe ist die Kartierung einer Vertrauensgrenze, die nicht hielt. Die defensive Architektin, die später Qubes baute, wusste bereits von innen, welche Mauern tragend und welche aufgemalt waren.

Misstraue der Infrastruktur: die Trusted Computing Base verkleinern

Qubes ist nicht nur „führe alles in VMs aus”. Das tiefere Entwurfsprinzip ist das Minimieren und Misstrauen der Trusted Computing Base – der Menge von Komponenten, auf deren Korrektheit die Sicherheit des gesamten Systems ruht. Rutkowskas Keynote „Security Through Distrusting” formuliert die Philosophie unumwunden: Der herkömmliche Drang, Komponenten „vertrauenswürdig” zu machen, sei „allzu naiv und nicht skalierbar”, denn in der Sicherheit bedeute „vertrauenswürdig” in Wahrheit, dass eine Komponente „in der Lage ist, meine gesamte Sicherheitsintegrität zu zerstören”, falls sie schiefgeht.⁵ Die richtige Antwort ist, anzunehmen, dass jede einzelne Komponente kompromittiert sein könnte, fast allen zu misstrauen und so zu entwerfen, dass es keinen einzelnen Ausfallpunkt gibt.⁵

Dieses Prinzip lässt sich in den konkreten Entscheidungen von Qubes erkennen. Der Verwaltungsdomäne dom0 wird bewusst der Netzwerkzugriff verweigert, denn eine dom0, die über das Netzwerk erreichbar wäre, wäre ein einzelner Punkt, dessen Kompromittierung die Maschine besitzt.² Netzwerk und USB werden ihrerseits in eigene isolierte Qubes verlagert, sodass ein Fehler im Treiber einer Netzwerkkarte oder ein bösartiges USB-Gerät in einer Sandbox landet statt im Kernel, dem alles vertraut.² Dateien, die zwischen Domänen wechseln, werden defensiv behandelt – dieselbe „behandle es als potenziell gekapert”-Logik, die Rutkowska darauf anwandte, wie Qubes Bilder und PDFs verarbeitet.⁵ Und Einweg-Qubes verkörpern das Misstrauen am unmittelbarsten: Statt einem PDF-Reader zu vertrauen, dass er nicht ausgenutzt wird, nehmen Sie an, dass er es wird, führen ihn in einer VM aus, die Sie gleich zerstören, und lassen die Explosion in einem leeren Raum geschehen.²

Der rote Faden ist Demut gegenüber dem eigenen Code. Ein System, das einer großen, komplexen Komponente vertraut, geht eine große, komplexe Wette ein. Rutkowskas Architektur arbeitet daran, die Wette klein zu machen – die Trusted Computing Base auf einen dünnen Hypervisor und eine netzwerkisolierte dom0 zu schrumpfen und fast alles darüber als entbehrlich, ersetzbar und mutmaßlich feindlich zu behandeln.²⁵

Vom Desktop zur Dezentralisierung

Rutkowska leitete Qubes jahrelang und wandte sich dann dem umfassenderen Problem zu, das das Betriebssystem nur teilweise löst: Selbst ein perfekt kompartimentierter Desktop vertraut noch der Infrastruktur um ihn herum – dem Cloud-Speicher, dem Netzwerk, den Diensten, die Ihre Daten halten.¹⁵ Ihre spätere Arbeit bewegte sich hin zu Datenschutz und Dezentralisierung und dehnte dasselbe Misstrauen von der einzelnen Maschine nach außen auf die Systeme aus, mit denen sie spricht. Die genaue Gestalt und der Stand dieser Projekte sind am besten aus ihren eigenen aktuellen Schriften zu entnehmen, statt sie hier zu paraphrasieren; was sauber hinübergetragen wird, ist das Prinzip, nicht das Produkt. Der Instinkt ist konstant: Nimm an, die Infrastruktur sei kompromittiert, und entwirf so, dass diese Annahme dich so wenig wie möglich kostet.⁵

Die Methode

Lesen Sie quer durch Qubes, Blue Pill, die SMM- und TXT-Angriffe und „Security Through Distrusting”, und dieselben Grundhaltungen kehren wieder. Rutkowskas Methode ist weniger ein Slogan als ein Satz fester Gewohnheiten.

Nehmen Sie eine Kompromittierung an; entwerfen Sie für den Schadensradius. Der grundlegende Schritt besteht darin, einzuräumen, dass Prävention scheitern wird, und zu fragen, wie weit sich ein Einbruch ausbreitet.² Im großen Maßstab ist dies das sicherheitstechnische Gegenstück zu dem, was Werner Vogels für die Zuverlässigkeit tut – alles fällt ständig aus, also grenzen Sie den Schadensradius ein, statt vorzugeben, Sie könnten den Ausfall vermeiden. Die Lehre überträgt sich weit über Qubes hinaus: Entwerfen Sie nicht für den Fall, dass nichts hereinkommt; entwerfen Sie so, dass das, was hereinkommt, in einer kleinen, entbehrlichen Zelle gefangen ist. Es ist die Beweisschwelle, angewandt auf die Sicherheit – „bisher ist niemand eingebrochen” ist kein Beweis; „ein Einbruch hier kann dort nicht hinreichen” schon.

Misstrauen Sie der Infrastruktur und beweisen Sie die Grenze. Behandeln Sie jede Komponente als potenziell gekapert und verweigern Sie standardmäßig jedes Vertrauen.⁵ Das ist Thompsons „Reflections on Trusting Trust”, übersetzt in Desktop-Architektur: Sie können nicht vertrauen, was Sie nicht geprüft haben, also hören Sie auf, den Schichten zu vertrauen, die Sie nicht sehen können, und mauern Sie sie stattdessen ab. Die Disziplin besteht darin, von jeder Komponente zu fragen: „Wenn diese kompromittiert ist, was besitzt sie?” – und die Grenzen so lange neu zu ziehen, bis die Antwort lautet „fast nichts”.

Brechen Sie es selbst, bevor es ein anderer tut. Rutkowskas Verteidigung ruht auf einem Jahrzehnt der Offensive – Blue Pill, SMM, Evil Maid – denn man kann keine Grenze isolieren, deren Falschheit man nicht zuvor bewiesen hat.³⁴ Das ist genau der Instinkt, den Adi Shamir in die Kryptografie einbrachte: angreifen, um zu verteidigen, und nur dem vertrauen, was einen ernsthaften Versuch des Aufbrechens übersteht. Die feste Gewohnheit ist, zuerst den Hut des Angreifers aufzusetzen, zu kartieren, welche der eigenen Vertrauensannahmen Lügen sind, und die Mauern dort zu errichten, wo die Lügen waren.

Verkleinern Sie die Trusted Computing Base. Von je weniger Codezeilen Ihre Sicherheit abhängt, desto kleiner ist Ihre Wette.²⁵ Ein dünner Hypervisor und eine netzwerkisolierte dom0 sind eine prüfbare Wette; ein monolithischer Kernel mit jedem Treiber und Dienst innerhalb der Vertrauensgrenze ist eine blinde. Es ist das minimal würdige Produkt, angewandt auf das Vertrauen: Die sauberste Vertrauensbasis ist die kleinste, die ihre eine Aufgabe noch erfüllt. Reduzieren Sie das Vertrauen auf das, dem vertraut werden muss, und setzen Sie den Rest als feindlich voraus.

Seien Sie ehrlich über den Kompromiss. Rutkowska übertreibt nicht – sie sagt klar, dass Sicherheit durch Misstrauen „kein Allheilmittel” sei und Benutzerfreundlichkeit und Bequemlichkeit koste.⁵ Die Gewohnheit ist, den Preis der Sicherheit, die man kauft, zu benennen, statt ihn zu verbergen, damit der nächste Ingenieur ihn abwägen kann. Diese Offenheit ist Qualität ist die einzige Variable, angewandt auf die Sicherheit: Die echte Garantie, samt ihrer Kosten ausgesprochen, ist mehr wert als ein bequemes Versprechen, das insgeheim nicht hält. Eine Grenze, die Sie verstanden und gewählt haben, schlägt eine, die Sie angenommen und geerbt haben.

Einflusskette

Wer sie prägte

Die offensive Forschergemeinschaft der mittleren 2000er. Rutkowska stieg innerhalb der Plattform-Angriffskultur von Black Hat und des hardwarenahen Systems-Hackings auf, wo die Arbeit darin bestand, die Annahme zu finden, die niemand infrage stellte, und sie zu brechen.³ Der zentrale Reflex dieser Kultur – der Schicht zu misstrauen, der alle vertrauen – wurde zum Rückgrat ihrer defensiven Arbeit. (Prägender Einfluss)

Die Welle der Hardware-Virtualisierung. Blue Pill war nur möglich, weil AMD-V und Intel VT-x die Hardware-Virtualisierung gerade massentauglich gemacht hatten.³ Dieselbe Technologie, die sie 2006 als Waffe einsetzte, wurde zum Fundament, auf dem sie in Qubes die Isolation baute, wo Xen den Hypervisor vom Werkzeug des Angreifers zur Mauer des Verteidigers macht.¹² (Direkter Einfluss)

Die Linie der Xen- und Hypervisor-Sicherheit. Ihre Jahre der Analyse und des Angriffs auf Xen lehrten sie genau, wie stark – und wie zerbrechlich – die Hypervisor-Isolation ist; ein Wissen, das die Entscheidung von Qubes prägte, dom0 vom Netzwerk fernzuhalten und Treiber in isolierte Domänen zu verlagern.¹² (Prägender Einfluss)

Wen sie prägte

Datenschutzbewusstes Rechnen. Qubes wurde zum empfohlenen Desktop für Journalisten, Aktivisten und Sicherheitsforscher, die eine gezielte Kompromittierung annehmen müssen – ein echtes Werkzeug für Menschen, deren Bedrohungsmodell ein Staat ist, kein Slogan.²

Die Denkweise der Kompartimentierung. „Sicherheit durch Isolation” und „verkleinere die Trusted Computing Base” verbreiteten sich weit über Qubes hinaus in die Art, wie Sandboxing, Container-Isolation und anwendungsweise Virtualisierung in der gesamten Branche durchdacht werden.²⁵

Verteidiger, die zuerst brechen. Rutkowska ist ein stehendes Beispiel dafür, dass die stärksten defensiven Architekten oft ehemalige Angreifer sind – dass das Kartieren der echten Vertrauensgrenzen, indem man sie bricht, die Voraussetzung dafür ist, sie korrekt zu ziehen.³⁴

Der rote Faden

Rutkowska ist der Isolations-Schlussstein dieser Reihe – die Figur, die auf „das System wird durchbrochen werden” nicht mit Verzweiflung antwortet, sondern mit Architektur. Adi Shamir greift in der Kryptografie an, um zu verteidigen, und vertraut nur dem, was einen echten Versuch des Aufbrechens übersteht; Rutkowska durchläuft dieselbe Schleife eine Schicht tiefer, bricht Hypervisoren und Boot-Ketten, um einen Desktop zu bauen, der deren Kompromittierung übersteht.³⁴ Thompson und Ritchie gaben uns die Warnung, dass man nicht vertrauen kann, was man nicht selbst gebaut und geprüft hat; Rutkowskas „Misstraue der Infrastruktur” ist diese Warnung, verwandelt in ein laufendes Betriebssystem, in dem die nichtvertrauenswürdigen Schichten abgemauert statt erhofft werden.⁵ Und wo Werner Vogels sagt alles fällt ständig aus, also grenze den Schadensradius ein für die Zuverlässigkeit, sagt Rutkowska dasselbe für die Sicherheit: Radia Perlman entwarf Netzwerke unter der Annahme, dass der feindliche und ausfallende Fall das Entwurfszentrum ist, und Rutkowska entwirft Maschinen auf diese Weise. Wo Vogels eine ausfallende Festplatte eingrenzt und Perlman eine ausfallende Verbindung, sagt Rutkowska: Der Angreifer ist bereits drinnen – also isolieren Sie jede Domäne, misstrauen Sie jeder Schicht und machen Sie den Einbruch zu einem Einwegraum, den Sie wegwerfen können. (Reihenbrücke)

Was ich daraus mitnehme

Die Lehre, die ich von Rutkowska behalte, ist, für den Einbruch zu entwerfen, nicht gegen ihn. Mein Instinkt ist, wie der der meisten Bauenden, das Ding zu härten – die Eingabe zu validieren, die Abhängigkeit zu patchen, die Konfiguration abzuschließen – und Sicherheit als eine Mauer zu behandeln, die ich hoch genug zu machen versuche. „Jede Software enthält Fehler” ist die Zurechtweisung: Die Mauer wird durchbrochen werden, denn es gibt immer noch einen Fehler mehr, und die Frage, auf die es wirklich ankommt, ist, was der Angreifer erreicht, sobald er hinüber ist. Wenn ich heute etwas baue – eine Authentifizierungsgrenze, einen Dienst, der nichtvertrauenswürdige Eingaben ausführt, eine Funktion, die Geld berührt – versuche ich also zu fragen „Wenn das kompromittiert ist, wie groß ist der Schadensradius?”, bevor ich frage „Wie halte ich es draußen?”. Die ehrliche Version von sicher ist nicht „Ich kann nicht sehen, wie das bricht”. Sie ist „Wenn es bricht, ist der Schaden in einem Raum gefangen, den ich löschen kann”.

Die zweite Lehre ist vernünftige Paranoia gegenüber dem, dem ich vertrauen muss. Es ist leicht, eine Komponente als „vertrauenswürdig” durchzuwinken und weiterzumachen, aber Rutkowska hat dieses Wort für mich neu gerahmt: Etwas vertrauenswürdig zu nennen, heißt einzugestehen, dass es alles zerstören kann, falls es versagt. Das veränderte, wie ich Grenzen ziehe. Jede Bibliothek, die ich einbinde, jeder Dienst, von dem ich abhänge, jede Schicht, auf der ich laufe, ist eine Wette darauf, dass sie korrekt ist – und die Größe der Wette ist die Größe meiner Trusted Computing Base. Also versuche ich, diese Basis klein und prüfbar zu halten, das Riskante und das Komplexe in Sandboxes zu schieben, die ich als feindlich voraussetze, und ehrlich zu sein, so wie sie es ist, dass die Isolation mich Bequemlichkeit kostet. Die Paranoia ist kein Pessimismus. Sie ist die Disziplin, genau zu wissen, wem ich vertraue, und diese Liste so kurz zu machen, wie ich nur kann.

FAQ

Was ist Qubes OS?

Qubes OS ist ein freies, quelloffenes, sicherheitsorientiertes Desktop-Betriebssystem, geschaffen von Joanna Rutkowska und vom Projekt beschrieben als „ein angemessen sicheres Betriebssystem”.² Es nutzt den Xen-Hypervisor, um Ihr Rechnen in isolierte virtuelle Maschinen namens Qubes aufzuteilen – getrennte Kompartimente für Tätigkeiten wie Arbeit, Bankgeschäfte, privates Surfen und das Öffnen nichtvertrauenswürdiger Dateien. Weil die Qubes isoliert sind, kann eine Kompromittierung in einem die anderen nicht erreichen, sodass der Schaden eines jeden einzelnen Einbruchs eingegrenzt bleibt. Es unterstützt zudem Einweg-Qubes, die sich nach Gebrauch selbst zerstören, und gibt jeder Domäne einen fälschungssicheren farbigen Fensterrahmen, sodass Sie erkennen, zu welchem Kompartiment ein Fenster gehört.¹²

Was ist Sicherheit durch Isolation (Kompartimentierung)?

Sicherheit durch Isolation, oder Kompartimentierung, ist das Prinzip im Herzen von Qubes: Statt zu versuchen, Software fehlerfrei zu machen, nehmen Sie an, dass eine Kompromittierung geschehen wird, und grenzen den Schaden ein, indem Sie das System in isolierte Domänen aufteilen.² Die Einführung in Qubes zieht die Analogie zum physischen Leben – Sie trennen Tätigkeiten ganz natürlich in verschiedene Räume – und wendet sie auf einen Computer an, bei dem sonst alles eine Vertrauensgrenze teilen würde.² Die ergänzende Hälfte ist „Misstraue der Infrastruktur”: Behandle jede Komponente als potenziell kompromittiert, beseitige einzelne Ausfallpunkte und halte die Trusted Computing Base so klein wie möglich.⁵

Was war die Blue Pill?

Blue Pill war ein Proof-of-Concept-Rootkit, das Joanna Rutkowska am 3. August 2006 auf der Black Hat vorführte. Es nutzte AMDs Hardware-Virtualisierung (AMD-V), um einen dünnen bösartigen Hypervisor auf einer laufenden Maschine zu starten und das lebende Betriebssystem in eine virtuelle Maschine darunter zu migrieren, sodass der Hypervisor die Sicht des Betriebssystems auf Hardware, Interrupts und sogar die Systemzeit abfangen und fälschen konnte.³ Rutkowskas Behauptung, ein solches Rootkit könne „zu 100 % unentdeckbar” sein, war umstritten, wobei andere Forscher eine zeitbasierte Erkennung vorschlugen. Es war eine Forschungsdemonstration einer Angriffsfläche – der Annahme, dass die Schicht unter Ihrem Betriebssystem gutartig ist – keine in freier Wildbahn gefundene Schadsoftware.³

Was ist der Evil-Maid-Angriff?

Der Evil-Maid-Angriff ist eine Technik mit physischem Zugriff, die Joanna Rutkowska in einem Blogbeitrag von 2009 benannte. Erlangt ein Angreifer kurzen unbeaufsichtigten Zugriff auf einen unbeaufsichtigten, verschlüsselten Laptop – etwa in einem Hotelzimmer –, kann er den unverschlüsselten Boot-Code so manipulieren, dass er die Passphrase der Festplattenverschlüsselung des Benutzers heimlich erfasst, sobald sie das nächste Mal eingegeben wird.⁴ Festplattenverschlüsselungssysteme wie TrueCrypt waren verwundbar, weil sich der Bootloader nicht gegenüber dem Benutzer authentifizieren konnte, sodass das Opfer keine Möglichkeit hatte, den kompromittierten Loader vom legitimen zu unterscheiden.⁴ Es ist eine anschauliche Demonstration, dass Verschlüsselung allein eine Maschine nicht schützt, die ein Gegner physisch berühren kann.

Quellen