Zweitschlüssel

Hintertüren in der Crypto-API

Ein mächtiges Instrument der Datensicherheit sind heute Verschlüsselungsprogramme. Dies haben auch die Amerikaner begriffen, und wehren sich seither per Gesetz gegen die Verbreitung leistungfähiger Kryptologietechniken im Rest der Welt. Wie weit dieses Anliegen gehen kann, hat am 31.August der Programmierer Andrew Fernandes u.a. im Internet veröffentlicht (www.cryptonym.com/hottopics/msft-nsa.html). Dabei geht es um eine Sicherheitslücke in der Windows-Verschlüsselungsschnittstelle (Crypto-API) die es ermöglicht vohandene Verschlüsselungssoftware zu schwächen oder die auch als Angriffspunkt für Trojanische Pferde dienen kann.

Sicherheitsunternehmen die Verschlüsselungsfunktionen für die Microsoft-Betriebssysteme zur Verfügung stellen wollen, müssen diese Module zunächst von Microsoft signieren lassen, bevor sie auf die Crypto-API zugreifen dürfen. Möchte ein extern eingebrachtes Verschlüsselungsmodul auf die Crypto-API zugreifen, wird dieses von der Crypto-API erst auf die korrekte Signatur mit einem Microsoft-RSA Key geprüft. Damit ist in gewissem Umfang die Exportkontrolle über sichere Kryptographie gegeben, denn es werden nur den amerikanischen Unternehmen die sicheren Krypto-Module signiert, ausländische Anbieter hingegen bekommen nur Module die mit ungenügenden Schlüssellängen arbeiten von Microsoft signiert.

Der Schwachpunkt innerhalb der Crypto-API ist ein bis dato der Öffentlichkeit unbekannter Zweitschlüssel mit dem Microsoft-internen Namen NSAKEY. Bedingt durch den Namen kamen dann auch sofort die Mutmaßungen auf, es könne sich dabei um eine Funktion für den US Geheimdienst NSA (National Security Agency, www.nsa.gov) handeln. Während der Hauptschlüssel von Microsoft in der Crypto-API gegen Manipulationen gesichert ist, kann dieser Zweitschlüssel problemlos gegen einen anderen ersetzt werden, was das unbemerkte Laden von nicht signierten Verschlüsselungsfunktionen erlaubt.

Microsoft dementierte zwar, dass der "NSAKEY" weder der NSA noch einem Dritten zugänglich ist und es sich vielmehr um eine unglückliche Namensgebung handelt, doch das Hauptproblem für IT-Verantwortliche wird dadurch nicht gelöst. Die Möglichkeit zur unauffälligen Veränderungen durch den Austausch des Zweitschlüssels steht jedem Angreifer offen. Damit bieten alle Windows Versionen von 95 über NT bis zum zukünftigen Windows 2000 tief im System einen für den Computeruntergrund interessanten Angriffspunkt für Trojanische Pferde. Dies sollte vor allen Dingen europäische IT-Manager beunruhigen, die auf der NT-Plattform hochsichere Data-Centers realisert haben.

Die Kehrseite der Sicherheitslücke besteht in der Möglichkeit zur Umgehung der amerikanischen Exportrestriktionen für sichere Verschlüsselungstechnologie. Die Austauschbarkeit des zweiten Schlüssels erlaubt nämlich auch die Installation von sicheren Verschlüsselungsmodulen, die nicht von Microsoft zur internationalen Verwendung signiert wurden. Damit eröffnen sich ganz neue Perspektiven für Verschlüsselungsanbieter, deren Produkte in Ermangelung einer Signatur aus Amerika oberhalb der Crypto-API auf das Betriebssystem aufgesetzt werden mussten. Hier muss nur das Produkt entsprechend angePasst werden, damit es die Crypto-API als direkte Schnittstelle zum Betriebssystem nutzen kann. Und das alles ohne Kontrolle von Microsoft oder dem amerikanischen Exportgesetz für Verschlüsselungstechnologie.

Betrachtet man sich die Marktdurchdringung von Microsoft-Betriebssystemen, so muss sich der IT-Manager der auch an wirksamem Datenschutz interessiert ist, doch die Frage stellen, wie wirksam überhaupt Datensicherheit auf Systemen sein kann deren interne Funktionen nicht offengelegt und verifizierbar sind. Bedingt durch die Tatsache, dass heute praktisch alle wichtigen Daten und kritische Unternehmensprozesse über Computer organisiert, optimiert und verwaltet werden, muss wohl innerhalb von Unternehmen und auch öffentlichen Verwaltungen das datensicherheitstechnische Restrisiko beim Einsatz von Microsoft-Betriebssystemen neu definiert werden.

In den letzten Jahren sind Stimmen von Datensicherheitsfachleuten aus der Privatwirtschaft und von Behörden laut geworden, die ein offenes Betriebssystem zwecks Verifizierung der Wirksamkeit von Datensicherheitsmaßnahmen angemahnt haben. Doch passiert ist praktisch nichts. Auf der einen Seite gibt es die Microsoft Betriebsysteme, deren Interna schlecht oder manchmal sogar falsch dokumentiert sind, mitsamt Microsoft's restriktiver Informationspolitik was Betriebssysteminternas anbelangt, auf der anderen Seite die Hersteller von Datensicherheitsmaßnahmen für die Windows Plattform, die aufbauend auf die Microsoft-Informationen mit bunten Prospekten und der Aussage "Unsere Lösung ist sicher..." um das Vertrauen der Kunden werben.

Was bleibt einem IT-Verantwortlichen als Alternative? Vielleicht Linux? Das Betriebssystem ist hervorragend dokumentiert und liegt als Sourcecode vor. Damit wäre die Forderung nach einem offenen Betriebssystem erfüllt, dessen Funktionen jederzeit anhand des Sourcecodes verifiziert werden können. Doch noch fehlt die Auswahl an geeigneten Applikationen. Trotz des Linux-Booms, der spätestens auf der CeBIT 99 erkennbar wurde, sind zur Systems 99 in München keine interessanten Sicherheitsapplikationen auf Linux portiert worden, was schon fast den Verdacht nahelegt, dass hier ein ganzer Zweig den Linux-Boom verschläft.

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar.