-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf das Einführen und Durchsetzen von Sicherheitsfunktionen
in Netzwerken wie etwa Computer- und Kommunikationsnetzwerken. Insbesondere
bezieht sich die Erfindung auf eine Vorrichtung, ein Verfahren und ein
System zum Bereitstellen von Netzwerksicherheit für ausführbaren
Code in Computer- oder Kommunikationsnetzwerken.
-
Hintergrund der Erfindung
-
Netzwerksicherheit
ist ein zunehmend wichtiges Thema für Netzwerkanwender, sowohl
innerhalb von Unternehmen, die ein Intranet betreiben, als auch
für größere und
globalere Daten-, Computer- und Kommunikationsnetzwerke wie etwa
das Internet und das World Wide Web. Wesentliche Technologien sind
für das
Bereitstellen von Netzwerksicherheitsfunktionalität entwickelt
worden, einschließlich Zugangskontrolle,
geschützter
Kommunikation, Sicherheitsunterstützung und Sicherheitsrichtlinienmanagement.
-
Zugangskontrolle
betrifft eine Entscheidung, ob einem bestimmten Anwender oder einem
Endsystem oder einer von einem Anwender initiierten Kommunikation
zu einer bestimmten Computer- oder Kommunikationsressource Zugang
gewährt
werden soll. Zum Beispiel kann bestimmten Anwendern oder Kategorien
von Anwender Zugang zur E-Mail-Funktionalität, aber nicht zur Rechnungswesen-Funktionalität gewährt werden,
die alle auf demselben Netzwerk wie etwa einem Unternelmens-Intranet
zur Verfügung
stehen können.
-
Ähnlich betrifft
andere Sicherheitsfunktionalität
(die als gesicherte Kommunikation bezeichnet wird) Verfahren zum
Sicherstellen, dass Informationen oder andere Daten nicht autorisierten
Personen nicht zugänglich
gemacht werden, z. B., dass nicht autorisierte Anwender darauf nicht
zugreifen können, sie
nicht modifizieren, lesen oder kopieren können. Andere Sicherheitsfunktionalität umfasst
das Bereitstellen von Unterstützung
in verschiedenen Netzwerkgeräten
zum Sichern von anderen Teilen des Netzwerksystems und das Verwalten
der aktuellen Netzwerkdaten, die die Sicherheitsrichtlinien des Netzwerks
festlegen.
-
So
wie sich Sicherheitsmaßnahmen
entwickelt haben, wurden Taktiken zum Durchbrechen der Sicherheit
allerdings zunehmend raffinierter. Passwortschutz und persönliche Identifikationsnummern („PIN"-Nummern) sind bekannte
Sicherheitsmaßnahmen,
die dazu verwendet werden, um physische Sicherheit von Geräten wie
etwa Computer zu bieten und um Zugangskontrolle zu Computersystemen
und Inhalten zu bieten, wie etwa Zugangskontrolle zu Konten (accounts),
Aufzeichnungen (records), Programmen und anderen sensitiven Informationen. Verschiedene
Versuche zum Umgehen solcher Sicherheitsmaßnahmen umfassen einen Angriff
mit einem „trojanischen
Pferd", bei dem
(unbemerkt für den
Anwender) ein schädliches
Programm (rogue program) oder eine andere Anwendung ein richtiges Programm
oder Anwendung ersetzt. Wenn der Anwender versucht, das richtige
Programm oder die Anwendung zu verwenden, wird stattdessen das schädliche Programm
oder die Anwendung ausgeführt,
mit begleitenden und häufig
schädlichen
Konsequenzen. Verschiedene bekannte Angriffe mit „trojanischen Pferden", die durch Computer- „Hacker" verwendet werden,
umfassen die Installation von Programmen, die nach der Ausführung das
Passwort oder die Zugangs-PIN-Nummer an den Hacker senden. Ein solcher
Angriff ermöglicht
eine entsprechende Verletzung der Sicherheit jedes Systems, das
vorher durch das Passwort oder die PIN-Nummer des Anwenders gesichert
wurde, wie z. B. ein Bankkonto des Anwenders.
-
Die
Sprache Java®,
deren Compiler und Interpreter und die gesamte Java-Architektur (einzeln und
zusammen als „Java" oder „Java-Architektur" bezeichnet) wurde
von Sun Microsystems, Inc. („Sun") für Computer-
und Kommunikationsnetzwerke und andere Anwendungen entwickelt. Java
ist so gestaltet, um solchen „trojanischen
Pferden" oder anderen Angriffen,
die aus einem Netzwerk stammen (d. h. von der Seite des Netzwerkservers
oder eines Client-Server-Netzwerkes)
entgegen zu wirken. Für
das World Wide Web („web") und andere Internet-Anwendungen
sind viele derzeitige Webbrowser mit Java ausgestattet (Java enabled)
(d. h. dass der Webbrowser Programmanweisungen für eine virtuelle Java-Maschine
(Java Virtual Machine, „JVM") umfasst), die eine
lokale Ausführung
von Java Byte Code bietet. Wenn ein Netzwerkanwender Informationen
von einer Website mit einem Java-unterstützten Browser anfordert und
darauf zugreift, kann eine ausführbare Anwendung
oder ein Programmpaket, das als „Applet" oder „Applet-Paket" bezeichnet wird,
in Byte Code-Form auf das Endsystem des Anwenders (die Client-Seite
des Client-Server-Netzwerks) herunter geladen werden. Das Applet
(in Byte Code-Form) wird dann durch die JVM des Webbrowsers ausgeführt, der,
zusammen mit allen aus dem Netzwerk herunter geladenen Daten, eine
lokal laufende Anwendung auf dem Endsystem des Anwenders bereitstellt.
Solche lokal laufenden Anwendungen können eine interaktive Website,
eine interaktive Spieleanwendung oder ein interaktives Arbeitsblatt
(spreadsheet) umfassen.
-
Angenommen
ein solcher letztlich fremder Programmcode wird zur lokalen Ausführung herunter geladen,
dann können
inhärente
Sicherheitsprobleme entstehen, die deshalb im Vorhinein innerhalb
der Java-Architektur berücksichtigt
und vermieden werden. Die Java-Architektur umfasst Sicherheitsmerkmale,
die verhindern, dass solche herunter geladenen Programme Auswirkungen
auf private oder Nicht-Netzwerkressourcen des Anwenders haben. Bezeichnet
als die Java Sandbox, verhindert die Java-Architektur, dass ein
nicht vertrauenswürdiges oder
potentiell bösartiges
Applet (herunter geladen von einen entfernten Webserver auf das
lokale Endsystem) von privaten Ressourcen wie etwa der lokalen Festplatte liest,
darauf schreibt oder sie ausführt. Neben
anderen Sicherheitsmerkmalen ist die Sprache Java eine „type safe"-Sprache, die es
Zeigern nicht erlaubt, beliebige Speicherorte zu lesen oder darauf
zu schreiben. Vor der Ausführung
eines ankommenden Applets wird das Applet zusätzlich durch einen Java Byte
Code Verifizierer geschickt, der den Byte Code auf potentiell illegale
Anweisungen bin untersucht, so dass nur zu lässige Applets durch die JVM
auf dem lokalen Endsystem ausgeführt
werden. Siehe zum Beispiel das Java Security White Paper, das auf
den Webseiten von Sun java.sun.com und javasoft.com verfügbar ist;
A. Tanenbaum, Computer Networks (Prentice-Hall, 3rd ed 1996), S.
718-20; D. Flanagan, Java in a Nutshell (O'Reilly, 2d ed 1997), bei 7, S. 139-43.
-
Während die
Java-Architektur Verletzungen der Sicherheit verhindert, die aus
einem Netzwerk (oder einem Netzwerkserver) stammen, bleibt die Notwendigkeit,
potentiellen Verletzungen der Sicherheit entgegen zu wirken, die
von einem lokalen Anwender (d. h. aus einem lokalen Endsystem oder
der Client-Seite eines Client-Server-Netzwerkes) stammen. Wenn z.
B. die physische Sicherheit eines lokalen Endsystems verletzt oder
auf andere Weise in Frage gestellt wird, kann ein schädliches
Programme oder ein Virus lokal auf dem Endsystem gespeichert werden,
wie z. B. ein schädliches
Programm zur Emulation oder Manipulation („spoofing") eines Applets. Es bleibt deshalb die
Notwendigkeit zu verhindern, dass jedes solche lokal geladene Programme oder
Applet unwissentlich durch einen ahnungslosen Anwender ausgeführt wird
und potentiell die Netzwerksicherheit des Anwenders eines solchen
Applets oder anderen Programms in Frage stellt. Solche zusätzlichen
Sicherheitsmaßnahmen
sollten auch ohne zusätzliche
Netzwerk-Hardware implementiert werden, sie sollten kosteneffektiv
und für
den Anwender transparent sein.
-
Aus
der
WO 97/42728 sind
ein Verfahren und eine Vorrichtung bekannt, bei denen zwei oder mehr
Parteien denselben Medieninhalt im Internet betrachten können, während sie
kommunizieren. In einem Beispiel verlangt ein Anwendercomputer einen
Produktvergleich zu sehen, worauf hin ein zweiter Computer ein Script
erzeugen kann, um den Produktvergleich in dem gemeinsamen Inhalt
zur Verfügung
zu stellen, der auf beiden Computern sichtbar ist.
-
Darüber hinaus
beschreibt die
EP 0
824 236 A2 eine Browser-Software, die auf einem Computer läuft, in
der eine Datenseite eine Referenz auf Code umfassen kann, die der
Browser auch über
das Netzwerk beziehen und dann auf der Computer-Workstation ausführen kann.
Der Referenz auf den Code ist auch eine Referenz auf eine weitere
Datei zugeordnet, die wiederum über
das Netzwerk zugänglich
ist, und die Informationen enthält,
die den Code wie etwa die Größe des Codes
betreffen.
-
Zusammenfassung der Erfindung
-
Die
vorliegende Erfindung gewährleistet
eine solche erhöhte
Netzwerksicherheit gegen Verletzungen, die von einer Client-Seite
eines Netzwerkes stammen können,
wie etwa aus einem lokalen Endsystem in einem Netzwerk von Servern
und Routern einschließlich
dem Internet. Dieses zusätzliche
Sicherheitsmerkmal wird vorzugsweise als Software oder als Programmanweisungen
innerhalb eines Netzwerkservers implementiert und erfordert als Konsequenz
keine zusätzliche
Netzwerkhardware und ist kosteneffektiv. Wenn die vorliegende Erfindung
in einer Netzwerkserverausführungsform
implementiert wird, ist sie völlig
transparent (unsichtbar) für den
Anwender, von dem nicht verlangt wird, irgendwelche zusätzlichen
Schritte auszuführen
und der höchstwahrscheinlich
die Implementierung dieses zusätzlichen
Sicherheitsmerkmals nicht bemerkt.
-
Das
Verfahren der vorliegenden Erfindung beginnt, wenn ein Anwender
an seinem oder ihren lokalen Endsystem wie etwa einem persönlichen
oder Netzwerkcomputer Netzwerkinformationen anfordert. Diese Netzwerkinformationen
können
z. B. eine Website sein. Wenn der entfernte Server die Anforderung
für Netzwerkinformationen
erhält,
stellt der entfernte Server fest, ob die angeforder ten Netzwerkinformationen
Schlüsselwörter enthalten
sollten, die, wenn sie aufgerufen werden, ausführbaren Code herunter laden.
Der entfernte Server stellt z. B. für Webseiten fest, ob die angeforderte
Webseite ein Applet Tag (als ein Schlüsselwort) aufweist, das, wenn es
durch den Anwender aufgerufen wird, von dem entfernten Server das
Herunterladen von Java Byte Code zu dem Anwender anfordert.
-
Wenn
die angeforderten Netzwerkinformationen Schlüsselwörter wie etwa Applet Tag enthalten, erzeugt
der entfernte Server Schlüsselwörter, die
bestimmte Referenzen auf entsprechenden ausführbaren Code haben und speichert
den entsprechenden ausführbaren
Code unter Verwendung der neuen unterscheidbaren Referenz. Weiter
in Bezug auf Java als Beispiel wird ein Applet Tag erzeugt, der
einen neuen unterscheidbaren Java-Klassennamen aufweist und der
entsprechende Applet Byte Code wird unter diesem neuen Klassennamen
gespeichert. Die angeforderten Netzwerkinformationen wie etwa eine Webseite,
wird dann erzeugt und an den Anwender übertragen, mit allen Schlüsselwörtern (wie
etwa Applet Tags), die unterscheidbare Referenzen wie etwa eindeutige
Applet-Klassennamen aufweisen.
-
Daraufhin
kann ein Anwender ein Schlüsselwort
aufrufen, in dem er z. B. mit der Maus auf eine graphische Benutzerschnittstelle
auf einer Webseite klickt. Das aufgerufene Schlüsselwort bezeichnet jetzt eindeutig
für den
Anwender, auf unbekannt oder transparent Weise, den entsprechenden
Code, der nur auf dem entfernten Server gespeichert wird. Wenn der
entfernte Server die Anfrage für
den Code empfängt,
so wie er über
den Webbrowser des Anwenders aufgerufen wurde, wird der entsprechende ausführbare Code,
der die unterscheidbare Referenz aufweist, dann für den Anwender
zur lokalen Ausführung
herunter geladen.
-
Es
ist für
einen „Hacker" höchst unwahrscheinlich
wenn nicht unmöglich,
vorher genau zu wissen, welche unterscheidbare Referenz auf einer Webseite
durch den entfernten Server erzeugt und darauf hin durch den Anwender
aufgerufen wird.
-
Wenn
es eine Verletzung der lokalen Sicherheit gäbe und ausführbarer Code (wie etwa ein schädliches
Applet) lokal gespeichert würde,
wäre es nicht
unter der unterscheidbaren Referenz gespeichert (die separat und
voraussichtlich zu einer anderen Zeit durch den entfernten Server
erzeugt wird). Wenn das Schlüsselwort
mit der unterscheidbaren Referenz darauf hin durch den Anwender
aufgerufen wird, wird z. B. ein schädliches Applet oder anderer ausführbarer
Code (der eine andere Referenz aufweist) nicht durch den lokalen
Anwender ausgeführt, ohne
dass er es weiß.
Vielmehr wird, in Übereinstimmung
mit der vorliegenden Erfindung, nur der entsprechende Code mit der
unterscheidbaren Referenz ausgeführt.
-
Die
vorliegende Erfindung stellt damit sicher, dass alle ausführbaren
Codes, die aus einem Netzwerk herunter geladen werden, nicht durch
ein lokal gespeichertes schädliches
Programm manipuliert oder imitiert werden. Vielmehr wird ein solcher
ausführbarer
Code für
jeden Webzugriff neu herunter geladen, voraussichtlich von einer
bekannten oder vertrauenswürdigen
Quelle, auf die direkt durch den Anwender zugegriffen wird. Als
Konsequenz wird die Netzwerksicherheit des Anwenders erhalten, trotz
einer angenommenen Verletzung der lokalen physischen Sicherheit
(die ermöglicht
hatte, dass schädlicher
Code lokal gespeichert wurde). Zusätzlich wird in der bevorzugten
Ausführungsform
die vorliegende Erfindung innerhalb eines Netzwerkservers verkörpert und
alle seine Operationen beim Erzeugen von unterscheidbaren Referenzen
und entsprechendem Code sind vollständig transparent für einen
Anwender: Der Anwender muss keine bestimmten Anweisungen, Codes
oder Passwörter
eingeben oder verwenden, und es muss ihm nicht einmal bewusst sein, dass
diese zusätzliche
Sicherheitsmaßnahme
implementiert wurde. Zahllose andere Vorteile und Merkmale der vorliegenden
Erfindung werden aus der folgenden detaillierten Beschreibung der
Erfindung und ihrer Ausführungsformen,
aus den Ansprüchen
und aus den beigefügten
Zeichnungen direkt deutlich.
-
Kurze Beschreibung der Zeichnungen
-
1 ist
ein Zustandsdiagramm, das eine Systemausführung in Übereinstimmung mit der vorliegenden
Erfindung darstellt.
-
2 ist
ein Blockdiagramm, das ein repräsentatives
Netzwerk mit einer Systemausführung
in Übereinstimmung
mit der vorliegenden Erfindung darstellt.
-
3 ist
ein Flussdiagramm, das eine bevorzugte Verfabrensausführung in Übereinstimmung
mit der vorliegenden Erfindung darstellt.
-
4 ist
ein Flussdiagramm, das eine allgemeine Verfahrensausführung in Übereinstimmung mit
der vorliegenden Erfindung darstellt.
-
5 ist
ein Blockdiagramm, das eine Vorrichtungs-Ausführungsform in Übereinstimmung
mit der vorliegenden Erfindung darstellt.
-
6 ist
ein Blockdiagramm, das eine bevorzugte Vorrichtungs-Ausführungsform
in Übereinstimmung
mit der vorliegenden Erfindung darstellt.
-
Detaillierte Beschreibung
der Erfindung
-
Wie
oben erwähnt
besteht eine Notwendigkeit, die Effekte von potentiellen Verletzungen
der Netzwerksicherheit zu beseitigen, die von einem lokalen Anwender
(d. h. von einem lokalen Endsystem oder der Client-Seite eines Client-Server
Netzwerkes) stammen. Wenn die physische Sicherheit eines lokalen
Endsystems beeinträchtigt
wird, so dass ein Netzwerksprachenprogramm oder eine Anwendung wie
etwa ein Applet lokal gespeichert werden, dann wird in Übereinstimrung
mit der vorliegenden Erfindung ein solches lokal geladenes Programm
oder Applet nicht durch einen ahnungslosen Anwender ausgeführt, ohne
dass er es weiß.
Angenommen, dass ein „trojanisches
Pferd" oder ein
anderes schädliches
Programm, das ein Applet fälscht,
lokal installiert wäre,
verhindert die vorliegende Erfindung trotz einer solchen Verletzung
der Sicherheit, dass ein solches schädliches Programm die Netzwerksicherheit
des lokalen Anwenders potentiell beeinträchtigt. Dieses zusätzliche
Sicherheitsmerkmal wird vorzugsweise als Software oder als andere
Programmanweisungen innerhalb eines Netzwerkservers implementiert
und erfordert deshalb keine zusätzliche
Netzwerkhardware und ist kosteneffektiv. Wenn die vorliegende Erfindung
in einer Netzwerkserverausführungsform
implementiert wird, ist sie für den
Anwender zudem transparent, von dem nicht verlangt wird, irgendwelche
zusätzlichen
Schritte auszuführen,
und dem höchstwahrscheinlich
dieses zusätzliche
Sicherheitsmerkmal nicht bewusst ist.
-
1 ist
ein Zustandsdiagramm, das eine Systemausführungsform 60 zeigt,
um eine Gesamtübersicht
des Verfahrens und des Betriebes der vorliegenden Erfindung zu bieten.
Wie in 1 dargestellt, besteht die Systemausführungsform 60 aus
einem lokalen Endsystem 150 wie z. B. einem persönlichen oder
einem Netzwerkcomputer und einem entfernten Server 110.
Der entfernte Server 110 ist typischerweise Teil eines
entfernten Serversystem 65, das auch Speicher oder andere
Speichermöglichkeiten
umfasst. Wie auch in 1 dargestellt, werden durchgezogene
Linien und unterbrochene Linien verwendet, um verschiedene Zeitdauern
anzugeben, wobei die durchgezogenen Linien eine anfängliche
Zeitdauer darstellen und die unterbrochenen Linien eine darauf folgende
Zeitdauer darstellen.
-
Mit
Bezug auf 1 überträgt das lokale Endsystem 150 über einen
Webbrowser oder ein anderes Internet-Kommunikationsprogramm eine
Anfrage für
Netzwerkinformationen (Zustand 10) wie z. B. eine Anfrage
für eine
Webseite. Diese Anfrage wird durch den entfernten Server 110 empfangen (Zustand 15).
Der entfernte Server 110 ermittelt dann, ob die angeforderten
Netzwerkinformationen ein oder mehrere Schlüsselwörter wie etwa Applet Tags aufweisen,
die zum Aufrufen von ausführbaren Codes
verwendet werden (Zustand 20). Wenn die Netzwerkin formationen
solche Schlüsselwörter aufweisen,
erzeugt der entfernte Server 110 die Schlüsselwörter, wobei
jedes Schlüsselwort
eine neue unterscheidbare Referenz aufweist, z. B. einen neuen Java
Applet Klassennamen (Zustand 25). Der ausführbare Code,
der jedem solchem Schlüsselwort entspricht,
wird gespeichert (Zustand 30), innerhalb des entfernten
Servers 110 oder innerhalb von zusätzlichen Speicherkapazitäten. Der
entfernte Server 110 erzeugt dann die angeforderten Netzwerkinformationen,
wobei jedes enthaltene Schlüsselwort
eine unterscheidbare Referenz aufweist (Zustand 35), und überträgt die Netzwerkinformationen
an das lokale Endsystem (Zustand 40). Darauf hin kann das lokale
Endsystem 150 ein Schlüsselwort
aufrufen, indem eine Anforderung für ausführbaren Code übertragen
wird, unter Verwendung oder mit der unterscheidbaren Referenz (Zustand 45).
Wenn der entfernte Server 110 die Anforderung empfängt (Zustand 50), überträgt er den
entsprechenden ausführbaren
Code an das lokale Endsystem 150 (Zustand 55).
-
2 ist
ein Blockdiagramm, das ein repräsentatives
Netzwerk 180 mit einer Systemausführungsform in Übereinstimmung
mit der vorliegenden Erfindung darstellt, z. B. Server 130 und
den genauer bezeichneten entfernten Server 110 und den
lokalen Server 120. Wie in 2 dargestellt,
umfasst das Netzwerk 180 eine Mehrzahl von verbindbaren
oder verbundenen Geräten
und anderen Systemen wie etwa Routern 125, Servern 130 (und
insbesondere dem entfernten Server 110 und dem lokalen
Server 120), lokalen Netzwerken (local area networks, „LANs") 165, Weitverkehrsnetzen
(wide area networks, „WANs") 115, andere
Netzwerke 140 und eine Mehrzahl von Endsystemen 150.
Die Endsysteme 150 können
z. B. Personal Computer, Konstruktionsarbeitsstationen (engineering
work stations), Netzwerkcomputer und andere Netzwerke umfassen,
die zu Netzwerkverbindungen fähig
sind, wie z. B. ein Web-Fernsehsystem oder ein persönlicher
digitaler Assistent. Das Netzwerk 180 und andere Netzwerke 140 können jeden
Typ von Kommunikationskanälen 160 umfassen,
wie z. B. T1, E1, ISDN, Kabel- oder faseroptische
Verbindungen, und sie können
jeden Typ von Netzwerkverbindungen wie etwa leitungsvermittelte
oder paketvermittelte Netzwerkverbindungen umfassen. Zum Beispiel
kann es sich bei den verschiedenen Kommunikationskanälen 160 um
Hybridfaser-Koaxialkabel an einigen Orten und twisted-pair-Verbindungen an anderen
Orten handeln, während
die anderen Netzwerke 140 ein öffentliches (oder allgemeines)
Telefonnetz oder ein öffentliches oder
ein backbone Internet routing-System umfassen können. Die verschiedenen Server 130 wie
etwa der entfernte Server 110 und der lokale Server 120 bieten typischerweise
verschiedene Dienste für
verbundene Endsysteme 150, LANs 165 und WANs 115 wie
etwa Dateispeicherung, Programmspeicherung, Datenbanken und sie
können
auch Internet- und Intraet-Dienste bereitstellen. Zum Beispiel kann
der lokale Server 120 ein Internet Service Provider sein,
der Internetverbindungen an verschiedene andere Server 130 wie
etwa den entfernten Server 110 bereitstellt. Die verschiedenen
anderen Server 130 wie etwa der entfernte Server 110,
ebenfalls als Beispiel, kann auch durch einzelne Personen, Unternehmen
oder Institutionen bereitgestellt werden, wie z. B Banken, Aktienhändler oder
jede andere Einheit die Websites bereitstellt oder sonst wie Webseiten,
Online-Dienste, Online-Marketing
oder Online-Verkäufe
bereitstellt. Die verschiedenen Server 130 einschließlich dem
entfernten Server 110 und dem lokalen Server 120 können auch
mit zusätzlichem
Speicher 145 oder anderen Speicherkapazitäten oder
-zugriff verbunden sein oder darüber
verfügen
wie etwa Systemfestplatten oder andere magnetische oder optische Speichergeräte. Wie
unten genauer besprochen, werden die Vorrichtung und das Verfahren
in Übereinstimmung
mit der vorliegenden Erfindung vorzugsweise innerhalb eines Systems
wie etwa dem Server 130, einem entfernten Server 110 oder
einem lokalen Server 120 verkörpert, wie in 2 dargestellt.
Wie ebenfalls oben genauer mit Bezug auf die Vorrichtungsausführungsformen
besprochen, die in 5 und 6 dargestellt
sind, kann das System auch interne Speicherkapazität oder externe
Speicherkapazität
umfassen, wie z. B. den Speicher 145, der in 2 dargestellt
ist.
-
Ein
Endsystem 150 wie etwa ein Personal Computer kann durch
einen lokalen Server 120 auf eine Website im Internet zugreifen,
in dem es im Allgemeinen eine Internetbrowser-Anwendung verwendet.
Wie oben erwähnt,
kann ein solcher Browser in der Lage sein, eine Netzwerkprogrammiersprache wie
etwa Java auszuführen
oder laufen zu lassen. Typischerweise fordert das Endsystem 150 über den Browser
eine Webseite an, die in Paket-basierter Form von einem entfernten
Server 110 (oder einem anderen Server 130) durch
den lokalen Server 120 zur Anzeige auf dem Endsystem 150 herunter
geladen wird. Eine solche Webseite kann erzeugt werden, indem eine
Standardsprache wie etwa Hypertext Markup Language („HTML"), dynamisches HTML,
eine Skriptsprache wie etwa JavaScript, Per1 oder Tc1 oder jeder
andere äquivalente
Sprache verwendet wird, insbesondere da sich Grenzen oder Unterscheidungen
zwischen und unter Markup-Sprachen,
Script-Sprachen und Programmiersprachen verwischen (daher werden
alle solchen Sprachen, die herunterladbaren und ausführbaren
Code bereitstellen, einzeln und zusammen hier als „Netzwerksprachen" oder „Netzwerkprogrammiersprachen” bezeichnet,
einschließlich
Sprachen wie etwa Java und JavaScript).
-
Weiter
mit
2 kann die angeforderte Webseite spezielle oder
bezeichnete Schlüsselworte enthalten,
die dazu bestimmt sind, eine Netzwerkprogrammiersprache zu starten,
aufzurufen oder zu spezifizieren. Zum Bespiel werden Java Anwendungen aufgerufen,
in dem ein Schlüsselwort
verwendet wird, das als ein „Tag" und insbesondere
als ein „Applet" Tag („<APPLET>") bezeichnet wird (andere Versionen
von HTML wie etwa HTML 4.0 sind auch dazu ausgelegt, um einen neuen
Tag zu unterstützen,
der als ein object tag („<OBJECT>") bezeichnet wird, der als eine Erweiterung
oder ein Ersatz des Applet Tags geplant ist; daher soll ein Bezug
auf einen Applet Tag, wie er hier gebraucht wird, auch einen Bezug
auf andere Schlüsselwörter oder
Tags bedeuten und umfassen, die eine ausführbare Netzwerkprogrammiersprache
wie etwa den object tag aufrufen). Ein Schlüsselwort wie etwa ein Applet
Tag hat typischerweise notwendige oder wünschenswerte Attribute, im Allgemeinen
einen Namen oder ein Referenzattribut und eine Menge an Raun (Höhen- und
Breiten-Attribute), die das Applet bei der Anzeige verwendet. Für den Gebrauch
hier muss das Schlüsselwort
nur über einen
Namen oder ein Referenzattribut verfügen, das den ausführbaren
Code bezeichnet oder ihm sonst wie entspricht, d. h. der Name oder
das Referenzattribut entspricht oder bezeichnet den Code (wo er
immer er sich befindet), der zur Ausführung herunter geladen wird,
wenn das Schlüsselwort
aufgerufen wird. Genauer in Bezug auf Java ist ein Java-Programm,
das herunter geladen und ausgeführt
werden soll, in Computer-lesbarer Byte Code Form, die eine „class"-Erweiterung aufweist,
das aus Java-Quellcode unter Verwendung eines Java-Compilers umgewandelt
wird. Als objektorientierte Programmiersprache definiert Java eine „Klasse" als eine Ansammlung
von Daten und Verfahren (Prozeduren oder Funktionen), die mit den
Daten arbeiten. Als Ergebnis verwendet ein Java Applet als ein solches
Referenzattribut einen Parameter, der als „CODE" bekannt ist, um die Klasse von Java
Byte Code zu benennen oder zu bezeichnen, die zur Ausführung durch
den Webbrowser herunter geladen werden soll. Zusätzlich und allgemeiner kann
solcher Java Byte Code auch unter Verwendung eines Parameters „CODE BASE" bezeichnet werden,
um einen Namen und Ort der Klasse von Java Byte Code zu spezifizieren,
der auf einem anderen Server
130 vorhanden ist, d. h., dass
er auf einem Server
130 vorhanden ist, der nicht der Server
ist, der die Webseite bereitstellt, oder solcher Java Byte Code
kann unter Verwendung eines Archivparameters bezeichnet werden,
um eine ganze Gruppe von Java-Klassen-Dateien zu spezifizieren für schnelleres,
gleichzeitiges herunterladen.
-
Weiter
mit 2, wenn ein Endsystem 150 eine Webseite
anfordert, wird die Webseite von einem entfernten Server 110 (durch
einen lokalen Server 120) herunter geladen und enthält typischerweise Text
(der unter Verwendung von HTML formatiert ist), scripting (Skripte)
und Schlüsselwörter einer
Netzwerksprache wie etwa Applet Tags. Wenn das Endsystem 150 ein
Schlüsselwort
wie etwa ein Applet tag aufruft, in dem z. B. mit einer Maus auf
Hypertext oder einen Knopf einer graphischen Benutzeroberfläche geklickt
wird, überträgt der Browser
eine Anfrage an den entfernten Server 110 zum Herunterladen
des angeforderten Applets, wobei die Anforderung eine entsprechende
Referenz aufweist oder enthält,
wie z. B. den Klassennamen, der in dem Applet Tag bezeichnet ist.
Der entfernte Server 110 überträgt dann den entsprechenden
angeforderten Code (und alle angeforderten Daten), und dieser Code
kann dann durch den Browser des Endsystems 150 wie etwa
die JVM ausgeführt
werden. Wie oben erwähnt,
da ausführbarer
Code von einer potentiell unbekannten oder nicht vertrauenswürdigen Quelle
herunter geladen wird, wurde die Java-Architektur so ausgelegt, um
Verletzungen der Sicherheit zu verhindern, die ihren Ursprung in
einem Netzwerk wie etwa einem entfernten Server 110 haben,
in dem Merkmale wie etwa die Java Sandbox und der Java Byte Code-Verifizierer
verwendet werden. Wie ebenfalls oben erwähnt, bietet die vorliegende
Erfindung zusätzlichen
Schutz gegen Verletzungen der Sicherheit, die ihren Ursprung lokal,
d. h. in einem lokalen Endsystem 150 oder in einem lokalen
Server 120, haben.
-
Insbesondere
mit Bezug auf Java als eine bestimmte Netzwerksprache, wie detaillierter
unten mit Bezug auf 3 und 4 beschrieben
und in Übereinstimmung
mit der dynamischen Java-Klassenbenennung der vorliegenden Erfindung,
wenn ein Endsystem 150 eine Webseite von einem Server 130 anfordert
(z. B. von dem entfernten Server 110), erzeugt der Server 130 eine
neue Webseite, in der alle Java Applets neue, unterscheidbare (oder
eindeutige) Klassennamen haben und speichert den entsprechenden
ausführbaren
Java Byte Code, wobei der jeweilige unterscheidbare (oder eindeutige)
Klassenname jedes Applets verwendet wird. Damit das Endsystem 150 den
ausführbaren
Java Byte Code anfordern kann, muss es darauf hin den neuen unterscheidbaren
(oder eindeutigen) Klassennamen verwenden, der mit der Webseite
geliefert wird, und der entsprechende ausführbare Byte Code wird dann
zu diesem Zeitpunkt von dem Server 130 herunter geladen.
Da jeder andere Java Byte Code, der lokal gespeichert sein könnte, d.
h. auf dem Endsystem 150 oder dem lokalen Server 120,
unter Verwendung eines vorher erzeugten und anderen Namens gespeichert
worden wäre,
kann solcher Java Byte Code nicht unbeabsichtigt durch das Endsystem 150 ausgeführt werden;
vielmehr wird die JVM des Endsystems 150 den neuen, unterscheidbar
benannten Java Byte Code aufrufen, der nur auf dem spezifischen
Server 130 (wie etwa den entfernten Server 110)
verfügbar
ist und der (noch) nicht auf dem Endsystem 150 oder dem
lokalen Server 120 verfügbar ist.
Die Vorrichtung, das Verfahren und das System der vorliegenden Erfindung
bieten dadurch erhöhte Netzwerksicher heit,
da es extrem unwahrscheinlich ist, dass irgendein vorher und lokal
gespeicherter Java Byte Code unter Verwendung des genau identischen
Namens gespeichert worden wäre
wie der neue, unterscheidbare (oder eindeutige) Klassenname (der
separat und unabhängig
aufs Neue (de novo) erzeugt und in dem Applet Tag der neu erzeugten Webseite
bereit gestellt wird). Abhängig
von dem gewünschten
Grad der Sicherheit könnten
z. B. vollständig
neue Applet-Klassennamen erzeugt werden, z. B. unter Verwendung
eines Zufallsgenerators; lokal gespeicherter Byte Code würde nur
ausgeführt, wenn
er vorher gespeichert würde
unter Verwendung von a priori Wissen des zufällig erzeugten, eindeutigen
Klassennamens, was höchst
unwahrscheinlich, wenn nicht unmöglich
ist. Angenommen, dass eine Verletzung der physischen Sicherheit
eines Endsystems 150 vorläge, bei der schädlicher
Java Byte Code lokal gespeichert worden wäre, würde daher dieser lokal gespeicherte
Byte Code nicht ausgeführt.
Stattdessen wird die JVM des Webbrowsers in dem Endsystem 150 nur
den unterscheidbar benannten Byte Code anfordern und daraufhin ausführen. Trotz
der angenommenen Verletzung der physischen Sicherheit, in dem potentiell
schädlicher
Byte Code lokal gespeichert wurde, wird deshalb kein weiterer Schaden
durch die unbekannte, potentielle Ausführung von Java Byte Code durch
die JVM des Webbrowsers folgen, da die dynamische Benennung der vorliegenden
Erfindung hilft sicher zu stellen, dass aller solcher auszuführender
Byte Code unmittelbar aufs Neue empfangen wird, vermutlich direkt
von einer bekannten oder vertrauenswürdigen Quelle. Die dynamische
Benennung der vorliegenden Erfindung verhindert dadurch die unbewusste
Ausführung
von potentiell schädlichen,
lokal gespeichertem Byte Code.
-
3 ist
ein Flussdiagramm, das eine bevorzugte Ausführungsform eines Verfahrens
in Übereinstimmung
mit der folgenden Erfindung zeigt, nämlich dynamische Java-Klassenbenennung
als ein bevorzugtes Verfahren zum Bereitstellen von Netzwerksicherheit
für ausführbaren
Code. Mit Bezug auf 3 beginnt das Verfahren beim
Startschritt 200 mit dem Empfangen einer Anforderung für eine Webseite,
z. B. einer Webseite „ABC" (Schritt 205).
Eine solche Anfrage wird typischerweise durch ein Endsystem 150 (durch
seinen Webbrowser) übertragen und durch
einen entfernten Server 110 (über einen lokalen Server 120)
empfangen. Das Verfahren bestimmt dann, typischerweise durch den
entfernten Server 110, ob die angeforderte Webseite einen
oder mehrere Java Apple Tags oder andere Schlüsselwörter aufweist (oder aufweisen
sollte), die zum Aufrufen von ausführbarem Code bestimmt sind
(Schritt 210). Wenn die angeforderte Webseite solche Applet
Tags nicht erfordert, kann die angeforderte Webseite bereitgestellt
werden (Schritt 215), und das Verfahren endet mit dem Return-Schritt 255.
Wenn die angeforderte Webseite ein oder mehrere Applet Tags oder andere
Schlüsselwörter bei
Schritt 210 erfordert, schreitet das Verfahren zu Schritt 220 fort
und erzeugt einen Applet Tag mit einem neuen, unterscheidbaren oder
eindeutigen Klassennamen als dem Referenzattribut, z. B. einem erforderlichen
Namen, Code, Codebasis oder Archivattribut. Das Verfahren speichert
dann bei Schritt 125 den Byte Code für dieses Applet mit oder unter
demselben unterscheidbaren oder eindeutigen Klassennamen. Das Verfahren
bestimmt dann, ob zusätzliche
Applet Tags für
die angeforderte Webseite erforderlich sind (Schritt 230).
Wenn bei Schritt 230 zusätzliche Applet Tags benötigt werden,
geht das Verfahren zu den Schritten 220 und 225 zurück und fährt damit
fort, ein zweites Applet Tag, das eine zweiten unterscheidbaren
oder eindeutigen Klassennamen aufweist, zu erzeugen und den Byte
Code für
das zweite Applet mit oder unter seinem zweiten unterscheidbaren
oder eindeutigen Klassennamen zu speichern. Das Verfahren fährt wiederholt
die Schritte 220 und 225 für jedes solche zusätzliches
Applet, erzeugt unterscheidbare Namen und speichert Byte Code für solche
dritten, vierten ... bis zu n-ten Applets, bis bei Schritt 230 kein
weiteres Applet mehr angefordert wird und das Verfahren dann zu
Schritt 235 fortfährt. Bei
Schritt 235 wird durch das Verfahren die angeforderte Webseite
mit allen seinen Applet Tags, die die jeweiligen neuen, unterscheidbaren
(oder eindeutigen) Klassennamen aufweisen, erzeugt und bereitgestellt.
Wenn daraufhin bei Schritt 240 eine Anfrage nach einem
oder mehreren Applets (Applet-Klassen oder Applet-Klassenpaketen)
mit ihrem (oder ihren) jeweiligen unterscheidbaren oder eindeutigen
Klassennamen erhalten wird, dann überträgt das Verfahren bei Schritt 245 den
entsprechenden Applet Byte Code mit dem jeweiligen unterscheidbaren
oder eindeutigen Klas sennamen. Der übertragene, unterscheidbar
benannte Applet Byte Code kann dann ausgeführt werden, z. B. durch das
bestimmte Endsystem 150, das den Applet Byte Code durch
seinen unterscheidbaren Klassennamen angefordert hatte. Nach den
Schritten 240 oder 245, wenn ein oder mehrere
zusätzliche
Webseiten wie etwa „DEF" oder „GHI" angefordert werden
(Schritt 250), wird das Verfahren dann für jede solche
zusätzliche
Webseite wiederholt und kehrt zu Schritt 210 zurück. Wenn
bei Schritt 250 keine Webseiten mehr angefordert werden,
kann das Verfahren bei Return-Schritt 255 enden.
-
Es
gibt eine große
Anzahl von Verfahren oder Prozeduren, die in 3 nicht
zusätzlich
dargestellt sind, die bei Schritt 220 verwendet werden
können,
um ein Schlüsselwort
mit einer unterscheidbaren Referenz auf ausführbaren Code zu erzeugen, z. B.
ein Applet Tag mit einen unterscheidbaren oder eindeutigen Klassennamen.
Wie oben erwähnt,
in Abhängigkeit
von dem gewünschten
Grad der Sicherheit, können
Applet-Klassennamen entweder eindeutig unterscheidbar für jeden
Zugriff auf eine Webseite durch jeden Browser eines Endsystems 150 erzeugt
werden (durch einen Server 130). Zum Beispiel können für sehr hohe
Sicherheit Applet-Klassennamen neu und eindeutig zu dem Zeitpunkt
erzeugt werden zu dem die Webseite angefordert wird, unter Verwendung
eines Zufallsgenerators oder einer anderen Methodologie oder Algorithmus, die
Namen erzeugen, die in keiner Weise leicht vorhergesehen werden
können.
Dieses Zufallsverfahren kann mehr Verarbeitungszeit erfordern, als
es für
viele Anwendungen wünschenswert
ist, da es Editieren der Applet-Klasse selbst und Neuübersetzung
des neu editierten Java Quellcodes erfordern kann. Während dies
beträchtliche
Sicherheit bietet, kann die potentiell längere Verarbeitungszeit des
Zufallsverfahrens andere weniger sichere Verfahren für eine gegebene
Anwendung wünschenswerter
machen. Zum Beispiel können
viele Gebrauchsanwendungen, die nicht mit wesentlichen Sicherheitsproblemen
verbunden sind, eine hohe Geschwindigkeit für eine Zufriedenheit des Verbrauchers
erfordern, z. B. die Fähigkeit,
eine Textseite innerhalb von 10 Sekunden dynamisch zu laden und
zu übertragen.
Entsprechend kann ein anderes Verfahren das Erzeugen eines vorbestimmten
Satzes von Schlüsselwortreferenzen und
entsprechenden ausführbaren
Code umfassen, z. B. einer Bibliothek von Applet-Klassennamen von jeder
gewünschten
Größe, die
wiederum in keiner Weise leicht vorhergesagt werden kann. Zum Beispiel
könnten
Bibliotheken von Hunderten bis zu Tausenden von unterscheidbaren
oder eindeutigen Applet-Klassennamen im Vorhinein erzeugt und gespeichert
werden, zusammen mit dem entsprechenden Applet-Klassen Byte Code.
Während
dies potentiell mehr Speicher oder Speicherkapazität verbraucht, könnte dieses
Bibliotheksverfahren sowohl den gewünschten Grad von Sicherheit
als auch die gewünschte
Schnelligkeit der Verarbeitung bieten, so dass unterscheidbar benannte
Applet Tags zum Einfügen
in die angeforderten Webseiten greifbar sind und dass die entsprechenden
unterscheidbar benannten Applet Byte Code-Klassen zum Herunterladen
greifbar sind, wenn und falls sie angefordert werden.
-
Ebenfalls
in Abhängigkeit
von dem gewünschten
Grad der Sicherheit können
die dynamisch erzeugten Klassennamen für jeden Zugriff auf eine Webseite
vollständig
eindeutig oder in höchstem Maße unterscheidbar
sein, oder sie können
eine geringere Unterscheidbarkeit aufweisen oder einen gewissen
Grad an Wiederholung beinhalten, so dass manche Namen (und der entsprechende
gespeicherte Byte Code) periodisch wieder verwendet oder bei anderen
Gelegenheiten einfach wieder verwendet werden. Zum Beispiel könnte eine
Bibliothek von Tausenden von Namen und entsprechendem Code erzeugt
und periodisch für
mehr als einen Zugriff auf eine Webseite verwendet werden unter
einer Sicherheitsannahme, dass es höchst unwahrscheinlich ist, dass
ein „Hacker" die gesamte Bibliothek
(oder wesentliche Teil der Bibliothek) duplizieren und den entsprechenden
Code auf einem Endsystem 150 oder einem lokalen Server 120 lokal
speichern könnte, ohne
Wissen des Anwenders oder ohne dass sonst die Verletzung der physischen
Sicherheit entdeckt würde.
In Verbindung mit höheren
Sicherheitsebenen können
vollständig
eindeutige Klassennamen wünschenswert
sein.
-
Wie
oben erwähnt,
betrifft der Bereich der vorliegenden Erfindung das Bereitstellen
von zusätzlicher
Sicherheitsfunktionalität
für ausführbaren
Code, der über
ein Netzwerk herunter geladen werden kann, und er ist nicht auf
Java als Netzwerkprogrammiersprache beschränkt, auf JavaScript als eine Scriptsprache,
auf HTML als eine Markup-Sprache oder auf Applet Tags oder object
tags als Schlüsselwörter, die
das Herunterladen des ausführbaren
Codes herbeiführen. 4 ist
daher ein Flussdiagramm, das allgemeiner ein Verfahren zum Bereitstellen
von Netzwerksicherheit für
ausführbaren Code
in Übereinstimmung
mit der vorliegenden Erfindung zeigt, das in einem breiteren Netzwerkkontext für jeden
Typ von herunterladbarem, ausführbarem Code
verwendet werden kann. Das Verfahren beginnt bei Startschritt 300 mit
dem Empfangen einer Anfrage nach Netzwerkinformationen, die typischerweise
von einem Endsystem 150 an einen entfernten Server 110 oder
ein anderes System (wie in 2 gezeigt) übertragen
wird. Die Netzwerkinformationen können in der Form einer Seite
des World Wide Web oder in jedem anderen Typ von Format oder Inhalt vorliegen.
Das Verfahren bestimmt dann bei Schritt 310, ob die angeforderten
Informationen ein oder mehrere Schlüsselwörter aufweisen (oder aufweisen sollten),
die ausführbaren
Code aufrufen, wie z. B. die Applet Tags oder object tags von Java.
Wenn die angeforderten Netzwerkinformationen solche Schlüsselwörter nicht
enthalten oder enthalten sollen (Schritt 310), werden die
angeforderten Netzwerkinformationen bereitgestellt (Schritt 315),
und das Verfahren kann enden (Return-Schritt 350). Wenn
die angeforderten Netzwerkinformationen ein Schlüsselwort enthalten (Schritt 310),
erzeugt das Verfahren ein Schlüsselwort
mit einer unterscheidbaren oder eindeutigen Referenz auf entsprechenden
ausführbaren
Code (Schritt 320) wie z. B. das Erzeugen eines Applet
Tags mit einem unterscheidbaren Java-Klassennamen, der auf entsprechenden
ausführbaren
Java Byte Code verweist. Der entsprechende ausführbare Code wird mit oder unter
der unterscheidbaren Referenz gespeichert oder ist darunter zugänglich (Schritt 325),
z. B. als Speichern von entsprechendem Java Byte Code unter seinem
unterscheidbaren Klassennamen. Wie oben mit Bezug auf 3 erwähnt, kann
eine solche Schlüsselworterzeugung
bei Schritt 320 auf vielfältige Weise durchgeführt werden,
einschließlich
durch Zufallserzeugung und durch Erzeugung mittels eines vorbestimmten
Datensatzes (Bibliothek). Nach den Schritten 320 und 325 bestimmt
das Verfahren, ob zusätzliche
Schlüsselwörter in den
angeforderten Netzwerkinformationen erforderlich sind (Schritt 330),
und falls ja, werden die Schritte 320 und 325 für jedes
solche zusätzliche
Schlüsselwort
wiederholt, indem für jedes
Schlüsselwort
unterscheidbare Referenzen erzeugt und entsprechender Code gespeichert
wird. Wenn bei Schritt 330 keine zusätzlichen Schlüsselwörter benötigt werden,
stellt das Verfahren die Netzwerkinformationen mit allen Schlüsselwörtern, die ihre
jeweiligen unterscheidbaren Referenzen aufweisen, bereit (Schritt 335),
z. B. als Bereitstellen einer Webseite mit allen Applet Tags oder
object tags mit ihren jeweiligen eindeutigen Applet-Klassennamen. Wenn
daraufhin eine Anfrage mit der unterscheidbaren Referenz erhalten
wird (Schritt 340), stellt das Verfahren den entsprechenden
ausführbaren
Code bereit (Schritt 345), z. B. als Bereitstellen des
entsprechenden Java Byte Codes zur Ausführung durch eine JVM eines
Webbrowsers. Nach den Schritten 315 und 345 oder
wenn keine Anforderungen erhalten werden (Schritt 340),
kann das Verfahren enden (Return-Schritt 350).
-
5 ist
ein Blockdiagramm, das eine Vorrichtung 400 in Übereinstimmung
mit der vorliegenden Erfindung zeigt. Wie oben erwähnt, ist
in der bevorzugten Ausführungsform
die Vorrichtung 400 in einem System enthalten, umfasst
oder verkörpert
wie z. B. einem Server 130 oder insbesondere einem entfernten
Server 110 oder einem lokalen Server 120; ein
solches System kann auch zusätzlichen
Speicher 145 oder weitere Speicherkapazität umfassen.
Mit Bezug auf 5 umfasst die Vorrichtung 400 einen Empfänger (oder
Mittel zum Empfangen) 410, einen Ermittler (oder Mittel
zum Ermitteln) 420, einen Erzeuger (oder Mittel zum Erzeugen) 430,
Speicher (oder Mittel zum Speichern) 440, und einem Transmitter
(oder Mittel zum Übertragen) 450.
Wie unten detaillierter besprochen, verfügt die Vorrichtung 400 über die
Zustände
und führt
das Verfahren aus, das in den 1, 3 und 4 dargestellt
ist. Der Empfänger 410 und
der Transmitter 450 können
jede Eingabe- bzw. Ausgabeschnittstelle (Input/Output, I/O) sein,
die für
den gewünschten
oder ausgewählten
Netzwerkkanal geeignet sind, wie z. B. eine T1-Schnittstelle, wenn sie an das Netzwerk 180 über eine
T1-Telekommunikationsverbindung,
eine geeignete ISDN-Schnittstelle, eine Koaxi alkabel- oder eine faseroptische
Schnittstelle oder eine analoge Schnittstelle verbunden sind. Der
Empfänger 410 und
der Transmitter 450 werden jeweils für den Empfang und die Übertragung
von Informationen, Code, Anfragen oder anderen Nachrichten verwendet,
typischerweise in Paket-basierten Formaten wie z. B. Internet-Protokollpaketen.
Zum Beispiel wird der Empfänger 410 für den Empfang
von Anfragen für
Webseiten oder andere Netzwerkinformationen verwendet, und der Transmitter 450 wird
zum Übertragen
von angeforderten Webseiten und für das Übertragen von ausführbarem
Code wie etwa Java Byte Code verwendet. Der Speicher 440 ist
typischerweise ein Speichersystem wie z. B. ein elektromagnetisches
Festplattenlaufwerk. Beim Speicher 440 kann es sich um jede
Form von elektromagnetischem, optischem oder anderem Typ von Speicher
oder Speicherkomponenten handeln, und er kann innerhalb des Speichers 145 für Systemausführungsformen
enthalten sein (und nicht als eine separate Komponente einer Vorrichtung 400 betrachtet
werden). In der bevorzugten Ausführungsform
und wie unten detaillierter mit Bezug auf 6 besprochen,
sind der Ermittler 420 und der Erzeuger 430 in
einem Prozessor verkörpert
wie z. B. einem Mikroprozessor, einem digitalen Signalprozessor,
einem anwendungsspezifischen integrierten Schaltkreis (Application
Specific Integrated Circuit, „ASIC") oder einer Gruppierung
von solchen Prozessoren oder ICs.
-
Weiter
in Bezug auf 5, wenn der Empfänger 410 eine
Anforderung für
Netzwerkinformationen empfängt
(typischerweise übertragen
von einem Endsystem 150), z. B. eine Anfrage für eine Webseite,
bestimmt der Ermittler 420, ob die angeforderten Informationen
ein oder mehrere Schlüsselwörter aufweisen
(oder aufweisen sollten), die ausführbaren Code aufrufen, wie
z. B. die Applet Tags oder object tags von Java. Wenn die angeforderten
Netzwerkinformationen solche Schlüsselwörter nicht enthalten, weist
der Ermittler 420 den Erzeuger 430 an, die angeforderten
Netzwerkinformationen bereit zu stellen, die wiederum durch den
Transmitter 450 übertragen werden
(an ein Endsystem 150 über
verschiedene Router 125 und Server 130). Wenn
die angeforderten Netzwerkinformationen ein Schlüsselwort enthalten, weist der
Ermittler 420 den Erzeuger 430 an, ein Schlüs selwort
mit einer unterscheidbaren oder eindeutigen Referenz auf entsprechenden
ausführbaren Code
zu erzeugen, z. B. durch Erzeugen eines Applet Tags mit einem unterscheidbaren
Java-Klassennamen, der auf entsprechenden ausführbaren Java Byte Code verweist.
Der Erzeuger 430 speichert auch den entsprechenden ausführbaren
Code in dem Speicher 440 mit, unter oder zugreifbar durch die
unterscheidbare Referenz, wie z. B. durch Speichern des entsprechenden
Java Byte Codes mit seinem unterscheidbaren Klassennamen. Wie oben
in Bezug auf 3 und 4 erwähnt, kann
solche Schlüsselworterzeugung
auf vielfältige
Weise durch den Generator 430 erfolgen, einschließlich durch
Zufallserzeugung und durch Erzeugung mittels einer Bibliothek (vorbestimmter
Datensatz). Der Ermittler 420 stellt dann fest, ob zusätzliche
Schlüsselwörter in den
angeforderten Netzwerkinformationen erforderlich sind und wenn ja,
weist er den Erzeuger 430 für jedes solche zusätzliche
Schlüsselwort
an, unterscheidbare Referenzen zu erzeugen und entsprechenden ausführbaren
Code für
jedes Schlüsselwort zu
speichern (im Speicher 440). Wenn keine zusätzlichen
Schlüsselwörter benötigt werden,
stellt der Generator 430 (zur Netzwerkübertragungen durch den Transmitter 450)
die Netzwerkinformationen mit allen Schlüsselwörtern und ihren jeweiligen
unterscheidbaren Referenzen bereit wie z. B. durch Bereitstellen einer
Webseite mit allen Applet Tags oder object tags mit ihren jeweiligen
eindeutigen Applet-Klassennamen.
Wenn daraufhin eine Anfrage mit der unterscheidbaren Referenz durch
den Empfänger 410 empfangen
wird wie durch den Ermittler 420 festgestellt, liefert
der Generator 430 (ebenso für Netzwerkübertragung durch den Transmitter 450)
den entsprechenden ausführbaren
Code wie z. B. durch Bereitstellen von entsprechendem Java Byte
Code zur Ausführung
durch eine JVM eines Webbrowsers.
-
6 ist
ein Blockdiagramm das eine bevorzugte Vorrichtung 500 in Übereinstimmung
mit der vorliegenden Erfindung zeigt. Wie oben erwähnt, ist in
der bevorzugten Ausführungsform
die Vorrichtung 500 in einem System enthalten, umfasst
oder verkörpert,
wie z. B. einem Server 130 oder insbesondere einem entfernten
Server 110 oder einem lokalen Server 120; ein
solches System kann auch zusätzlichen Speicher 145 oder
andere Speicherkapazität
umfassen. Bezug nehmend auf 6 umfasst
die Vorrichtung 500 eine Netzwerkschnittstelle 520,
einen Prozessor 510 und ein Speichersystem 530.
Die Netzwerkschnittstelle 420 kann jede Eingabe- und Ausgabeschnittstelle
(I/O) sein, die für
den gewünschten oder
ausgewählten
Netzwerkkanal geeignet ist wie z. B. eine T1-Schnittstelle, wenn
sie mit dem Netzwerk 180 über eine T1-Telekommunikationsverbindung, eine
geeignete ISDN-Schnittstelle, eine Koaxialkabel- oder eine faseroptische
Schnittstelle oder eine analoge Schnittstelle verbunden ist. Die
Netzwerkschnittstelle 520 wird für den Empfang und das Übertragen
von Informationen, Code, Anfragen und anderen Nachrichten verwendet,
typischerweise in Paket-basierten Formaten wie z. B. Internet-Protokollpaketen
(und führt
die Funktionen des Empfängers 410 und
des Transmitters 450 aus, die oben mit Bezug auf 5 besprochen
wurde). Zum Beispiel wird die Netzwerkschnittstelle 520 für den Empfang
von Anfragen nach Webseiten oder anderen Netzwerkinformationen,
zur Übertragung
von angeforderten Webseiten und zum Übertragen von ausführbarem Code
wie z. B. Java Byte Code verwendet. Das Speichersystem 530 kann
jede Form magnetischem, optischem oder anderem Typ von Speicher
oder Speicherkomponente sein, und es kann innerhalb des Speichers 145 für Systemausführungsformen
enthalten sein (und nicht als eine separate Komponente einer Vorrichtung 500 betrachtet
werden). Ein Prozessor 510 ist mit der Netzwerkschnittstelle 520 über einen
Bus 515 (z. B. einen PCI-Bus) verbunden und kann auch mit
dem Speichersystem 530 verbunden sein (wenn ein solches
Speichersystem 530 separat in der Vorrichtung 500 enthalten
ist und nicht in dem Speicher 145 enthalten ist, der mit
einem Server 130 verbunden sein kann). Der Prozessor 510 kann
einen einzelnen integrierten Schaltkreis („IC") umfassen, oder er kann eine Mehrzahl
von integrierten Schaltkreisen oder anderen verbundenen, angeordneten oder
zusammen gruppierten Komponenten umfassen wie z. B. Mikroprozessoren,
digitale Signalprozessoren, ASICs, zugeordneten Speicher (wie z.
B. RAM und ROM) und andere ICs und Komponenten. Als Resultat sollte
der hier gebrauchte Begriff Prozessor so verstanden werden, dass
er gleichwertig bedeutet und umfasst einen einzelnen Prozessor oder
eine Anordnung von Prozessoren, Mikroprozessoren, Controller oder
eine andere Gruppierung von integrierten Schaltkreisen, die die
Funktionen ausführen,
die unten detaillierter besprochen werden, mit zugeordnetem Speicher
wie etwa Mikroprozessorspeicher oder zusätzliches RAM, ROM, EPROM oder E2PROM. Der Prozessor 510 führt die
Funktionen des Ermittlers 420 und des Erzeugers 430 aus,
die oben mit Bezug auf 5 besprochen wurden. Wie oben
auch mit Bezug auf 3 und 4 besprochen,
kann die Methodologie der Erfindung als ein Satz von Programmanweisungen
zur nachfolgenden Verarbeitung in dem Prozessor 510 mit
seinem zugeordneten Speicher und anderen äquivalenten Komponenten programmiert
und gespeichert werden.
-
In
der bevorzugten Ausführungsform
ist die Netzwerkschnittstelle 520 bereit zum Empfangen
von Anfragen für
Netzwerkinformationen, wie z. B. Anfragen nach Webseiten, und ist
bereit zum Übertragen von
Netzwerkinformationen wie etwa Webseiten und ausführbarem
Code. Der Prozessor 510 reagiert durch einen Satz von Programmanweisungen,
wenn er operativ verbunden ist (d. h. angeschaltet und hochgefahren),
um festzustellen, ob angeforderte Netzwerkinformationen ein oder
mehrere Schlüsselwörter aufweisen
(oder aufweisen sollten), die ausführbaren Code aufrufen wie z.
B. die Applet Tags oder object tags von Java. Wenn die angeforderten Netzwerkinformationen
solche Schlüsselwörter nicht enthalten
oder nicht enthalten sollen, reagiert der Prozessor 510 mit
dem Bereitstellen der angeforderten Netzwerkinformationen, die wiederum
durch die Netzwerkschnittstelle 520 übermittelt werden (an ein Endsystem 150 über verschiedene
Router 125 und Server 130). Wenn die angeforderten
Netzwerkinformationen ein Schlüsselwort
enthalten, reagiert der Prozessor 510 mit dem Erzeugen
eines Schlüsselwortes,
das eine unterscheidbare oder eindeutige Referenz auf entsprechenden
ausführbaren
Code aufweist, z. B. als Erzeugen eines Applet Tags mit einem unterscheidbaren
Java-Klassennamen, der auf entsprechenden ausführbaren Java Byte Code verweist,
und dem Speichern des entsprechenden ausführbaren Codes in dem Speichersystem 530 mit,
unter oder zugreifbar durch die unterscheidbare Referenz, z. B.
durch Speichern des entsprechenden Java Byte Codes mit seinem unterscheid baren
Klassennamen. Wie oben mit Bezug auf 3 und 4 erwähnt, kann
eine solche Schlüsselworterzeugung auf
vielfältige
Weise durch den Prozessor 510 erfolgen, einschließlich durch
Zufallserzeugung und durch Erzeugung mittels eines vorbestimmten
Datensatzes (Bibliothek). Der Prozessor 510 reagiert dann weiterhin
mit dem Feststellen, ob zusätzliche
Schlüsselwörter in
den angeforderten Netzwerkinformationen erforderlich sind und wenn
ja, erzeugt der Prozessor 510 die unterscheidbaren Referenzen
und speichert den entsprechenden ausführbaren Code für jedes
solche Schlüsselwort
in dem Speichersystem 530. Wenn keine zusätzlichen
Schlüsselwörter benötigt werden,
reagiert der Prozessor 510 mit dem Bereitstellen (für Netzwerkübertragung
durch die Netzwerkschnittstelle 520) der Netzwerkinformationen
mit allen Schlüsselwörtern mit
ihren jeweiligen unterscheidbaren Referenzen, z. B. durch Bereitstellen
einer Webseite mit allen Applet Tags oder object tags, die ihren
jeweiligen eindeutigen Applet-Klassennamen
haben. Wenn daraufhin eine Anfrage mit unterscheidbarer Referenz
durch die Netzwerkschnittstelle 520 empfangen wird, wie
es durch den Prozessor 510 festgestellt wird, reagiert
der Prozessor 510 mit dem Bereitstellen (für Netzwerkübertragung
durch die Netzwerkschnittstelle 520) des entsprechenden
ausführbaren
Codes, wie z. B. durch Bereitstellen des entsprechenden Java Byte
Codes zur Ausführung
durch eine JVM eines Webbrowsers.
-
Zahllose
Vorteile der verschiedenen Ausführungsformen
der vorliegenden Erfindungen sind offensichtlich. Erstens und vor
allem verhindert die vorliegende Erfindung die unwissentliche oder
ahnungslose Ausführung
eines schädlichen
Applets oder anderen „trojanischen
Pferdes" als Netzwerksprachenprogramm
oder Anwendung. Angenommen, dass die physische Sicherheit eines
lokalen Endsystems verletzt wurde, um ein schädliches Programm einzuschleusen,
wird deshalb aus der Nutzung des Netzwerksprachenprogramms, z. B.
einem Java Applet, kein weiterer Schaden entstehen. Die dynamische Java-Klassenbenennung
der vorliegenden Erfindung angenommen und wenn z. B. ein schädliches
Applet lokal gespeichert wurde, würde das schädliche Applet nicht ausgeführt; vielmehr
wird durch den Server ein anderer Java-Klassenname erzeugt, der
dann entsprechend durch das Endsystem für die selbe Funktionalität (oder
Objektorientierung) aufgerufen wird.
-
Ein
weiterer Vorteil der vorliegenden Erfindung ist die Leichtigkeit
der Implementierung. Die vorliegende Erfindung wird vorzugsweise
als ein Satz von Programmanweisungen verkörpert, die auf einem Netzwerkserver
liegen, und erfordert keine Änderung
der Hardware oder zusätzliche
Hardware. Als ein Ergebnis kann die vorliegende Erfindung mit erheblichen
Kostenersparnissen implementiert werden.
-
Ein
noch weiterer Vorteil der vorliegenden Erfindung ist ihre Transparenz
für den
Anwender. Die vorliegende Erfindung kann innerhalb eines Netzwerkservers
implementiert werden, und innerhalb eines lokalen Endsystems sind
keine Änderungen, Hinzufügungen oder
Anweisungen nötig.
Darüber
hinaus kann der Anwender von diesen zusätzlichen Sicherheitsmerkmalen
profitieren, ohne Wissen über seinen
Ablauf, ohne irgendwelche Kommandos oder Anweisungen eingeben zu
müssen
und ohne irgendeine Unbequemlichkeit. Aus denn Vorangehenden kann
erschlossen werden, dass zahllose Änderungen und Abwandlungen
bewirkt werden können, ohne
vom Bereich des neuen Konzepts der Erfindung abzuweichen. Es ist
selbstverständlich,
dass keine Beschränkung
in Bezug auf die spezifischen Verfahren und Vorrichtungen, die hier
gezeigt werden, beabsichtigt ist oder abgeleitet werden sollte.
Es ist selbstverständlich
beabsichtigt, mit den angehängten Ansprüchen alle
solchen Abweichungen abzudecken, die in den Bereich der Ansprüche fallen.