Linux ist Open Source. Der Kernel kann überprüft werden. Programme können selbst kompiliert werden. Firewalls können jedes ein- und ausgehende Paket kontrollieren.

Zumindest glauben wir das.

Denn tief unterhalb des Betriebssystems läuft auf vielen Intel-Systemen eine zweite, weitgehend unsichtbare Welt: die Intel Management Engine, heute Teil der Intel Converged Security and Management Engine (CSME).

Sie läuft unabhängig vom eigentlichen Betriebssystem, besitzt weitreichende Privilegien und ihre Firmware ist proprietär. Auf entsprechend ausgestatteten Systemen ermöglicht Intel Active Management Technology (AMT) sogar eine Netzwerkkommunikation außerhalb des normalen Betriebssystems.

Damit stellt sich eine unangenehme Frage:

Kann ein Computer wirklich als vertrauenswürdig gelten, wenn sein Eigentümer nicht die gesamte Software kontrollieren kann, die seine Hardware kontrolliert?

Ein Computer im Computer

Die Intel Management Engine ist kein gewöhnliches Programm unter Windows oder Linux.

Sie ist Teil der Plattform und arbeitet außerhalb des normalen Host-Betriebssystems.

Vereinfacht sieht ein moderner PC nicht nur so aus:

Programme
    ↓
Linux / Windows
    ↓
Kernel
    ↓
Hardware

Sondern eher so:

                 Anwendungen
                     ↓
               Linux / Windows
                     ↓
                   Kernel
                     ↓
        ┌────────────┴────────────┐
        │                         │
     Host-CPU                 ME / CSME
        │                         │
        │                  eigene Firmware
        │                         │
        └────────────┬────────────┘
                     ↓
                  Hardware

Damit existiert eine privilegierte Softwarekomponente, die der normale Benutzer nicht wie einen gewöhnlichen Dienst kontrollieren kann.

Und genau das macht die Sache sicherheitstechnisch interessant.

MINIX im Maschinenraum

2017 sorgte eine Erkenntnis für Aufmerksamkeit: Bestimmte Generationen der Intel Management Engine verwendeten eine angepasste Version von MINIX 3.

MINIX ist kein kleiner Hardwaretreiber, sondern ein echtes Betriebssystem auf Basis einer Microkernel-Architektur.

Das bedeutet allerdings nicht, dass auf jedem Intel-PC ein vollständiges gewöhnliches MINIX mit allen bekannten Diensten läuft. Intel verwendet eine speziell angepasste Firmwareumgebung.

Trotzdem verdeutlicht es die Größenordnung:

Wir sprechen nicht einfach über einige hundert Bytes Initialisierungscode.

Wir sprechen über eine komplexe Ausführungsumgebung tief innerhalb der Plattform.

Und sie kann kommunizieren

Besonders interessant wird die Sache bei Intel-Systemen mit vPro und Active Management Technology (AMT).

AMT wurde für die Fernverwaltung von Unternehmensrechnern entwickelt.

Administratoren können entsprechend konfigurierte Rechner unabhängig vom normalen Betriebssystem verwalten. Je nach Plattform und Konfiguration gehören dazu Funktionen wie:

• Ein- und Ausschalten eines Rechners
• Neustart
• Hardwareinformationen
• Serial over LAN
• Remote-KVM
• Storage- bzw. Media-Redirection
• Diagnose eines Rechners, dessen Betriebssystem nicht mehr funktioniert

Genau das ist der Sinn von Out-of-Band Management.

Das Unternehmensnetzwerk soll den Rechner noch erreichen können, wenn Windows oder Linux nicht mehr funktioniert.

Vereinfacht:

                    Netzwerk
                       │
                       ↓
                Netzwerkcontroller
                   /         \
                  /           \
                 ↓             ↓
             ME / AMT      Host-System
                 │             │
          Management        Linux
                               │
                            Firewall

Das ist für große Unternehmen ausgesprochen praktisch.

Es hat aber eine bemerkenswerte Konsequenz:

Nicht jede Netzwerkkommunikation einer solchen Plattform muss zwangsläufig durch den Netzwerkstack des Host-Betriebssystems laufen.

Eine Linux-Firewall kontrolliert das, was Linux kontrolliert.

Sie kann nicht automatisch garantieren, dass außerhalb ihrer eigenen Vertrauensdomäne keine andere Komponente kommuniziert.

Ist Intel ME deshalb eine Backdoor?

Nein.

Zumindest gibt es keinen öffentlich belastbaren Beweis dafür, dass Intel ME als geheime Backdoor für einen Geheimdienst entwickelt wurde.

Und genau hier muss eine seriöse Betrachtung sauber unterscheiden zwischen:

nachgewiesenen Eigenschaften

und

möglichen Schlussfolgerungen daraus.

Dass eine Technologie theoretisch für Überwachung oder Sabotage geeignet sein könnte, beweist nicht, dass sie dafür entwickelt wurde oder tatsächlich dafür verwendet wird.

Doch damit verschwindet das eigentliche Problem keineswegs.

Denn aus Sicht der Computersicherheit stellt sich eine fundamentalere Frage:

Warum muss ich Intel überhaupt vertrauen?

Die Blackbox im eigenen Rechner

Linux kann untersucht werden.

Der Linux-Kernel besitzt öffentlich verfügbaren Quellcode.

Dasselbe gilt für GCC, Clang und unzählige andere Bestandteile eines freien Betriebssystems.

Man kann theoretisch den Quellcode untersuchen, verändern und selbst übersetzen.

Bei einer proprietären Plattformkomponente sieht die Situation anders aus.

Der Eigentümer besitzt nicht ohne Weiteres eine vollständige überprüfbare Kette:

Quellcode
    ↓
Audit
    ↓
reproduzierbarer Build
    ↓
Binary
    ↓
ausgeführte Firmware

Damit entsteht eine Blackbox innerhalb der sogenannten Trusted Computing Base.

Das bedeutet ausdrücklich nicht, dass sich darin zwangsläufig etwas Bösartiges befindet.

Es bedeutet etwas viel Grundsätzlicheres:

Der Eigentümer kann es nicht vollständig selbst ausschließen.

Ken Thompson lässt grüßen

Das Problem erinnert an eine der berühmtesten Überlegungen der Informatikgeschichte.

Ken Thompson, einer der Entwickler von Unix, beschrieb 1984 in seinem Vortrag „Reflections on Trusting Trust“ einen erschreckend eleganten Angriff.

Man stelle sich einen manipulierten C-Compiler vor.

Dieser erkennt beim Übersetzen eines Login-Programms:

if compiling(login.c)
    insert_backdoor();

Natürlich würde ein Auditor diese Manipulation im Compiler-Quellcode finden.

Also geht Thompson einen Schritt weiter.

Der manipulierte Compiler erkennt zusätzlich, wenn er seinen eigenen Compiler übersetzt:

if compiling(compiler.c)
    insert_compiler_backdoor();

Jetzt kann man beide Manipulationen aus dem sichtbaren Quellcode entfernen.

Der Compiler bleibt trotzdem infiziert.

Denn beim nächsten Übersetzen erzeugt der bereits manipulierte Compiler erneut einen manipulierten Compiler.

sauberer Compiler-Source
          │
          ↓
manipulierter alter Compiler
          │
          ↓
manipulierter neuer Compiler
          │
          ↓
sauberer Source
          │
          ↓
wieder manipulierter Compiler

Die Backdoor existiert schließlich in keinem sichtbaren Quellcode mehr.

Thompsons eigentliche Botschaft war größer als dieser konkrete Angriff:

Irgendwo muss Vertrauen beginnen.

Und genau dieses Problem begegnet uns auf der Hardwareebene erneut.

Open Source allein reicht nicht

Selbst ein vollständig freies Betriebssystem löst das Problem deshalb nicht vollständig.

Man könnte besitzen:

Firefox
   ↓
Open Source

Linux
   ↓
Open Source

GCC
   ↓
Open Source

coreboot
   ↓
weitgehend Open Source

Doch darunter befinden sich weiterhin Komponenten wie:

CPU-Microcode

Firmware des SSD-Controllers

Firmware des Netzwerkcontrollers

UEFI-Komponenten

TPM

Management-Prozessoren

Hardware selbst

Die entscheidende Frage lautet deshalb nicht nur:

„Ist mein Betriebssystem Open Source?“

Sondern:

Wie weit reicht meine überprüfbare Vertrauenskette tatsächlich?

Warum wurde ME überhaupt entwickelt?

Intel hat dafür durchaus nachvollziehbare technische Anwendungsfälle.

Ein Unternehmen mit beispielsweise 30.000 Arbeitsplatzrechnern möchte einen defekten Rechner möglicherweise fernwarten können.

Der Administrator möchte ihn einschalten können.

Er möchte möglicherweise eine Diagnose durchführen, obwohl Windows nicht mehr startet.

Genau dafür ist Out-of-Band-Management hervorragend geeignet.

Doch daraus folgt eine weitere Frage:

Warum muss eine solche Funktion für den Eigentümer weitgehend eine proprietäre Blackbox sein?

Fernwartung und Open Source schließen sich technisch nicht gegenseitig aus.

Auch eine vom Eigentümer kontrollierte Deaktivierungsmöglichkeit wäre grundsätzlich denkbar.

Man hätte beispielsweise eine Architektur entwickeln können wie:

Management Engine

[✓] notwendige Plattforminitialisierung

[ ] Remote Management

[ ] Netzwerkzugriff

[ ] KVM

[ ] Storage Redirection

[ ] zusätzliche Managementdienste

mit einem Hardware-Schalter oder einer vom Eigentümer kontrollierten Firmwarekonfiguration.

Stattdessen wurde eine Architektur geschaffen, bei der bestimmte Plattformfunktionen eng mit einer proprietären Firmwareumgebung verbunden sind.

Für ein Sicherheitsmodell, in dem der Eigentümer die oberste Vertrauensinstanz seines Computers sein soll, ist das zumindest diskussionswürdig.

Der interessante HAP-Modus

Besonders interessant wurde die Diskussion durch einen Mechanismus, der als HAP bzw. AltMeDisable bekannt wurde.

HAP wird mit High Assurance Platform in Verbindung gebracht – also besonders abgesicherten Systemen für Regierungsumgebungen.

Sicherheitsforscher fanden heraus, dass bestimmte ME-Versionen einen Mechanismus besitzen, mit dem wesentliche ME-Funktionen nach der notwendigen Initialisierung stillgelegt werden können.

Das ist bemerkenswert.

Denn damit stellt sich eine offensichtliche Frage:

Wenn eine reduzierte ME für besonders sicherheitskritische Systeme sinnvoll ist, warum erhält der gewöhnliche Eigentümer nicht dieselbe offiziell unterstützte Kontrolle?

Allein daraus folgt wiederum kein Beweis für eine Hintertür.

Aber es zeigt, dass die Diskussion über die Notwendigkeit einer permanent umfangreich aktiven Management Engine komplizierter ist als:

„Ohne sie funktioniert der Computer technisch einfach nicht.“

Eine unbequeme Hypothese

An dieser Stelle kann man eine weitergehende Hypothese formulieren.

Und sie sollte ausdrücklich als Hypothese, nicht als Tatsache verstanden werden.

In den frühen Jahrzehnten der Computerindustrie waren Betriebssysteme und zentrale Softwarekomponenten überwiegend proprietär.

Wer Einfluss auf einen Hersteller gewinnen konnte, konnte theoretisch Einfluss auf Software nehmen, die auf Millionen Rechnern eingesetzt wurde.

Doch freie Software veränderte dieses Modell.

Linux kann von Tausenden Entwicklern untersucht werden.

Manipulationen können entdeckt werden.

Distributionen können Software unabhängig bauen.

Reproduzierbare Builds können Binärdateien vergleichbar machen.

Was wäre also aus Sicht eines Nachrichtendienstes interessanter?

Das Betriebssystem?

Oder eine Ebene darunter?

                 Anwendungen
                      ↓
                 Open Source
                      ↓
                    Linux
                      ↓
                 Open Source
                      ↓
────────────────────────────────
           Vertrauensgrenze
────────────────────────────────
                      ↓
            proprietäre Firmware
                      ↓
              Management Engine
                      ↓
                  Hardware

Die Hypothese wäre:

Mit der zunehmenden Verbreitung freier und überprüfbarer Software könnte es für staatliche Akteure attraktiver geworden sein, Einfluss auf Ebenen unterhalb des Betriebssystems zu gewinnen.

Das wäre eine außerordentlich mächtige Position.

Doch gibt es dafür Belege?

Für Intel ME konkret bislang nicht.

Für staatliches Interesse an der Manipulation technischer Infrastruktur dagegen sehr wohl.

Clipper Chip: Die Hintertür war einmal offiziell

In den 1990er Jahren schlug die US-Regierung den sogenannten Clipper Chip vor.

Das Konzept sah verschlüsselte Kommunikation vor, bei der staatliche Stellen unter bestimmten Voraussetzungen Zugriff auf hinterlegte Schlüssel erhalten konnten.

Heute würde man dafür häufig den Begriff Key Escrow verwenden.

Das Entscheidende daran:

Die staatliche Zugriffsmöglichkeit war kein Gerücht.

Sie war Teil des Konzepts.

Die damalige „Crypto Wars“-Debatte zeigt deshalb eindeutig:

Nachrichtendienste und Regierungen haben ein reales strategisches Interesse daran, Zugriffsmöglichkeiten in weit verbreitete Kommunikationstechnologien einzubauen.

Dual_EC_DRBG: Wenn ein Standard verdächtig wird

Noch interessanter wurde es Jahre später.

Der kryptographische Zufallszahlengenerator Dual_EC_DRBG wurde unter Beteiligung der NSA standardisiert.

Kryptographen bemerkten früh eine merkwürdige Eigenschaft:

Bestimmte Konstanten des Algorithmus waren nicht nachvollziehbar gewählt worden.

Wenn jemand eine bestimmte mathematische Beziehung zwischen diesen Konstanten kannte, konnte daraus möglicherweise eine äußerst mächtige Hintertür entstehen.

Nach den Snowden-Enthüllungen wurde der Verdacht erheblich ernster.

Das Beispiel ist deshalb wichtig, weil es zeigt:

Ein Angriff muss nicht aussehen wie:

NSA_BACKDOOR = true;

Er kann sich als technische Designentscheidung, Parameterwahl oder Standard präsentieren.

Und dann kam Stuxnet

Noch deutlicher wird die strategische Bedeutung von Computersystemen beim Blick auf Stuxnet.

Die Schadsoftware wurde gezielt gegen iranische Urananreicherungsanlagen eingesetzt.

Sie manipulierte industrielle Steuerungen und beeinflusste dadurch physische Maschinen.

Damit war endgültig demonstriert:

Software
   ↓
Steuerungssystem
   ↓
Industrieanlage
   ↓
physische Wirkung

Cyberangriffe können Maschinen nicht nur ausspionieren.

Sie können physische Infrastruktur manipulieren und beschädigen.

Stuxnet benötigte dafür keine nachgewiesene universelle Intel-Hintertür.

Gerade deshalb sollte man das Beispiel nicht als Beweis gegen Intel interpretieren.

Es zeigt vielmehr etwas anderes:

Staaten besitzen sowohl das Interesse als auch die Ressourcen, komplexe technische Lieferketten für strategische Zwecke anzugreifen.

Was wissen wir – und was vermuten wir?

An dieser Stelle ist eine klare Trennung notwendig.

Gut belegt

• Intel ME/CSME ist eine privilegierte Firmwareumgebung.
• Wesentliche Teile sind proprietär.
• Bestimmte Generationen verwendeten MINIX 3.
• Intel AMT ermöglicht auf geeigneten und entsprechend konfigurierten Plattformen Out-of-Band-Management.
• Dieses Management funktioniert unabhängig vom normalen Host-Betriebssystem.
• In ME/CSME wurden bereits schwerwiegende Sicherheitslücken gefunden.
• Bestimmte Plattformen besitzen Mechanismen zur Reduzierung bzw. Deaktivierung wesentlicher ME-Funktionen.
• Nachrichtendienste haben historisch versucht, Einfluss auf Kryptographie und technische Standards zu nehmen.
• Staaten führen offensive Cyberoperationen durch.
• Manipulationen von Software und technischen Lieferketten gehören zu realen Angriffsszenarien.

Nicht belegt

Nicht öffentlich bewiesen ist dagegen:

• dass Intel ME im Auftrag der NSA entwickelt wurde,
• dass Intel ME eine geheime universelle Geheimdienst-Backdoor enthält,
• dass Geheimdienste beliebige Intel-Rechner über ME kontrollieren können,
• dass Intel ME für Sabotage fremder Staaten entwickelt wurde.

Diese Unterscheidung ist wichtig.

Denn eine starke Sicherheitskritik benötigt diese Behauptungen überhaupt nicht.

Das eigentliche Problem ist Vertrauen

Nehmen wir für einen Moment an, Intel sei vollkommen vertrauenswürdig.

Nehmen wir außerdem an, dass kein Geheimdienst jemals Einfluss auf die Management Engine genommen hat.

Das grundlegende Problem bleibt trotzdem bestehen.

Der Eigentümer kann nicht vollständig selbst verifizieren, was sämtliche privilegierten Komponenten seines Rechners tun.

Damit verändert sich die Frage.

Nicht:

„Ist Intel ME eine NSA-Backdoor?“

Sondern:

„Warum sollte ein sicherer Computer überhaupt eine privilegierte Blackbox benötigen, die sein Eigentümer nicht vollständig kontrollieren kann?“

Das ist die wesentlich stärkere Frage.

Denn sie benötigt keine Verschwörungstheorie.

Sie benötigt lediglich ein bestimmtes Verständnis von Eigentum und Computersicherheit.

Wem gehört die Root of Trust?

Ein gewöhnliches Verständnis von Eigentum lautet:

Wenn ich einen Computer kaufe, gehört er mir.

Aus technischer Sicht ist die Situation komplizierter.

Ich kontrolliere vielleicht:

meine Dateien
meine Programme
mein Linux
meinen Kernel
meine Firewall

Aber möglicherweise nicht vollständig:

CPU-Microcode
Management-Firmware
SSD-Firmware
Netzwerk-Firmware
Secure-Boot-Schlüssel
Hardware-Root-of-Trust

Damit entsteht eine fundamentale Frage für die Zukunft des Computing:

Soll die Root of Trust beim Hersteller liegen – oder beim Eigentümer des Gerätes?

Hersteller argumentieren mit Integrität, Schutz vor Malware, DRM, Unternehmensmanagement und Plattformstabilität.

Aus Sicht des Eigentümers lässt sich dagegen argumentieren:

Ein Sicherheitsmechanismus, den ich nicht kontrollieren kann, schützt möglicherweise das System – aber er gehört nicht vollständig zu meinem Vertrauensmodell.

Der perfekte Angriff müsste niemals entdeckt werden

Und damit kommen wir zurück zu Ken Thompson.

Die gefährlichste Hintertür wäre nicht unbedingt diejenige, die Sicherheitsforscher irgendwann finden.

Die perfekte Hintertür wäre eine, deren Existenz sich aus dem sichtbaren System überhaupt nicht zuverlässig ableiten lässt.

Genau deshalb war Thompsons Gedankenexperiment so einflussreich.

Er zeigte:

Quellcode allein ist kein Beweis für das Verhalten eines Computers.

Vier Jahrzehnte später ist diese Erkenntnis vielleicht relevanter denn je.

Denn moderne Computer bestehen nicht mehr nur aus einer CPU, RAM und einem Betriebssystem.

Sie bestehen aus einem ganzen Ökosystem voneinander abhängiger Prozessoren und Firmwarekomponenten.

                   Benutzer
                      │
                      ▼
                  Programme
                      │
                      ▼
                    Linux
                      │
                      ▼
                   Kernel
                      │
                      ▼
                  Firmware
                 /    |    \
                /     |     \
             CSME    SSD    NIC
                \     |     /
                 \    |    /
                      ▼
                   Microcode
                      │
                      ▼
                    CPU
                      │
                      ▼
               physische Hardware

Jede Ebene erweitert die Vertrauenskette.

Und jede nicht überprüfbare Ebene verlangt Vertrauen.

Sicherheit beginnt mit Kontrolle

Vielleicht lautet deshalb die wichtigste Frage nicht:

„Hat mein Computer eine Backdoor?“

Diese Frage lässt sich bei einer hinreichend gut versteckten Backdoor möglicherweise niemals endgültig beantworten.

Die bessere Frage lautet:

„Welche Komponenten meines Computers muss ich blind vertrauen?“

Je länger diese Liste wird, desto weniger kann der Eigentümer die Sicherheit seines eigenen Systems selbst beweisen.

Intel ME ist deshalb unabhängig von jeder Geheimdiensthypothese ein faszinierendes Beispiel für ein grundsätzliches Problem moderner Computerarchitektur.

Wir haben enorme Fortschritte bei freier Software gemacht.

Wir können Betriebssysteme untersuchen.

Wir können Compiler vergleichen.

Wir können reproduzierbare Builds erzeugen.

Wir können Netzwerkverkehr analysieren.

Doch irgendwann erreicht diese Transparenz eine Grenze.

Und hinter dieser Grenze beginnt Firmware, die wir nicht geschrieben haben, nicht vollständig überprüfen können und teilweise nicht entfernen dürfen.

Vielleicht ist deshalb die entscheidende Sicherheitsfrage des modernen Computers nicht, welchem Betriebssystem wir vertrauen.

Sondern:

Wer kontrolliert die unterste Ebene der Maschine?

Denn wer diese Ebene kontrolliert, definiert letztlich, wem der Computer wirklich gehorcht.