Eine der vielen Legenden, die seit Jahren um amerikanische Software herumrankt, ist die Behauptung, amerikanische Software besäße versteckte Hintertüren, die amerikanischen Behörden einen ungehinderten Zugriff auf die Daten des Benutzers ermöglichen würde. Keiner hatte bisher eine solche Hintertür eindeutig identifizieren können, allerdings auch keiner ausdrücklich dementieren. Ende August 1999 schien es jedoch so, als ob diese Legende zumindest bei der derzeit prominentesten, US-amerikanischen Softwarereihe, den Windows-Betriebssystemen von Microsoft, zur alptraumhaften Wahrheit geworden wäre.
Der US-Amerikaner Andrew Fernandes, Chefwissenschaftler der kanadischen Firma Cryptonym fand und beschrieb genau so eine Hintertür, ausgerechnet in einem der sensibelsten Bereiche des Betriebssystems, in der so genannten Crypto-API. Die Crypto-API (API steht für Advanced Programming Interface) ist eine windows-interne Programmbibliothek, die verschiedene Verschlüsselungsmodule für die Nutzung durch andere Programme bereithält. Diese Bibliothek ist so aufgebaut, dass sie durch weitere Verschlüsselungsmodule ergänzt werden kann. Damit dies nicht von jedermann vorgenommen werden kann und die grundlegende Sicherheit dieser Crypto-API in Frage gestellt wird, müssen alle Module, die in diese API importiert werden sollen, ein bestimmtes Sicherheitsmerkmal aufweisen.
Dieses Sicherheitsmerkmal wird auf Basis eines asymmetrischen Verschlüsselungsverfahrens bewerkstelligt: Ein Modul, das für die Implementierung in die Crypto-API freigegeben werden soll, muss zunächst Microsoft zur Prüfung vorgelegt werden. Hält es dieser Prüfung stand, wird das Modul mit dem geheimen Schlüssel eines Microsoft-eigenen RSA-Schlüsselpaars signiert, dessen öffentlicher Schlüssel fest in jeder installierten Crypto-API integriert ist. Bei der Installation des zu importierenden Moduls wird dann die digitale Signatur mit dem öffentlichen Schlüssel überprüft und erst dann importiert, wenn die Signatur unbeschädigt ist und vom passenden, geheimen Schlüssel signiert wurde. An sich ein löblicher Sicherheitsmechanismus, der unautorisierte Veränderungen der Crypto-API weitgehend verhindert.
Was bisher an der Crypto-API lediglich am Rande merkwürdig war, war ein zweiter, öffentlicher Schlüssel, der neben dem Microsoft-Schlüssel in der Crypto-API integriert ist. Er trug keine Absenderinformationen und konnte bisher auch noch nicht identifiziert werden. Theoretisch gesehen war dieser unbekannte öffentliche Schlüssel allerdings genauso dazu berechtigt, zu importierende Verschlüsselungsmodule als vertrauenswürdig einzustufen und für die Integration in die Crypto-API freizugeben.
Fernandes fand nun in einem Update-Paket (Service Pack 5) des Betriebssystems »Windows NT 4.0« eine Version der Crypto-API, die noch Debug-Symbole enthielt. Debug-Symbole werden von einem Programmierer während der Programmierarbeit in den Quellcode gesetzt, um bei der testweisen Ausführung mögliche Fehlerquellen genauer lokalisieren zu können. Bei Endversionen von Programmen werden die Debug-Symbole aus Gründen der Sicherheit wieder vom Programmierer entfernt, um es Interessenten möglichst schwer zu machen, den Quellcode bei einer möglichen Analyse des Quellcodes wieder zu entschlüsseln.
Genau solche Debug-Symbole markierten jeweils zwei Stellen im Quellcode der Crypto-API, die sich beim näheren Hinsehen als zwei öffentliche RSA-Schlüssel entpuppten. Der eine war mit »_KEY« bezeichnet, der andere mit "_NSAKEY". Im Klartext bedeutet das: Ein signiertes Verschlüsselungsmodul, das in die Crypto-API importiert werden soll, wird zunächst mit dem öffentlichen RSA-Schlüssel von Microsoft darauf überprüft, ob es mit dem dazugehörigen geheimen Schlüssel signiert wurde. Ist es das nicht, wird dieser Vorgang wiederholt, diesmal aber mit dem öffentlichen RSA-Schlüssel, der als "_NSAKEY" bezeichnet ist.
Und genau das ist der Zündstoff, der auf einen Schlag hochgegangen ist: Die NSA, die »National Security Agency«, ist die größte Geheimdienstorganisation der USA und besonders auf dem Gebiet der Industriespionage tätig (siehe hierzu auch das I-File 008). Klammheimlich hat die NSA sich die Möglichkeit in Windows einbauen lassen, selbst zu bestimmen, ob ein Verschlüsselungsmodul von Windows als sicher eingestuft wird oder nicht. Über diesen Vorgang wird der Benutzer in keinster Weise informiert und er hat auch keine Möglichkeit, zu kontrollieren, von welchem öffentlichen Schlüssel die digitale Signatur eines zu importierenden Verschlüsselungsmoduls überprüft wurde.
Diese Hintertür bringt aber noch ein ganz anderes Problem mit sich. Gelingt es jemandem, den öffentlichen RSA-Schlüssel "_NSAKEY" gegen einen anderen auszutauschen, könnte die ganze Idee der Zertifizierung ausgehebelt werden. Ein Hacker könnte praktisch, nachdem der Schlüssel z.B. durch die Installation eines unverfänglichen Programms ausgetauscht wurde, seine eigenen Verschlüsselungsmodule in Windows importieren und dadurch schwerwiegendste Sicherheitslöcher auslösen.
Und es kommt noch dicker: Laut Fernandes befinden sich in der Crypto-API des Windows-Nachfolgers Windows 2000 schon in den Vorversionen nun sogar drei öffentliche RSA-Schlüssel...
Eine (vorübergehende) Lösung dieses eklatanten Sicherheitsproblems liefert Fernandes auf seiner Informationsseite gleich mit. Mit einem kleinen Programm wird in der Crypto-API der öffentliche RSA-Schlüssel, der als "_NSAKEY" bezeichnet ist, durch einen Dummy-Schlüssel ersetzt. Dennoch, an der eigentlichen, völlig löchrigen "Sicherheitsarchitektur" ändert dies nichts, egal, ob nun der als "_NSAKEY" bezeichnete Schlüssel wirklich zu einem NSA-Schlüsselpaar gehört oder nicht.
Microsoft hat in einer eilig veröffentlichten Pressemitteilung freilich jeglichen Zusammenhang des "_NSAKEY" mit der NSA zurückgewiesen. Der Schlüssel trüge deshalb den Namen "_NSAKEY", da die NSA "das technische Kontrollgremium des USA in der Exportkontrolle sei" und der Schlüssel nur dazu diene, "die Einwilligung zu den US-Exportrichtlinien darzustellen". Und Microsoft kippte noch mehr Öl ins Feuer der Gerüchteküche: Der zweite Schlüssel sei angeblich als "Ersatz" eingebaut, "falls der Hauptschlüssel verloren gehen würde". Nanu, traut Microsoft etwa keinen Banken mit ihren dicken Tresoren, die ganz andere, wertvolle Dokumente schon seit Jahrzehnten sicher wegschließen können?
Das Echo in der Öffentlichkeit war jedenfalls auch ohne diese Frage mehr als gewaltig: Für einen börsentechnisch bedenklich langen Zeitraum von einigen Tagen war Microsoft plötzlich im Zielkreuz von Datenschützern und Bürgerrechtlern. Diskussionen über die Sicherheit amerikanischer Software wurden innerhalb von Firmen und Behörden laut und die ganze Sache reichte sogar in viele Nachrichtensendungen und Zeitungstitelseiten hinein. Besonders im Usenet, dem traditionell besten Ort für brandaktuelle und fundierte Informationen, brodelte die Gerüchteküche.
Doch recht schnell kamen an der Verschwörungstheorie Zweifel auf: Wieso sollte die NSA über die Crypto-API in einen Rechner eindringen, wo es doch z.B. Programme gibt, die als so genannte Trojanischen Pferde Fremden den Zugriff auf einen Rechner ermöglichen können. Ein Spionprogramm, dass als eigenes, kleines Programm oder ausführbares Script daherkommt, ließe sich mindestens genauso gut verstecken. Wieso sollte auch die Erklärung Microsoft, der zweite RSA-Schlüssel sei als Ersatz eingebaut, nicht richtig sein? Es wäre durchaus möglich, dass Programmierer den zweiten Schlüssel als Notnagel eingebaut oder schlicht und einfach vergessen oder es für nicht notwendig befunden haben, ihn nach der Entwicklungsphase wieder auszubauen. Eine andere, denkbare Existenzberechtigung des NSAKEY wäre die Forderung der NSA, einen eigenen Schlüssel für die NSA-interne Datenübertragung einbauen zu lassen, um die NSA völlig unabhängig von Microsoft zu machen. Eine grundsätzliche Frage wirft aber die meisten Fragen auf: Wieso sollte Microsoft einen geheimen Schlüssel der NSA ausgerechnet auffällig als "NSAKEY" im Quellcode kennzeichnen, Debug-Symbol hin oder her?
Letztendlich wird es wohl für lange Zeit ein Rätsel bleiben, was genau dieser ominöse "NSAKEY" bezwecken soll. Ihn einfach als Hintertür der amerikanischen NSA in fremde Rechner zu bezeichnen, ist zu einfach und wirft mehr Fragen als Antworten auf. So eine Geschichte zeigt aber deutlich, wie schnell sich ein Softwareunternehmen durch eventuell missverständliche und unsaubere Programmierung in sensiblen Bereichen sich in kürzester Zeit in ärgste Bedrängnis gegenüber seinen Kunden und der Öffentlichkeit bringen kann.
