Schutz vor kryptographischen Backdoors

Open Source macht Hintertüren transparent

| Autor / Redakteur: Dr. Amir Alsbih / Peter Schmitz

Politiker und Polizei fordern immer wieder Hintertüren für den Zugang zu verschlüsselten Daten und verschlüsselter Kommunikation.
Politiker und Polizei fordern immer wieder Hintertüren für den Zugang zu verschlüsselten Daten und verschlüsselter Kommunikation. (© beebright - Fotolia)

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.

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.

Wikileaks enthüllt Hacking-Tools der CIA

Zero Day Exploits und Vorgehensweisen

Wikileaks enthüllt Hacking-Tools der CIA

08.03.17 - Wikileaks hat eine neue Serie an Enthüllungen angekündigt. Unter dem Codenamen Vault 7 wollen die Aktivisten sensible Inhalte veröffentlichen, die Aufschluss über die Hacking-Aktivitäten der CIA geben. Als einer der Stützpunkte wird das US-Konsulat in Frankfurt genannt. lesen

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.

Tausende Computer durch NSA-Hackertools infiziert

Leaks der Shadow Broker

Tausende Computer durch NSA-Hackertools infiziert

03.05.17 - Die von den Shadow Brokers veröffentlichten Hacking-Tools und Zero-Day-Schwachstellen aus dem Fundus der NSA sind inzwischen weit verbreitet. Kriminelle Hacker nutzen sie aktiv für Attacken, gleichzeigt suchen Sicherheitsexperten fieberhaft nach Gegenmaßnahmen. lesen

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.

Viele Server immer noch verwundbar

Ein Jahr nach Heartbleed

Viele Server immer noch verwundbar

08.04.15 - Fast drei Viertel aller externen Server der Global 2000-Unternehmen sind noch immer für Hackerangriffe auf OpenSSL durch Heartbleed anfällig. Das zeigt eine Analyse des Sicherheits-Anbieters Venafi die im ersten Quartal 2015 durchgeführt wurde. lesen

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.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44719664 / Verschlüsselung)