Von CW-Redakteur Wolfgang Sommergut
MÜNCHEN (COMPUTERWOCHE) - Mit dem Update der Java Cryptography Extension (JCE) will Sun nur mehr Verschlüsselungsmodule autorisierter Hersteller zulassen. Mit dieser Änderung werden Anbieter von Kryptografieprogrammen auch außerhalb der USA zur Einhaltung der amerikanischen Exportbestimmungen gezwungen.
Bei JCE handelt es sich, wie bei anderen Java-APIs (Application Programming Interfaces = Programmierschnittstellen) auch, primär um eine Spezifikation. Sie definiert eine Plug-in-Architektur für Verschlüsselungsmodule, die unabhängige Softwareentwickler in die Java-Plattform einfügen können. Die wesentliche Neuerung von JCE 1.2.1 besteht darin, dass sich über diese Schnittstelle nur Code einklinken lässt, wenn er von autorisierter Stelle digital signiert wurde.
Auf den ersten Blick könnte diese Änderung vielleicht danach aussehen, als schütze sie Anwender vor zweifelhaften Krypto-Programmen - wobei bis dato unklar ist, wer außer Sun derartige Module überhaupt absegnen darf. Tatsächlich ist diese Funktion aber in erster Linie politisch motiviert und bringt für Unternehmen außerhalb der USA eine Verschlechterung in puncto Geheimhaltung. Bis zur Version 1.2 konnten beispielsweise europäische Softwarehäuser ohne Rücksicht auf amerikanische Exportbestimmungen Module für starke Verschlüsselungen schreiben, die sich in JCE einhängen ließen. Ein solcher Baustein, von Sun als Service-Provider bezeichnet, stammt sogar von einem Open-Source-Projekt namens Cryptix.
In der neuen Architektur aber soll sich die Länge des Schlüssels abhängig vom Standort dynamisch ändern. Dazu benutzt JCE "jurisdiction policy files". Eine dieser Dateien repräsentiert die amerikanischen Exportbestimmungen, eine andere trägt den lokalen Gesetzen Rechnung. Unterscheiden sich die beiden Regelungen, so zieht JCE jene mit den strengeren Auflagen heran. Im Klartext: Das Maximum an Verschlüsselung definieren außerhalb Nordamerikas in jedem Fall die amerikanischen Exportrestriktionen, die lokalen Bestimmungen greifen nur, wenn sie noch strenger sind.
Kritiker befürchten, dass die benötigte Signatur für Krypto-Module mit zusätzlichen Auflagen verbunden sein könnte. Hersteller müssen nämlich vorher das amerikanische Genehmigungsverfahren für den Export durchlaufen. In dessen Zuge werden Firmen häufig angehalten, mit amerikanischen Behörden zu kooperieren, beispielsweise Hintertüren für Geheimdienste wie die National Security Agency (NSA) einzubauen. Nicht gerade vertrauenserweckend sind zudem Äußerungen von Sun-Chef Scott McNealy, der für das Thema Schutz der Privatsphäre nach eigenem Bekunden wenig übrig hat.
Sun hilft die erforderliche Signierung von Verschlüsselungsmodulen zumindest bei der Distribution von Java. Musste JCE vorher noch getrennt vom Java Developer Kit (JDK) heruntergeladen werden, kann die als exportfähig eingestufte Version 1.2.1 nun zusammen mit dem ganzen Paket vertrieben werden. Der als Referenzimplementierung mitgelieferte Provider beschränkt sich zudem auf schwache Verschlüsselung.
Da JCE als allgemein zugängliche Spezifikation vorliegt, könnten unabhängige Entwickler (beispielsweise Open-Source-Teams) diese selbständig umsetzen und dabei auf die Signierung für Krypto-Module verzichten. Dies freilich böte Sun einen - vielleicht willkommenen - Anlass, das Zulassungsverfahren auf weitere Java-APIs auszudehnen und so zu verhindern, dass das hauseigene JDK um unliebsame Klassen erweitert wird.