Transparenz und offene Quellcodes

Dazu kommt: Staatliche Behörden, die Zertifizierungen durchführen, sind angesichts der Ereignisse der letzten Jahre nicht gerade vertrauenswürdiger geworden. Vom BSI etwa ist bekannt, dass es bis 2014 Geschäftsbeziehungen zum dubiosen französischen Zeroday-Händler Vupen unterhielt. Die Verquickung staatlicher IT-Sicherheitsinstitutionen mit Überwachungsmaßnahmen von Geheimdiensten ist nicht gerade geeignet, das Vertrauen in diese Institutionen zu stärken.

Ein weiteres Problem: Zertifizierungen werden in aller Regel nicht direkt von den entsprechenden Institutionen durchgeführt, sondern an externe Firmen ausgelagert. Eine Firma, die Zertifizierungen durchführt, will vor allem ihre Kunden zufriedenstellen. Sie hat eigentlich kein Interesse daran, besonders kritisch nachzuhaken und auch in Grenzfällen auf das Beheben von Sicherheitslücken zu bestehen.

Die Community springt ein

Ein Prozess, der wirklich Vertrauen in die Sicherheit von Firmwares schaffen soll, kommt ohne eine Offenlegung der Funktionalität und damit der Quellcodes nicht aus. Die offenen Quellen haben einen weiteren Vorteil: Üblicherweise verzichten Hardwarehersteller heute schon nach kurzer Zeit darauf, Sicherheitslücken in ihren Firmwares zu beheben und verweisen darauf, dass ältere Gerätegenerationen nicht mehr unterstützt werden. Mit offenen Quellcodes könnte in so einem Fall zumindest die Community dafür sorgen, dass es für wichtige Sicherheitslücken weiterhin Fixes gibt. Aus genau diesem Grund hat der IT-Sicherheitsexperte Dan Geer auf der letzten Black-Hat-Konferenz in Las Vegas gefordert, dass Unternehmen den Quellcode von Programmen, die nicht mehr unterstützt werden, offenlegen müssen.

Doch ein offener Quellcode reicht nicht aus, um für Sicherheit zu sorgen. Vielmehr sollten die Firmwares einem Audit durch eine entsprechende Fachfirma unterzogen werden. Auch hier bitte keine Geheimniskrämerei: Das Ergebnis des Audits sollte für jeden öffentlich einsehbar sein.

Reproduzierbare Buildprozesse

Als weiterer Baustein zu einer wirklich sicheren Firmware müsste zudem ein Beweis dafür vorliegen, dass die Firmware-Images auch wirklich dem Quellcode entsprechen, der veröffentlicht wurde. Einige freie Softwareprojekte, darunter beispielsweise Tor, nutzen bereits sogenannte reproduzierbare Buildprozesse. Die Idee: Der Compilevorgang der jeweiligen Software muss für jeden nachvollziehbar sein und es sollte am Ende bitidentisch das gleiche Binary herauskommen.

Doch selbst das reicht nicht aus, um zu verhindern, dass einzelnen Nutzern eine manipulierte Firmware untergeschoben wird. Denn die Prüfung des Buildprozesses werden nur einige wenige Nutzer durchführen. Gezielte Angriffe auf einzelne Nutzer würden vermutlich in den meisten Fällen nicht auffallen. Um das zu verhindern, wären öffentliche, überprüfbare Logs sinnvoll, in denen Prüfsummen der Firmware-Images hinterlegt werden. Solche Logs könnten mit ähnlichen Technologien wie die Bitcoin-Blockchain oder Certificate Transparency funktionieren. Durch einen Abgleich mit dem Log kann sich ein Nutzer vergewissern, dass er das gleiche Firmware-Image wie alle anderen Kunden erhält.

Alles unrealistisch?

Offener Quellcode, transparente Audits und reproduzierbare Builds: Ist das nicht alles komplett unrealistisch? Aus heutiger Sicht vermutlich ja. Doch gerade im Enterprise-Bereich haben die Hardwarehersteller in jüngster Zeit einiges an Vertrauen eingebüßt. Die Diskussionen darüber, ob man in den USA chinesischen Produkten trauen kann und ob man im Rest der Welt US-amerikanischen Produkten trauen kann, sind bekannt. Wenn die Industrie Vertrauen zurückgewinnen will, muss sie etwas dafür tun - auch wenn das nicht immer ganz einfach sein mag. Fragwürdige Zertifizierungen helfen nicht weiter, sie bergen vielmehr die Gefahr, dass sie als Placebo-Lösungen dienen und von wirklichen Fortschritten ablenken.

IMHO ist der Kommentar von Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach)