Informationssicherheit durch Obskurität

(openPR) Stuttgart, 03. Juni 2013 - Seit mehr als fünftausend Jahren versuchen Menschen, Nachrichteninhalte vor Außenstehenden zu verbergen. Die Anfänge der Kryptographie begannen mit der Ersetzung von Schriftzeichen, Hieroglyphen und dem Austausch von einzelnen Buchstaben. Die Epoche der Verschlüsselung durch den Computer wurde 1976 mit der Veröffentlichung einer Methode zur sicheren Schlüsselverteilung eingeläutet. Im Aufsatz „New Directions in Cryptography“ publizierten Diffie und Hellman eine neuartige Methode zur öffentlichen Verteilung geheimer Schlüssel für die abhörsichere Übermittlung von Nachrichten. Der nach ihnen benannte Diffie-Hellman-Schlüsselaustausch legte die Grundlage des heute nahezu überall verwendeten Public-Key-Verfahrens zur Gewährleistung des sicheren Datenaustauschs im Internet.

OpenSSL (Secure Socket Layer), eine der am meisten verwendeten Open Source Komponenten zur Sicherung von Datenverbindungen im Internet, rückte mit dem Bekanntwerden der Sicherheitslücke „Heartbleed“ in den Fokus. Plötzlich sah sich ein Softwareanbieter jüngst dazu veranlasst, die Qualität seines Produktes mit der abwertenden Darstellung von Open Source Software anzupreisen. Die Flucht nach vorne trat der Anbieter offenbar an, um Antwort auf kritischen Fragen nach der Sicherheit seiner proprietären Lösung zu finden.

Der Hersteller argumentiert die Sicherheit seiner Software paradoxerweise mit der Geheimhaltung des Quellcodes; Zitat: „Was hält der Leser davon, für sicherheitskritische Funktionen Open Source zu verwenden, wo jeder der hacken will, ganz bequem im Sourcecode suchen kann, wie das Ganze funktioniert und ob er nicht eine Schwachstelle findet“. Sicherheit durch Obskurität. Das entspräche in etwa der Vorgehensweise eines Herstellers von Türschlössern, die Einbruchsicherheit seiner Produktes mit einem geheimen Mechanismus zu erklären. Die Dechiffrierung des Enigma Codes, DeCSS, AACSS, die GSM Mobilfunkverschlüsselung A5, die EC Karte und andere proprietäre Verfahren wurden allesamt geknackt, meist nicht von Sicherheitsexperten, sondern von „Hackern“.

Der Grund warum die in SSL zum Tragen kommenden Verschlüsselungsverfahren als unvermindert sicher gelten, ist dem Umstand zu verdanken, dass die verwendeten Algorithmen offen gelegt, offen evaluiert und als quelloffene Software implementiert wurden. Ein Hersteller, der von sich behauptet, eine fehlerfreie Sicherheitssoftware anzubieten, deren Prüfung durch unabhängige Experten mit der Nicht-Offenlegung des Codes jedoch verhindert, scheut die Veröffentlichung in der Regel aus drei Gründen: die Softwarequalität entspricht nicht den gängigen Standards, die Software verwendet bzw. basiert auf bereits existierender Software (meist Open Source) und die verwendeten Algorithmen bieten dem Hersteller einen Wettbewerbsvorteil. Letzteres kann ausgeschlossen werden, da die zur Anwendung kommenden Verfahren standardisiert und frei verfügbar sind.

Ist es Taktik oder mangelt es an fachlicher Kompetenz? Oder warum lässt der Softwareanbieter außer Acht, dass die Entdeckung des OpenSSL Fehlers auf Neel Mehta, einem Google Softwareingenieur, zurückzuführen ist. Bevor die Lücke ausgenutzt wurde, wurde sie publiziert und behoben. Gerade weil OpenSSL eine quelloffene Software ist, war es möglich, die Lücke zu finden und zu schließen. Vom Anbieter unerwähnt bleibt zudem auch die Tatsache, dass OpenSSL in einer zertifizierten (FIPS-140) und als Open Source Software frei erhältlichen Version verfügbar ist, die die kritische Lücke nie enthalten hat (RHEL, SuSE u.a.).

Die Zertifizierung einer Verschlüsselungskomponente ergibt jedoch noch keine sichere Anwendung. So schreibt Autor Dr. Marcus Heitmann in seinem Buch IT-Sicherheit in vertikalen F&E-Kooperationen der Automobilindustrie: „Nominative Werke wie FIPS-140 oder Common Criteria sind eher dazu geeignet, Produkte zu evaluieren oder zu zertifizieren. Ein derartiges Zertifikat kann teilweise auch trügerisch wirken. So entspricht eine Zertifizierung eines Produktes nach Evaluation Assurance Level (EAL) ungefähr einem ISO 9000-Zertifikat. Dies bedeutet, dass das Produkt nach einem gewissen Qualitätsstandard entwickelt wurde (z. B. Dokumentation). Gleichzeitig bedeutet dies aber nicht, dass das Produkt höhere Sicherheitsanforderungen erfüllt oder gar als „sicher“ zu bezeichnen ist.“

Wem trauen wir also mehr zu, die Informationssicherheit im Internet zu gewährleisten? Einem Anbieter, der die Sicherheit seiner Lösung mit der Geheimhaltung des Quellcodes zu erklären versucht, oder dem kontinuierlichen Code Review quelloffener Software durch Sicherheitsexperten in Unternehmen, für die Informationssicherheit von grundlegender Bedeutung ist? Nebenbei bemerkt, benötigt die Software des besagten Anbieters eine JAVA Umgebung, die im Fall von OpenJDK eine Open Source Software ist. Trotz aller Kritik an Open Source und OpenSSL scheint das Vertrauen des Anbieters in OpenSSL ausreichend groß gewesen zu sein, um es für den eigenen Webauftritt zu nutzen und dafür keine kostenpflichtige proprietäre Lösung zu erwerben. Auf die weite Verbreitung von Open Source in sicherheitskritischen Bereichen hat die IT-Branche inzwischen reagiert und einen Fond für wichtige Open-Source-Projekte eingerichtet.

OpenSSL wird eines der ersten Projekte sein, das Geldmittel aus der Core Infrastructure Initiative erhält. Auch bei der jetzigen Förderung der OpenSSL Entwicklung sollte nicht außer Acht gelassen werden, dass die OpenSSL Foundation, die von Steve Marquess, einem Berater des US Verteidigungsministeriums, gegründet wurde, auch in der Vergangenheit finanziert wurde. Seit dem Heartbleed Bug ist die OpenSSL Code Qualität und die Vertrauenswürdigkeit der Implementierung insgesamt in Frage gestellt. Dies hat das OpenBSD Team um Gründer Theo de Raadt auf den Plan gerufen, mit LibreSSL eine unabhängige, zu OpenSSL kompatible Software Implementierung zu entwickeln. Erste Erfolge kann das LibreSSL Team nach 30 Tagen Entwicklungszeit bereits vermelden und ruft um Unterstützung für die Finanzierung der Entwicklung auf.