Gruppe 3, Victoria Tetyak und Rastislav Levrinc
Inhalt
Es gibt Meinungen, daß Electronic Commerce die Geschäftsabwicklung, speziell über das World Wide Web, revolutionieren wird. Noch hat die Finanzwelt allerdings diese Revolution nicht wirklich zur Kenntnis genommen und vielen Menschen, die elektronischen Betrug fürchten, bleiben diese Technologien verdächtig und sie nehmen sie nicht an. Um ein sichereres Umfeld für elektronische Transaktionen zu schaffen, wurde als eine mögliche Lösung von Sun Microsystems eine in der Programmiersprache Java geschriebene Produktfamilie mit dem Namen "Java Wallet" vorgeschlagen, von dem der Entwickler annimmt, daß es die mannigfaltigen Probleme der Elektronischen Geschäftsabwicklung lösen könnte.
Die Java Programmiersprache und Virtuelle Maschine haben es ermöglicht, architektur-neutrale multi-Teilnehmer-fähige Netzwerkanwendungen zu schaffen. Jeder in Java geschriebene Code wird zu einem architekturneutralen bytecode Format compiliert, so daß es auf jedem Gerät, das die Java Virtuelle Maschine implementiert (ausführt), von gewöhnlichen Computern bis zu kleinen elektronischen Geräten.
Der Umstand, daß in Java entwickelte Software architekturneutral ist, ist der Hauptgrund für seine spezielle Eignung für Netzwerkumgebungen, da Netzwerke, und da besonders das Internet, verschiedene Plattformen verbinden, die unabhängig von den ihnen zugrundeliegenden Unterschieden kooperieren müssen. Bei Geschäfts-abwicklungen über das WWW ist es notwendig die einzelnen Teilnehmer, unabhängig von der Kompatibilität der von ihnen verwendeten Operationssysteme, zu verbinden. Aus diesem Grund scheint Java recht gut geeignet zu sein, das Umfeld zu bilden, das Geschäfte im WWW ermöglicht und könnte eine wichtige Rolle im E-Commerce spielen. [5], [6], [9]
Es weiß allerdings jeder über die Sicherheitsprobleme, die in den letzten drei Jahren in Java-fähigen (Java enabled) Web Browsern aufgetreten sind. Heutzutage ist Java Sicherheit ein heißes Thema. Es gibt da noch einige Fragen, die beantwortet werden müssen. Welche Auswirkungen werden erkannte Sicherheitsrisiken (entweder bereits eingetretene oder befürchtete) auf mögliche Käufer haben? Ist Java im Hinblick auf mögliche Sicherheitsrisiken die beste Plattform für die Entwicklung von E-Commerce Systemen? Wie wird die Verwendung von Java innerhalb von Unternehmen sich auf deren Sicherheitsrisiken auswirken?
Als ein Beispiel für die Verwendung von Java, um sicherere E-Commerce Operationen zu ermöglichen, wollen wir das obengenannte Java Wallet genauer betrachten.
Das Java Wallet ist eine in der Programmiersprache Java geschriebene Produktfamilie, die mit dem Ziel, sichere E-Commerce Operationen zu ermöglichen, geschaffen wurde.[2] Es gibt zumindest zwei unterschiedliche Bedeutungen des Ausdruckes "Java Wallet". In seiner extensiven Auslegung ist Java Wallet das Java Electronic Commerce Framework (JECF), welches entwickelt wurde um eine offene, erweiterbare Architektur zur Entwicklung von sicheren E-Commerce Applikationen in Java zu bieten.
Im engeren Sinne ist das Java Wallet ein Programm mit einem Wallet-Like-Grafical-User Interface, das für Online Käufe und zahlreiche andere Finanztransaktionen verwendet werden kann. In diesem engeren Sinne ist es eines der JECF Tools (Werkzeuge), das von Sun unter Verwendung der JECF API's entwickelt wurde.
Das Java Wallet umfaßt den Java Commerce Client, Commerce JavaBeans Komponenten, und Java Commerce Messages um den Usern eine flexible Plattform für Online Geschäfte zu bieten. [2]
Alle diese Produkte können sowohl kombiniert, als auch unabhängig voneinander eingesetzt werden.
Die Hauptkomponenenten von Java Wallet [4]
Das Java Commerce Client Framework besteht aus Java Commerce APIs, welche die Standard-APIs des Java Developer's Kit (JDK) erweitern. Diese beinhalten Klassen (classes), Interfaces und Methoden, um alle Funktionen des JCC ausführen zu können und um alle System-Ressourcen nutzen zu können. Der JCC wurde entwickelt, um Commerce JavaBeans Komponeneten zu vereinigen. Er soll sichere elektronische Transaktionen ermöglichen. Der JCC gibt die Möglichkeiten E-Commerce Applikationen zu entwickeln.[4] [10]
Der JCC hat zwei wichtige Umgebungen (environments):
Die JCC`s Operation / Service-Umgebung ist die Runtime-Umgebung in der E-Commerce Operationen ausgeführt werden unter Verwendung von Commerce JavaBeans Komponenten, die zuvor heruntergeladen und im JCC registriert wurden.
Abbildung 1. JCC und Komponenten
Das Gateway Security Model (Das Gateway Sicherheitsmodell)
Die Entwickler versuchten den JCC sicher zu machen. Deshalb wurde ein neues Sicherheitsmodell mit dem Namen Gateway Security Model (GSM) für JCC vorgeschlagen, um den Zugang zu Ressourcen im JCC und in den Kassetten zu kontrollieren.
Das Gateway Security Model ( GSM ) basiert auf dem Limited Trust Model ( LTM ). Dieses Modell geht davon aus, daß keine Geschäftsverbindung auf absolutem Vertrauen zwischen den Geschäftspartnern basiert. Weiters vertraut man verschiedenen Parteien unterschiedliche Informationen an. Man gibt zum Beispiel seinem Arzt andere Informationen als seinem Rechtsanwalt. Man will keinesfalls, daß der Anwalt die Informationen des Arztes erhält. Und umgekehrt. Im E-Commerce ist das nicht anders. Man wollte auch hier nicht, daß das Finanzamt auf Informationen über unversteuerbares Einkommen zugreifen kann. Das Limited Trust Model versucht, die Beziehungen "Begrenzten Vertrauens" in der Interaktion zwischen Codes abzubilden, welche die an der Transaktion teilnehmenden Parteien repräsentieren. Das LTM bietet daher fine-grained Zugang zwischen den Kassetten sowie zwischen Kassetten und dem JCC.
Der JCC führt Limited Trust im Gateway Security Model aus, einer auf Genehmigungen basierenden Sicherheits-Architektur. Diese Sicherheits-Architektur ermöglicht Zugriff zu Ressourcen gemäß den Rechten, die einem Code (body of code) vertraglich zugesichert werden. Im GSM werden Rechte durch Roles repräsentiert.
Man sagt zum Beispiel von einem Code (body of code), der das Recht hat, in die JCC Database installiert zu werden, er sei für die Kassette-Role signiert. Die Kassette wird als signiert für die Role bezeichnet, da der Inhalt der Kassette eine digitale Unterschrift trägt, die es der Kassette ermöglicht, ein Permit (eine Erlaubnis) für die Installation in den JCC zu erhalten.[4] [3]
Kassetten Signaturen
Der Inhalt einer Kassette wird verschlüsselt unter Verwendung des privaten Schlüssels einer Partei, der von beiden an einer Transaktion beteiligten Parteien vertraut wird. Ein Privater Schlüssel ist ein Teil eines Schlüsselpaares bestehend aus Privatem und Öffentlichem Schlüssel. Der Unterschied zwischen den beiden Teilen ist der, daß der öffentliche Schlüssel für jedermann zugänglich ist, während der Private Schlüssel geheim gehalten werden muß. In diesem Fall wird das System der Ver- schlüsselung umgedreht: Der Versender Verschlüsselt die Nachricht mit seinem Privaten Schlüssel. Es kann jeder die Nachricht dann mit dem Öffentlichen Schlüssel des Versenders entschlüsseln. Läßt sich die Nachricht mit dem Öffentlichen Schlüssel öffnen, bedeutet das, die Nachricht stammt tatsächlich vom angegebenen Absender und wurde auch nicht verfälscht.
Da Benutzer des JCC die Kassetten in ihre Maschinen herunterladen, ist es wesentlich, daß der Code in der Kassette authentisch ist. Er muß von einer Partei kommen, der man vertraut. Wenn der Code einer Kassette geändert wurde, nachdem diese signiert für Roles wurde, könnte unerlaubter Zugang zu geheimer Information gegeben werden. Deshalb wird der gesamte Inhalt einer Kassette (Klass-Files, Graphiken, Audio-Files includiert) hashed und digital signiert. Der JCC überprüft die Hashwerte und entscheidet ob der Code authentisch ist. Eine Kassette wird grundsätzlich von Inhabern
der Codes oder von den Autoren signiert. Ebenso kann sie von einer dritten Partei signiert werden, welche das Vertrauen beider an einer auf Kassetten basierenden Beziehung beteiligten Parteien genießt.
Kassetten Roles
Nachdem ein CommerceBean entwickelt worden ist, muß es in einem Java-Archiv-File (JAR-File) gespeichert werden, das wiederum muß für die Roles, die das CommerceBean im JCC haben wird, signiert sein. Sobald das JAR-File, welches das CommerceBean beinhaltet, signiert ist, ist es offiziell eine Kassette.
Der öffentliche Schlüssel der Partei, der man vertraut und welche die Kassetten für Roles signieren soll, ist im Manifest-File der Kassette eingeschlossen. Der Private Schlüssel, mit dem die Kassette signiert wurde, hat eine spezielle Aufgabe. Die dritte Partei, der man vertraut, wird einen Privaten Schlüssel verwenden, um eine Kassette für die KASSETTE-Role zu signieren, einen anderen Privaten Schlüssel für die WALLET-USER-Role.
Abbildung 2
Der JCC beinhaltet einen RoleManager, der die digitalen Signaturen einer Kassette mit einer Liste von Öffentlichen Schlüsseln vergleicht, sobald die Kassette geladen wird. Wenn der Öffentliche Schlüssel, der zum Privaten Schlüssel der dritten Partei, der man vertraut, gefunden wird, erhält die Kassette diese Role im Verhältnis zum JCC oder einer anderen Kassette.
Ein JAR-File wird signiert, um der Kassette und den CommerceBeans, die es enthält, das Recht zu geben, Aktionen im JCC auszufuhren. In gewissem Sinne verleihen Roles Kassetten die Staatsbürgerschaft im JCC.
Es sind jedoch nicht alle Kassetten gleichrangig. Einige Kassetten haben mehr Freiheiten als andere. So muß zum Beispiel ein JAR-File mit der KASSETTE-Role signiert werden, um im JCC installiert werden zu können. Alle authentizierten Kassetten müssen dieses Recht haben. Soll ein CommerceBean das Privileg haben, von der JCC- Database zu lesen, muß die Kassette, die sie beinhaltet, mit der WALLET-USER-Role signiert sein. Und wenn ein CommerceBean das Recht haben soll, in der JCC-Database zu schreiben, muß die Kassette mit der WALLET-ADMIN-Role signiert sein. Diese Roles sind vordefiniert. Der Satz verfügbarer Roles entspricht dem Satz von Permits die im JCC angewendet werden. Es können Roles jedoch nach Bedarf geschaffen werden.
Wenn eine Institution zwei CommerceBeans entwickelt, die zusammenarbeiten sollen, kann diese Institution diesen CommerceBeans auch Roles zuteilen, indem sie die Kassetten signiert und Öffentliche Schlüssel, die diesen Roles entsprechen, in die Kassetten einbettet.[4]
Gates
Eine Gate-Commerce-JavaBeans Komponente schirmt sensitive Daten ab, indem sie nur authentizierten Zugang zu sensitiven Daten und Methoden erlaubt. Ein Gate-Bean vergibt Permits an authentizierte Antragsteller. Ein CommerceBean erhält ein Permit von einem Gate-Bean, das seiner Role entspricht. So muß, zum Beispiel eine Kassette, die ein Operation-CommerceBean enthält, für die OPERATION-Role signiert sein, damit sie die Information erhalten kann, die sie benötigt, um ihren Auftrag auszuführen. Die Operation-Role erlaubt einem Operation-Bean ein OperationPermit von einem OperationGate zu erhalten.
Genauso ist es in einer Operation, in der ein Item zum Pulldown-Menü im Wallet GUI hinzugefügt werden soll. Es muß für die MENÜ-Role signiert sein, die es ihm erlaubt, ein MENÜ-Permit vom Menü-Gate zu erhalten. Daher muß eine Kassette, die ein Operation-CommerceBean enthält, das im JCC installiert werden will um eine Operation auszuführen und einen Item zur Pulldown-Menü hinzuzufügen, für die KASSETTE-, OPERATION- und MENÜ-Roles signiert sein, da jeweils ein eigenes Permit vom entsprechenden Gate benötigt wird. [4]
Gates und Kontext
Sobald der JCC durch den Empfang einer Operation Java Commerce Message (JCM) instantiiert wird, erstellt es eine Kontext-Hierarchie in der danach Commerce- JavaBeans instantiiert werden. Gate-Beans werden mit dem passenden spezifischen CommerceKontext registriert bevor eine Operation ausgeführt wird. Der JCC ist verantwortlich, die Gates mit den geeigneten Kontexten zu registrieren. Kontext-Specificity ermöglicht es, den Zugang zu den Ressourcen genau zu kontrollieren.
Abbildung 3.Kontext Instantiation und Gate Registrierung
Ein Operation-Kontext ist eine spezifische Ebene des Kontexts. Ein Operation-Kontext wird für eine spezielle Operation instantiiert. Das zu dieser Operation gehörige OperationBean wird innerhalb dieses Operation-Kontexts instantiiert. Die Instrument- und Protokoll-Beans, welche in dieser Operation verwendet werden, werden ebenfalls innerhalb des Operation-Kontextes instantiiert.
Ausschließlich CommerceBeans die in einem Kontext registriert sind haben Zugang zu Gates in dieser Ebene der Specificity. Jedoch können spezifische Kontexte die Methodenaufrufe an mehr allgemeine Kontexte delegieren. Zum Beispiel erhält das OperationBean, welches mit dem mit dem Operation-Kontext registriert ist, Zugang zu den Instrument- und Protokol-Beans über das Operation-Gate, das mit dem Operation-Kontext registriert ist. [4]
Permits
Roles erlauben es Kassetten, Permits für den Zugang zu Methoden zu erhalten, welche die im JCC oder anderen Kassetten beinhalteten Ressourcen verwenden. Es gibt für jede Role ein eigenes Permit. Zum Beispiel: Ein Kassetten-Permit wird einer für die KASSETTE-Role signierten Kassette gegeben, Dieses Kassetten-Permit erlaubt ihr den Zugang zur Durchführung der install() Methode, die in CassettePermitImpl durchgeführt wird.
Ein Beispiel für eine Methode, die durch Permits geboten wird, ist die Möglichkeit, auf Tabellen in der Database zugreifen zu können.
So wird zum Beispiel das TableOwnerPermit dem CommerceBean gewährt, das eine Tabelle in der JCC Database erstellt. Dieses Permit erlaubt seinem Inhaber
Ein Beispiel für die Funktion des Gateway Security Model's
Die Roles werden überprüft und die Permits verteilt, sobald eine Kassette zum ersten Mal geladen wird.
Abbildung 4 GSM [4]
Nun werden wir die Schwachstellen im Sicherheitskonzept von Java Wallet näher betrachten. Die Betrachtungen basieren auf den Untersuchungen, die von GTE, Irving, Texas [8], ein Unternehmen, das ebenso an der Entwicklung von Produkten für den sicheren elektronischen Handel arbeitet, gemacht wurden. Diese Untersuchungen deckten eine Anzahl von Möglichkeiten für feindliche Applets auf, Systeme, auf denen Java Wallet installiert ist, zu mißbrauchen.
So kann zum Beispiel die Database dazu verwendet werden, vertrauliche Informationen zu erhalten. Die Database ist verschlüsselt und sollte ausschließlich für den Inhaber der Java Wallet zugänglich sein, da sie Informationen über registrierte Kassetten enthält und zusätzlich Daten, wie Kreditkartennummer, PIN-Codes und Passwörter, beinhalten kann. Wenn ein User sich entscheidet, einen Login-Namen und ein Passwort für das Java Wallet zu einzugeben, werden diese Daten unverschlüsselt gespeichert. Es ist klar, daß dies feindlichen Applets mehrere Möglichkeiten des Mißbrauchs bietet.
Es wurden drei Beispiele für feindliche Applets, welche die Schwächen von Java Wallet ausnützen, untersucht. Zwei der untersuchten Applets verwenden die Java Wallet Klassen, um einen unerlaubten Zugang zu vertraulichen Daten und zu Services auf dem Rechner des Users zu erhalten. Das dritte Applet verleitet einen sorglosen Anwender, einen "Hilfe" Knopf zu betätigen, dessen Funktion vom Applet verändert wurde.
Um diese Applets zu entwickeln, wurde Java Wallet (Early Access Release 1) heruntergeladen und gemäß den Vorschriften installiert. Da das Java Wallet zur Installation das Java Plug-in 1.1 von Sun zur Installation benötigt, wurde auch dieses heruntergeladen und installiert. Es wurde auch festgestellt, daß das Java Wallet mit dem Java Plug-in nicht immer ordnungsgemäß arbeitet. So wurde zusätzlich der Project Java Activator (Early Access Release 3) installiert, wobei bemerkt werden muß, daß die untersuchten Applets sowohl mit dem Plug-in, als auch mit dem Activator arbeiteten.
Pickpocket: ein Applet, das Informationen und Passwörter vom Java Wallet stiehlt
Applikationen, die Login- und Passwort Daten zur Erleichterung des Anwenders speichern, führen oft dazu, daß diese Informationen gestohlen werden. Die Untersuchungen haben gezeigt, daß es für ein feindliches Applet leicht ist, derartige Informationen zu bekommen. Dieses Beispiel zeigt, wie ein Applet das Java Wallet's Home-directory auf dem Rechner des User's findet. Das Beispiel zeigt auch, daß ein Applet das Java Wallet's Properties-File (jecf.properties) lesen kann. Das erlaubt dem Applet, gespeicherte Login-Daten, sowie unverschlüsselt gespeicherte Passwörter zu lesen.
BookMarker: ein Applet, das die Funktion des "Help Contents" Knopfes von Java Wallet verändert.
Dieses Beispiel zeigt, wie ein feindliches Applet die Funktion des "Hilfe" Knopfes von von Java Wallet verändern kann, was diesem Applet auf Solaris Systemen erlaubt, Befehle über den Netscape Communicator auszuführen, sobald dieser Knopf gedrückt wird. Damit der "Help Contents" Knopf überhaupt funktioniert, muß der User bereits den Property jecf.browser.path im jecf.properties-File festgelegt haben. Da dies eine scheinbar unbekannte Eigenschaft von Java Wallet ist, läuft ein zweites Applet auf der selben Seite wie der BookMarker und veranlaßt den User, diese Property festzulegen.
Der BookMarker.java lädt zuerst eine falsche Java Commerce Message um das Java Wallet zu starten. Sobald Java Wallet gestartet ist, kann das Applet Zugang zum Feld JECF.globals.releaseBundle erhalten. Dieses erhält daraufhin Zugang zu einem neuen ListResourceBundle, welches es selbst konstruiert hat. Diese unechte Java Commerce Message veranlaßt das Java Wallet, eine falsche Meldung über einen internen Test gemeinsam mit Instruktionen anzuzeigen, man möge den "Help Contents" Knopf für weitere Informationen drücken. Wenn man dieser Anweisung folgt, fügt das Applet eine Bookmark der Home Page des feindlichen Applets zu den bereits bestehenden Bookmarks.
DemonDialer: ein Applet, welches das Modem mißbräuchlich verwenden kann
Das dritte Beispiel zeigt, wie ein feindliches Applet das Java Wallet dazu benützen kann, die Seriellen und Parallelen Ports auf dem Rechner zu besetzen. Dieses spezielle beispiel, der DemonDialer.java, überwacht zuerst alle verfügbaren Ports auf dem Rechner. Sobald es einen Seriellen Port entdeckt, registriert es die Eigenschaften dieses Ports. Wenn ein serieller Port frei ist, öffnet das Applet diesen und kontrolliert, ob ein Modem angeschlossen ist. Wenn dies der Fall ist, wählt das Applet eine Nummer. Wenn der Serielle Port nicht frei ist, oder der Vorgang aus sonstigen Gründen nicht möglich ist, wiederholt das Applet den Wählvorgang nach zehn Sekunden.
Während dieses Applet bloß eine gebührenfreie Nummer
wählt und nach einer Minute wieder auflegt, ist es leicht, das Applet
andere Nummern zu wählen, die die Telefonrechnung erhöhen oder
den Rechner mit einem Computer zu verbinden, der den eigenen Rechner angreift.
Um den Vorgang zu stoppen, ist es notwendig, den Browser zu verlassen.
Hat man dieses Applet über das Modem heruntergeladen, wird sich dieses
Applet im Hintergrund verstecken und, sobald das Modem nicht in Verwendung
ist, angreifen.
Es war nicht ganz leicht, Untersuchungen und Meinungen über Java Wallet zu finden, was zeigt, daß Java Wallet bis jetzt noch nicht sehr weit verbreitet ist und noch nicht von vielen Anwendern getestet wurde. Deshalb ist es nicht überraschend, daß es noch einige Sicherheitsmängel hat, die allerdings nicht zu einer Ablehnung von Java Wallet führen sollten. Alle diese Mängel müßten korrigiert werden können, indem man den Zugang zu den Methoden in den Java Wallet Klassen beschränkt. Derartige Erleichterungen für den Anwender, wie die Speicherung von Login- und Passwortinformationen sollten aus künftigen Java Wallet Versionen entfernt werden.
Aber unter Berücksichtigung der wachsenden Verbreitung und dem gestiegenen Interesse an E-Commerce, sollten alle Unternehmen, welche Software für E-Commerce Anwendungen anbieten, ihre Produkte genau auf Sicherheitsmängel testen, damit nicht Anwender, die sich dafür entscheiden, die Möglichkeiten des Internets und anderer Netzwerke für ihre geschäftlichen Transaktionen zu nutzen, für immer davon abgeschreckt werden.