Version 1.1, 02.01.2014
Der Einsatz von Kryptografie führt natürlich nur auf vertrauenswürdiger und sicherer Hard- und Software zu garantierter Sicherheit. Schon bei Linux kann man den Paranoia-Level beliebig hoch schrauben, aber bei der Hardware ist es dann völlig vorbei.
Wir alle setzen Hardware ein, die einerseits sonstwo entwickelt und produziert wurde und andererseits zum Großteil nicht mit großem Aufwand dagegen abgesichert wurde, auch von Leuten mit den Ressourcen der NSA nicht manipuliert werden zu können.
Ich sehe den Staat in der Pflicht – schon weil niemand sonst das leisten kann –, sowohl der Wirtschaft als auch seinen Bürgen den Zugang zu bezahlbarer und brauchbarer Hardware zu sichern, die garantiert sauber ist (Entwicklung, Produktion und Distribution). Das muss keine besonders leistungsfähige Hardware sein, aber man muss einen Rechner kaufen und wissen können: Jetzt bin ich auf der sicheren Seite.
Das ist heute de facto nicht möglich.
Notwendige, aber nicht hinreichende Bedingung ist, dass die Hardware open source ist – an dieser Stelle mal nicht notwendigerweise auch frei. Da man als Normalsterblicher die Integrität von Hardware nicht prüfen kann, muss diese durch einen über jeden Zweifel erhaben transparenten Prozess gefertigt werden. Auch die Auslieferung der Hardware muss man dabei im Auge behalten. Dafür ist es nicht erforderlich, dass der Staat als das Unternehmen auftritt, das die Fertigung durchführt; auch dies ließe sich über eine Ausschreibung und strengste Kontrolle machen, wodurch wettbewerbsrechtliche Probleme minimiert werden dürften, wobei schnödes EU-Recht allerdings sowieso hinter der Wahrung der nationalen Sicherheit zurückstehen dürfte, die hier zweifellos betroffen ist.
Es ist nicht erforderlich (und für die kleinen Länder auch gar nicht praktikabel), dass Deutschland so etwas im nationalen Alleingang macht. Eine gemeinsame Einrichtung dieser Art für die EU wäre ausreichend.
Nicht jede Hardware wird in einer derart gesicherten Variante benötigt, jedenfalls nicht mit derselben Wichtigkeit. Nötig erscheinen folgende Komponenten:
Smartcards und Kartenleser
Das bedarf wohl keiner Erläuterung.
Mainboards
Ein Mainboard dieser Kategorie muss eine Open-Source-Firmware haben, die (per Hardwareschalter) schreibschützbar und nur mittels kryptografischer Signatur aktualisierbar ist. Außerdem sollte es möglich sein, (wiederum per Hardwareschalter) jedweden Schreibzugriff auf Mainboardkomponenten (CMOS-RAM usw.) zu unterbinden, so dass man sicher sein kann, dass (von der Uhrzeit mal abgesehen) der Zustand des Systems nach einem Reset absolut identisch ist und es somit keinerlei Angriffspunkte für Manipulationen bietet.
So ein Board muss über I/O-Virtualisierung verfügen, um den möglichen Schaden durch unsichere Erweiterungshardware zu begrenzen. Es mag sinnvoll sein, einen USB-Controller mit reduziertem Funktionsumfang zu entwickeln.
Wünschenswert ist die Option, die Firmware die Hashwerte des Bootmediums (CD/DVD/UEFI-Bootpartition) ermitteln und anzeigen zu lassen, bevor von dem Medium gebootet wird.
USB-Sticks
Eine einfache Maßnahme zur Sicherung von Rechner ist: vom Netz nehmen. Aber Daten müssen sie natürlich mit dem Rest der Welt austauschen können. Dafür werden USB-Sticks benötigt, die sichere Controller und eine Open-Source-Firmware haben.
Netzwerk
Die Nutzung als Offline-Rechner ist zwar kostengünstig, aber nicht immer praktikabel. Deshalb wird irgendeine Form von Netzanbindung benötigt. Wenn die Entwicklung von Ethernet-Hardware, die sowohl gegenüber Manipulationen auf dem Netzwerkmedium als auch der durch Software auf dem Rechner resistent ist, zu teuer ist, mag es sinnvoll sein, Hardware für ein komplett neues, sehr einfaches Protokoll zu entwerfen: eine Art serieller Anschluss 2.0 – eben für sehr viel höhere Geschwindigkeiten. Solche Hardware könnte dann auch in einem unsicheren Rechner verbaut werden, der die Anbindung ans Netzwerk übernimmt.
Solche Netzwerkhardware mag auch Funktionen haben, die Softwareansätze untestützen, die Softwarefehler in Treibern oder dem Netzwerkstack abfangen sollen. Denkbar ist, dass die Hardware sich als zwei Komponenten (PCI functions) im System meldet und über beide dieselben Daten anliefert, so dass die Daten über zwei unterschiedliche Netzwerkimplementierungen eingelesen, verarbeitet und vor dem Weiterreichen verglichen werden können. Das Versenden von Daten könnte daran gebunden werden, dass beide Netzwerkimplementierungen versuchen exakt dieselben Daten zu verschicken.
Festplatten
Controller und Firmware der Festplatte müssen ebenfalls open source sein. Sehr viel einfacher dürfte dies bei SSDs sein. Die Festplatten müssen einen in Hardware aktivierbaren Schreibschutz haben. Sinnvoll erscheint auch die Möglichkeit, über einen Hardware-Umschalter jeweils nur bestimmte Teile des Speichers einzublenden (so dass man für unterschiedliche Systeme nicht mehrere Festplatten benötigt).
Funktionen, die nicht unbedingt im Betrieb benötigt werden, sowie die Schreibmöglichkeit auf den Firmware-Speicher (falls der nicht gerade sowieso in Hardware gesperrt ist) sollten von der Mainboard-Firmware deaktiviert werden, bevor das Betriebssystem gestartet wird. Firmware-Updates sollten nur in einem speziellen Bootmodus möglich sein (wenn man dafür überhaupt ein Betriebssystem braucht).
Bessere Festplatten könnten die Notwendigkeit vermeiden, sich für ein höheres Sicherheitsniveau einen zweiten Rechner zuzulegen. Die Firmware könnte die Kapazität der Platte in einem festen Verhältnis (z.B. 1:5) aufteilen. Beim Rechnerstart wäre dann (unveränderbar bis zum nächsten Abschalten der Versorgungsspannung, also dem Ausschalten des Rechners) zu entscheiden, ob die Platte im sicheren oder unsicheren Modus starten soll. Diese Auswahl könnte per UEFI erfolgen; in Hardware wäre der Aufwand erheblich höher, ohne angemessen höheren Nutzen. Im unsicheren Modus wäre nur der größere Teil der Platte sichtbar. Es wäre dem Betriebssystem unmöglich (Firmware-Bugs mal außen vor gelassen), auf den geschützten Teil zuzugreifen. Im sicheren Modus sind zwei Varianten denkbar (zwischen denen durchaus bei jedem Booten gewechselt werden könnte): Im einfachen Fall ist analog nur der kleinere Teil der Platte sichtbar. Allerdings mag es ab und zu nötig sein, Daten vom unsicheren Teil in den sicheren zu transferieren. Ob das nun auf direktem Weg oder per USB-Stick passiert, hat nur geringe Auswirkungen auf den potentiellen Schaden. Mit einem zweiten SATA-Port an der Platte wäre es möglich, eine Platte als zwei Platten einzublenden, wobei in geeigneter Weise zu verhindern wäre, dass vom unsicheren Teil gebootet werden kann.
CD-/DVD-/Blueray-Laufwerk
Weitgehend analog zu Festplatten.
Eingabegeräte
Auf Grund der Möglichkeiten, über die elektromagnetische Abstrahlung auf große Entfernung die Eingaben mitzulesen und der Unmöglichkeit für Privatpersonen und die meisten Unternehmen, sich durch physikalische Maßnahmen dagegen zu wehren, erscheint es sinnvoll, Eingabegeräte (zumindest Tastaturen) zu entwickeln, bei denen die Übertragung der Eingabedaten verschlüsselt und außerdem in einem stetigen Strom von Dummydaten versteckt wird. Die Tastenanschläge dürfen dann natürlich auch keine (als solche identifizierbaren) Abstrahlung verursachen (Optische Erfassung? Störsignale?) und sollten so weit wie möglich geräuschlos sein.
Diese gesicherte Übertragung könnte man einerseits dem Tastaturtreiber überlassen, sie andererseits auch softwaretransparent von dem eigenen USB-Controller erledigen lassen, so dass man kein angepasstes Betriebssystem benötigt.
Als Nebeneffekt könnte die Integrität der Übertragung gesichert werden.
Ausgabegeräte
Da die Anzeige von Daten am Bildschirm genauso problematisch ist, sollte (als Alternative oder Ergänzung zum normalen Bildschirm) eine auf die (Schwarz-Weiß-)Ausgabe der Linux-Konsole beschränkte Anzeige entwickelt werden, die durch die Art der Anzeige auf minimale (identifizierbare) Abstrahlung optimiert werden kann.
In einer ansonsten sicheren Umgebung sollte ein manipulierter Prozessor nur wenig Schaden anrichten können (insbesondere, wenn die auf ihm laufende Software jünger ist als er selber). Die Entwicklung eines Open-Source-Prozessors erscheint außerdem unrealistisch. Allerdings käme man dem über die Lizensierung und eigene Fertigung von ARM-Prozessoren schon nahe.