Schutz vor kryptographischen Backdoors Open Source macht Hintertüren transparent

Unternehmen setzen häufig auf herstellerspezifische Software, um Daten zu verschlüsseln und User zu authentifizieren. Doch das ist riskant, weil der Druck auf Hersteller wächst, Hintertüren in ihre Software einzubauen. Einen Ausweg bietet Open-Source-Software.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

KeyIdentity GmbH

Hackern ist es ein Dorn im Auge, wenn Unternehmen Authentifizierungslösungen mit starker Verschlüsselung einsetzen. Das macht es komplizierter, Accounts von Mitarbeitern zu übernehmen und Geschäftsdaten zu entwenden. Doch nicht nur Kriminelle wünschen sich in solchen Fällen eine Hintertüre in Authentifizierungs- und Verschlüsselungslösungen. Auch die Polizei, Geheimdienste und Finanzbehörden fordern in zunehmendem Maße, dass die Anbieter von Sicherheitssoftware Backdoors in ihre Lösungen einbauen – und den Schlüssel oder eine Zugangsmöglichkeit bei Behörden deponieren.

So kritisierte Bundesinnenminister Thomas de Maizière Ende November 2016 in einem Interview die steigende „missbräuchliche Verwendung der Verschlüsselung durch Kriminelle“ und verlangte verbesserte Zugriffsmöglichkeiten von Behörden auf solche Daten. Auch der neue US-Präsident Donald Trump forderte IT-Unternehmen auf, Backdoors in Verschlüsselungsprogramme zu integrieren, über die sich amerikanische Behörden Zugang zu Informationen Verdächtiger verschaffen können.

Zero Day Exploits und Vorgehensweisen

Wikileaks enthüllt Hacking-Tools der CIA

Hintertüren blieben nicht geheim

Ein Problem bei solchen Ansätzen ist, dass sich solche Hintertüren nicht auf Dauer vor Hackern verbergen lassen; Fälle wie die Veröffentlichung der CIA- und NSA-Hacking-Tools durch Wikileaks und die Shadow Broker belegen dies. Die mögliche Folge: Unbefugte erhalten Zugang zu vertraulichen Daten von Unternehmen und öffentlichen Einrichtungen. Für ein Unternehmen kann es den Ruin bedeuten, wenn Forschungs- und Finanzinformationen bei einem Mitbewerber in Fernost landen. Und ein Bürger verliert das Vertrauen in staatliche Stellen, wenn plötzlich seine Steuererklärung für alle sichtbar im Internet auftaucht.

Doch was tun? Die Lösung heißt Transparenz. Unternehmen müssen nachprüfen können, ob eine Sicherheitssoftware kryptographische Schlupflöcher enthält. Das setzt voraus, dass der Quellcode jedermann zugänglich ist – wie bei Open-Source-Lösungen. Dadurch haben IT-Sicherheitsfachleute eines Unternehmens die Möglichkeit, die Software selbst in Augenschein zu nehmen und eine Auditierung durchzuführen. Nur dann, wenn Fachleuten der Quellcode vorliegt, können sie erkennen, ob die Startpunkte beziehungsweise die Kurvenparameter einer Lösung sauber gewählt wurden oder ob darin beispielsweise ein Nobody-but-us-Backdoor (Nobus) verbirgt.

Die meisten anderen Schwachpunkte lassen sich durch eine Kombination von Penetrationstest, dynamischer Analyse oder Fuzzing finden. Die Grundlage bilden statische und dynamische Code-Analysen in Verbindung mit einer Untersuchung des Datenflusses und der verwendeten kryptographischen Algorithmen sowie Kryptographie-Parameter. Immer häufiger werden Hintertüren dabei durch die geschickte Wahl von kryptographischen Parametern realisiert.

Software-Escrow-Verträge helfen nur bedingt

Bei Open-Source-Software können IT-Fachleute diese, sofern erforderlich, an spezielle Anforderungen des Unternehmens anpassen beziehungsweise die Lösung erweitern. Auch im Falle von „Bugs“, die de facto in jeder Software vorhanden sind, können IT-Fachleute schneller und selbstständig reagieren, bevor ein „offizieller“ Patch erscheint. Neben dem permanenten Zugriff auf den aktuellen Source Code – auch ohne Software Escrow – unterbleiben somit auch komplexe Verträge sowie die damit verbundenen Kosten. In jedem Fall ist dieses Modell flexibler als der Ansatz von Anbietern mit proprietären Lösungen.

Bei geschlossener Software ist es beispielsweise für Nutzer nicht oder nur in begrenztem Maße möglich, den Code zur prüfen, etwa im Rahmen von Software-Escrow-Verträgen. Sie sehen vor, dass ein Software-Anbieter den Quellcode bei einem neutralen Dritten hinterlegt. Nutzer können dann unter bestimmten Voraussetzungen den Code einsehen, etwa dann, wenn der Anbieter insolvent wird und die Software für den Nutzer von geschäftskritischer Bedeutung ist. Allerdings ist Software-Escrow umstritten. Denn naturgemäß wollen Software-Anbieter Externen keinen Zugang zu ihrem Know-how gewähren. Daher sind Escrow-Abkommen meist mit juristischen Hürden gespickt.

Des Weiteren ist bei Software-Escrow ein hoher „bürokratischer“ Aufwand nötig. Denn ohne regelmäßige Prüfung, ob es sich bei dem hinterlegten Source-Code um die aktuelle Version handelt und ob sich damit die eingesetzte Software nachbauen lässt, kann man Software-Escrow im Grunde gleich sein lassen. Denn sonst droht die Gefahr, dass der Nutzer dann, wenn er auf Software-Escrow zugrückgreifen muss, einen unvollständigen oder völlig veralteten Code vorfindet, möglicherweise sogar beides. In diesem Fall gilt dasselbe wie für jede Business-Continuity-Maßnahme: Wurde sie nicht getestet, wird sie dann, wenn man benötigt, nicht funktionieren.

Leaks der Shadow Broker

Tausende Computer durch NSA-Hackertools infiziert

Code-Basis: Geheim versus offen

In der Regel müssen Nutzer von proprietären IT-Sicherheitslösungen daher auf die Zusicherungen der Anbieter vertrauen. Bestenfalls stehen Ergebnisse von Black-Box-Sicherheitstests zur Verfügung. Ob eine Anwendung ein Backdoor enthält, können Normalanwender in der Regel nicht ermitteln. Bei Open-Source-Lösung ist ein solches Versteckspiel erheblich schwerer.

Auch das Argument, eine geschlossene, proprietäre Software sei für Hacker nicht so leicht auf Schwachstellen hin zu analysieren wie quelloffener Code, ist nicht haltbar. So haben Angreifer heute die technischen Möglichkeiten, innerhalb von Minuten ein Reverse-Engineering von Patches durchzuführen, und das ohne Detailkenntnisse des Codes. Auf Basis der Resultate können sie anschließend Exploits erstellen. Entsprechende Reverse-Engineering-Tools wie Apktool oder diStorm3 sind frei verfügbar.

Auch Open-Source-Lösungen sind nicht perfekt

Die Sicherheit einer Lösung hängt nicht primär davon ab, ob diese Open Source ist oder ob es sich um proprietäre Lösungen handelt. Dass auch Open-Source-Code Sicherheitsschwachstellen aufweisen kann, zeigten beispielsweise die Heartbleed-Sicherheitslücke im OpenSSL-Stack und die GNU Bash Remote Code Execution Vulnerability, kurz Shellshock. Die letztgenannte Schwachstelle war 25 Jahre lang in der Bash-Shell vorhanden, die in Unix, Linux und Mac OS zum Einsatz kommt.

Ein Jahr nach Heartbleed

Viele Server immer noch verwundbar

Sichere Entwicklungsprozesse und geschulte Entwickler notwendig

Ob eine Software sicher ist, hängt vielmehr davon ab, ob ein sicherer Software-Entwicklungsprozess mit in der Anwendungssicherheit geschulten Entwicklern und Technologien kombiniert wird - oder ob die Entwicklung ohne Struktur, Bedrohungsanalysen und technische Hilfsmittel wie einer statischen Code Analyse erfolgt.

Allerdings hat Open-Source-Software den Vorteil, dass sowohl jeder für sich selbst als auch die Community Risiken und Schwachstellen aufspürt und Lösungen erarbeitet. Das funktioniert, weil der Code einsehbar ist. Bei herstellerspezifischen Lösungen besteht zwar ein ebenso hohes Risiko wie bei Open Source, dass sie Schwachstellen enthalten. Nur ist der Nutzer in diesem Fall auf die Kompetenz und das Wohlwollen des Anbieters angewiesen, diese Lücken zu schließen. Ob und wann ein Software-Haus diese Aufgabe in Angriff nimmt, hängt maßgeblich von finanziellen Erwägungen ab. Dieser Aspekt spielt dagegen bei Anbietern von Open-Source-Software traditionell eine untergeordnete Rolle – zum Wohl der Nutzer.

Über den Autor: Dr. Amir Alsbih ist Chief Operation Officer bei KeyIdentity.

(ID:44719664)