Original-URL des Artikels: https://www.golem.de/news/imho-zertifizierungen-sind-der-falsche-weg-1501-111906.html    Veröffentlicht: 26.01.2015 08:00    Kurz-URL: https://glm.io/111906

IMHO

Zertifizierungen sind der falsche Weg

In Firmware versteckte Malware ist ein Problem, Zertifizierungen dürften aber kaum dagegen helfen. Wer vertrauenswürdige Firmware möchte, muss offene Quellen, transparente Audits und reproduzierbare Buildprozesse fordern.

Mein Kollege Nico Ernst forderte jüngst hier in einem Kommentar, Schlussfolgerungen aus den neuen Erkenntnissen über in Firmware versteckte Malware zu ziehen und forderte zertifizierte Firmware-Images. Die Frage, wie sehr wir unserer Hardware vertrauen können, ist ein großes Problem. Aber wenn falsche Lösungen propagiert werden, richtet das möglicherweise mehr Schaden an als es nützt.

Die Problemlage ist bekannt: Was nützt die beste Software, wenn man der Hardware, auf der sie läuft, nicht vertrauen kann? Dabei kommt erschwerend hinzu, dass die auf der Hardware laufenden Firmwares heute immer komplexer und immer mehr werden. Genaugenommen ist es längst nicht mehr korrekt, bei unserer heutigen Hardware von Computern zu sprechen. Vielmehr handelt es sich bei jedem Laptop und jedem Smartphone um ein komplexes Netzwerk von Mini-Computern. Selbst so simple Geräte wie SD-Karten haben eigene Prozessoren und eigene Mini-Betriebssysteme, die für ihre Steuerung zuständig sind.

In all diesen Firmwares können bösartige Hintertüren versteckt sein und - vermutlich sogar das gravierendere Problem - alle diese Firmwares können kritische Sicherheitslücken enthalten.

Bausteine für sichere Firmware

Eigentlich ist klar: Wirklich vertrauen kann man dieser Firmware nur, wenn nachprüfbar ist, was sie tut. Und dafür benötigt man den Quellcode. Ein offener Quellcode alleine sorgt natürlich noch nicht für eine sichere Firmware, aber es ist ein wichtiger erster Schritt.

Die traurige Realität ist jedoch: Firmware mit offenen Quellen muss man heutzutage mit der Lupe suchen. Spricht man Hardwarehersteller darauf an, erhält man üblicherweise immer die gleichen Antworten: Man könne die Firmware überhaupt nicht offenlegen, weil dabei die Rechte von Drittherstellern betroffen seien. Und die unfreie Firmware sei notwendig zum Schutz der Geschäftsgeheimnisse.

Nur - die Frage sei erlaubt - was ist wichtiger: der Schutz der Geschäftsgeheimnisse oder die Sicherheit der IT-Infrastruktur? Wenn Hardwarehersteller diese Frage immer zulasten der Sicherheit beantworten, dann sagt das einiges darüber aus, wo die Probleme zu suchen sind.

Da Nico Ernst die Freigabe der Firmware-Quellcodes für unrealistisch hält, schlägt er stattdessen eine Zertifizierung der Firmware, beispielsweise durch das Bundesamt für Sicherheit in der Informationstechnik (BSI), vor. Doch eine Zertifizierung ist keine Alternative zu offenen Quellen.

Faktorisierbare RSA-Keys und Zufallszahlen mit Hintertür

Zertifizierungen können katastrophal fehlschlagen, wie diverse Beispiele aus der Vergangenheit zeigen. 2013 gelang es einem Team von Kryptographen, private RSA-Schlüssel von taiwanesischen Bürger-Chipkarten zu faktorisieren. Schuld daran war ein fehlerhafter Zufallszahlengenerator. Die Chipkarten waren FIPS- und Common-Criteria-zertifiziert. Was war hier passiert? Die Chipkarten hatten zwar einen zertifizierten Zufallszahlengenerator, dessen Nutzung war aber optional - er wurde schlicht nicht genutzt.

Noch absurder ist eine Episode aus der schier endlosen Geschichte um den NSA-kompromittierten Zufallszahlengenerator Dual EC DRBG. Dieser war einst Teil der FIPS-Zertifizierung und wurde somit auch in OpenSSL eingebaut. Nachdem durch die Snowden-Enthüllungen bekannt wurde, dass es sich bei Dual EC DRBG höchstwahrscheinlich um einen Algorithmus mit einer NSA-Hintertür handelte, wurde er aus OpenSSL entfernt. Dabei stellte man jedoch fest, dass der Algorithmus überhaupt nicht funktioniert hatte.

Nicht nur hatte die Zertifizierung dafür gesorgt, dass ein Algorithmus mit einer Geheimdienst-Hintertür in OpenSSL landete, im Zertifizierungsprozess wurde nicht einmal bemerkt, dass der Algorithmus fehlerhaft implementiert war. Ein doppelter Fehlschlag.



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)  (hab)


Verwandte Artikel:
Ultrabook: Dell hat das XPS 13 ruiniert   
(26.01.2018, https://glm.io/132406 )
Playstation: Firmware-Update bringt Supersampling und Elternkontrolle   
(08.03.2018, https://glm.io/133232 )
Incident Response: Social Engineering funktioniert als Angriffsvektor weiterhin   
(25.02.2018, https://glm.io/132972 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Verschlüsselte Telefonie: Signal ist das Redphone fürs iPhone   
(30.07.2014, https://glm.io/108222 )

© 1997–2019 Golem.de, https://www.golem.de/