DE60010433T2

DE60010433T2 - Verfahren zur durchführung von sicherheitvorgaben in einem kleingerät unter verwendung von einer kontextsperre

Info

Publication number: DE60010433T2
Application number: DE60010433T
Authority: DE
Inventors: Joshua Susser; B. Mitchel BUTLER; Andy Streich; Eduard Redland de JONG
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-01-22
Filing date: 2000-01-20
Publication date: 2004-09-09
Anticipated expiration: 2020-01-21
Also published as: JP2003522986A; CN1619455A; US7478389B2; AU2617200A; HK1041334B; US20050091659A1; AU772045B2; EP1155365B1; EP1434121A2; CN1338069A; JP4996787B2; EP1434121B1; DE60010433D1; KR100688396B1; DE1155365T1; KR20010108114A; EP1155365A1; EP1434121A3; HK1041334A1; CN1157655C

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf die Computersicherheit und genauer gesagt auf Techniken zum Implementieren von Sicherheitsmerkmalen auf kleinformatigen Einrichtungen bzw. Geräten, wie z. B. Smart Cards.
Beschreibung des verwandten Standes der Technik
Im Stand der Technik ist eine Anzahl objektorientierter Programmsprachen wohlbekannt. Beispiele umfassen die Sprache C++ und die Sprache Smalltalk. Eine weitere derartige objektorientierte Sprache ist die Java^TM-Sprache. Diese Sprache wird in dem Buch Java^TM-Language Specification von James Gosling et al., veröffentlicht bei Addison-Wesley, beschrieben. Die Java^TM-Sprache ist besonders gut geeignet, auf einer virtuellen Java^TM-Maschine bzw. Java^TM Virtual Machine zu laufen. Eine derartige Maschine wird beschrieben in dem Buch Java^TM Virtual Machine Specification von Tim Lindholm und Frank Yellin, ebenfalls veröffentlicht bei Addison-Wesley.
Eine Anzahl kleinformatiger Einrichtungen bzw. Geräte sind im Stand der Technik ebenfalls bekannt. Diese umfassen Smart Cards, Mobiltelefone und verschiedene andere kleine oder Miniaturgeräte.
Smart Cards sind von ähnlicher Größe und Form wie eine Kreditkarte, enthalten jedoch typischerweise Datenverarbeitungsmerkmale innerhalb der Karte (beispielsweise einen Prozessor oder eine Logik, welche Verarbeitungsfunktionen ausführt), und einen Satz von Kontakten, durch welche Programme, Daten und andere Kommunikationsmöglichkeiten mit der Smart Card verbunden bzw. erreicht werden können. Typsicherweise umfaßt der Satz von Kontakten eine Stromversorgungsverbindung und eine Ausgabe bzw. Rückgabe, ebenso wie einen Takteingang, einen Rückstelleingang und einen Datenanschluß, über welchen Datenkommunikationen erfolgen können.
Information kann in eine Smart Card geschrieben und aus einer Smart Card geholt werden unter Verwendung eines Kartenannahmegerätes. Ein Kartenannahmegerät ist typischerweise ein peripheres Gerät, welches an einem Hauptcomputer angeschlossen ist und einen Kartenanschluß aufweist, wie z. B. einen Schlitz, in welchen eine Smart Card eingesetzt werden kann. Wenn die Smart Card eingesetzt ist, drücken Kontakte oder Bürsten von einem Anschluß gegen den oberflächlichen Anschlußbereich der Smart Card, um die Stromversorgung bereitzustellen, und um die Kommunikationen mit dem Prozessor und dem Speicher zu ermöglichen, die man auf einer Smart Card typischerweise findet.
Smart Cards und Kartenannahmeeinrichtungen (CADs) sind der Gegenstand außerordentlicher Standardisierungsanstrengungen, beispielsweise ISO 7816. Auf die WO 19237 wird verwiesen.
Die Verwendung von Firewalls für das Trennen autorisierter von nicht-autorisierten Benutzern ist in der Netzwerkumgebung wohlbekannt. Beispielsweise wird eine solche Firewall in der US-Patentanmeldung US-2002-169980-A beschrieben, die am 1. Dezember 1998 eingereicht wurde und den Titel trägt "AUTHENTICATED FIREWALL TUNNELLING FRAMEWORK" und auf den Namen des Erfinders David Brownell lautet.
Ein Teilsatz der vollständigen Leistungsmerkmale der Java^TM-Plattform ist für kleinformatige Geräte, wie z. B. Smart Cards, definiert worden. Dieser Teilsatz wird die Java Card^TM-Plattform genannt. Die Verwendungen der Java Card^TM-Plattform werden in den folgenden Veröffentlichungen beschrieben.
JAVA CARD^TM 2.0 – LANGUAGE SUBSET AND VIRTUAL MACHINE SPECIFICATION,
JAVA CARD^TM 2.1 – APPLICATION PROGRAMMING INTERFACES,
JAVA CARD^TM 2.0 – PROGRAMMING CONCEPTS,
JAVA CARD^TM APPLET DEVELOPER'S GUIDE.
Ein Arbeitsentwurf der ISO 7816 – Teil 11 ist für Stellungnahmen in Umlauf gebracht worden. Dieser Entwurf spezifiziert Standards für das Ermöglichen getrennter Ausführungskontexte für das Arbeiten auf einer Smart Card. Teile dieses Arbeitsentwurfes werden hier aufgenommen.
Die Idee eines Ausführungskontexts ist in der Computerwssenschaft wohlbekannt. Allgemein gesprochen stellt die Verwendung von mehreren Ausführungskontexten in einer Computerumgebung eine Möglichkeit bereit, unterschiedliche Programmodule oder Prozesse voneinander zu trennen oder zu isolieren, so daß sie ohne unangemessene wechselseitige Störung unabhängig voneinander arbeiten können. Wechselwirkungen zwischen verschiedenen Kontexten, falls überhaupt vorhanden, sind gewollt oder werden willkürlich hergestellt, anstatt daß sie zufällig auftreten und sie werden sorgfältig kontrolliert, um die Integrität jedes Kontexts zu bewahren. Ein Beispiel mehrerer Kontexte findet man in größeren Hardwareeinrichtungen, wie z. B. Mainframes, wo eine Mehrzahl virtueller Maschinen definiert sein kann, und jede derartige virtuelle Maschine ihren eigenen Ausführungskontext hat. Ein weiteres Beispiel findet man in dem US-Patent Nr. 5,802,519 auf den Namen des Erfinders De Jong, welches die Verwendung mehrerer Ausführungskontexte auf einer Smart Card beschreibt. Es versteht sich für Fachleute, daß eine Rechnerumgebung, die mehrere Ausführungskontexte bereitstellt, auch einen Mechanismus bereitstellen muß, um irgendwelchen gegebenen Ausführungscode dem entsprechenden Kontext zuzuordnen.
Weiterhin ist auch die Idee eines aktuellen Kontextes wohlbekannt. Bestimmte Rechnerumgebungen, die mehrere Kontexte unterstützen, behandeln zu irgendeinem gegebenen Zeitpunkt einen Kontext insbesondere als den aktiven Brennpunkt der Berechnung. Der Kontext kann als der "aktuelle Kontext" bezeichnet werden. Wenn der aktuelle Kontext wechselt, so daß irgendein anderer Kontext der aktuelle Kontext wird, so spricht man davon, daß eine "Kontextumschaltung" erfolgt. Es versteht sich für Fachleute auf diesem Gebiet, daß Rechnerumgebungen Mechanismen bereitstellen, um genau zu verfolgen, welcher Kontext der aktuelle ist, und um eine Kontextumschaltung zu ermöglichen.
Im Stand der Technik gab es auf dem Gebiet der kleinformatigen Geräte und insbesondere auf dem Gebiet der Smart Cards keine wechselseitige Arbeitsfunktion zwischen Kontexten, die auf den kleinformatigen Geräten liefen. Jeder Kontext arbeitete vollständig separat und konnte innerhalb seines Kontextraumes ordnungsgemäß ablaufen oder fehlschlagen, ohne andere Anwendungen oder Vorgänge in einem anderen Kontext zu beeinflussen.
Eine Ebene des Sicherheitsschutzes, welche durch die Java^TM-Plattform verwendet wird, wird üblicherweise als ein Sandkastenmodell bezeichnet. Unsicherer Code wird in einen "Sandkasten" verbracht, wo er sicher "spielen" kann, ohne an der "realen Welt" oder der vollständigen Java^TM-Umgebung irgendeinen Schaden anzurichten. In einer solchen Umgebung kommunizieren Java^TM-Applets nicht, sondern stattdessen hat jeder seinen eigenen Namensraum bzw. Namensumgebung.
Einige Betriebssysteme für Smart Cards erlauben nicht die Ausführung von Kontexten in der Weise, daß sie direkt kommunizieren, erlauben jedoch Kommunikationen über ein Betriebssystem oder über einen Server.
Probleme
Eine Reihe von Problemen tritt auf, wenn man versucht, Computerprogramme und andere Information auf einer kleinformatigen Einrichtung unterzubringen. Eines der einschränkenden Probleme ist die Tatsache bzw. das Vorliegen von sehr begrenztem Speicherraum. Dies erfordert oftmals außerordentliche Anstrengungen, um innerhalb des Speicherraumes die benötigte Funktionalität bereitzustellen.
Ein zweites Problem, welches mit kleinformatigen Geräten verknüpft ist, liegt in der Tatsache, daß unterschiedliche Hersteller kleinformatiger, Geräte unterschiedliche Betriebssysteme womöglich verwenden. Im Ergebnis sind Anwendungen, die für ein Betriebssystem entwickelt wurden, nicht notwendigerweise auf die von einem anderen Hersteller hergestellten kleinformatigen Geräte übertragbar.
Wenn Programme aus mehr als einer Programmquelle (Hersteller oder Verkäufer) auf einer einzelnen kleinformatigen Einrichtung angewendet werden bzw. ablaufen sollen, wird die Sicherheit zu einem Problemfaktor, wenn man versucht, eine Beschädigung vorhandener Programme und Daten zu vermeiden, wenn ein neues Programm auf das kleinformatige Gerät geladen wird. Dasselbe Problem besteht, wenn man einen Hacker oder eine böswillige Person daran hindern will, auf Programme und Daten zuzugreifen.
Es versteht sich, daß kleinformatige Geräte, wie z. B. Smart Cards nicht die Ressourcen haben, die notwendig sind, um getrennte virtuelle Maschinen zu implementieren. Nichtsdestotrotz ist es wünschenswert, eine strikte Sicherheit zwischen getrennten Ausführungskontexten aufrechtzuerhalten.
In der Vergangenheit wurde Sicherheit gewährleistet, indem man Anwendungen ausschließlich von derselben Quelle oder von einer bekannten, vertrauenswürdigen Quelle auf eine Smart Card oder eine andere kleinformatige Einrchtung geladen hat.
Dementsprechend wäre es wünschenswert, eine objektorientierte Wechselwirkung zwischen ausgewählten Ausführungskontexten nur auf sicheren Wegen über schnelle, effiziente Peer-to-Peer-Verbindungen zu ermöglichen, die dem Programmierer keine übermäßige Belastung aufbürden, jedoch das dynamische Laden von Applets ermöglichen bzw. erleichtern, die zu unterschiedlichen Zeiten von Quellen geschrieben wurden, denen man nicht vertraut.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ist auf das Bereitstellen einer Kontextbarriere (manchmal auch als Firewall bezeichnet) gerichtet, um eine Trennung und Isolierung eines Kontextes von einem anderen bereitzustellen und um einen kontrollierten Zugriff über die Barriere hinweg bereitzustellen, wenn dies erforderlich ist.
Gemäß der Erfindung können zwei Ausführungskontexte, die beispielsweise jeweils einen oder mehrere Applets enthalten, in derselben logischen (d. h. virtuellen oder realen) Maschine ablaufen und die gegeneinander geschützt sind, Information in einer kontrollierten, sicheren Weise austauschen, und zwar unter Verwendung von Sprachmechanismen, wie z. B. Mechanismen der objektorientierten Sprache. Sicherheit kann beispielsweise objektweise vorliegen. Demnach kann auf Basis einer Auswahl ein Verfahren in einem ersten Ausführungskontext auf ein erstes Objekt A in dem zweiten Ausführungskontext zugreifen, jedoch nicht auf ein zweites Objekt B in dem zweiten Ausführungskontext.
Gemäß einer beispielhaften Ausführungsform stellt eine verbesserte virtuelle Java^TM-Maschine (VM) gewisse Laufzeitüberprüfungen von versuchten Zugriffen über Ausführungskontexte in der VM bereit. Überprüfungen können automatisch durch die VM ausgeführt werden oder durch den Programmierer mit Unterstützung von der VM codiert werden. Dies kann geschehen unter Verwendung von Kommunikationsmechanismen auf Sprachniveau. Auf diese Weise kann man den Objektzugriff auf Ausführungskontexte in derselben Weise ausdrücken, wie auch andere Objektzugriffe unter Verwendung der Sprache ausgeführt werden. Diese Laufzeitüberprüfungen bzw. Überprüfungen während des Ablaufs stellen eine zweite Dimension der Verteidigung/Sicherheit über diejenige hinaus bereit, welche die Java^TM-Sprache und -Plattform bereitstellen.
Diese Mechanismen stellen einen Schutz beispielsweise gegen Sicherheitslöcher aufgrund von Programmiertehlern (wie z. B. der Erklärung eines Datums als "öffentlich" (global), wenn es nicht für alle Kontexte zugänglich sein sollte) bereit. Sie ermöglichen auch eine detaillierte bzw. gezielte Kontrolle der gemeinsamen Verwendung (wie z. B. der Auswahl von Objekten, die gemeinsam zu verwenden sind und der gemeinsam zu verwenden Applets).
Die Erfindung ist auch auf Computerprogrammprodukte und Trägerwellen gerichtet, die sich auf andere Aspekte der Erfindung beziehen.
Die vorstehenden und weitere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden deutlicher aus der folgenden genauen Beschreibung der vorliegenden Erfindung in Verbindung mit den zugehörigen Zeichnungen.
KURZE BESCHREIBUNG DER FIGUREN
Die Merkmale und Vorteile der vorliegenden Erfindung werden offensichtlich aus der folgenden Beschreibung, in welcher:
1 eine Darstellung eines mit einer Kartenannahmeeinrichtung ausgerüsteten Computers sowie einer Smart Card für die Verwendung mit der Kartenannahmeeinrichtung ist,
2 eine Darstellung eines mit einer Kartenannahmeeinrichtung ausgestatteten Computers ist, der mit einem Netzwerk verbunden ist,
3 eine beispielhafte Hardwarearchitektur eines kleinformatigen Gerätes, wie z. B. einer Smart Card, nach dem Stand der Technik ist,
4 Objekte veranschaulicht, auf welche durch Hauptfunktionen zugegriffen wird, wie es im Stand der Technik geschieht,
5 ein beispielhaftes Sicherheitsmodell ist, welches bei der Erläuterung der verschiedenen Ausführungsformen der Erfindung verwendet werden kann,
6 ein Blockdiagramm ist, welches die Trennung von Ausführungskontexten durch eine Firewall oder eine Kontextbarriere gemäß einem Aspekt der Erfindung zeigt,
7 eine Darstellung einer Softwarearchitektur ist, die beim Ausführen der Erfindung zweckmäßig ist,
8 ein Flußdiagramm eines Sicherheitserzwingungsvorgangs ist, welcher eine Firewall gemäß einem Aspekt der Erfindung implementiert,
9 ein Blockdiagramm ist, welches einen Objektzugriff über eine Firewall hinweg gemäß einem Aspekt der Erfindung zeigt,
10 ein Blockdiagramm ist, welches einen Kaskadenzugriff auf Objekte über eine Firewall hinweg zeigt,
11 ein Flußdiagramm eines Prozesses für das Gewähren von Zugriff durch eine Hauptfunktion in einem Kontext über eine Firewall in einen anderen Kontext ist,
12 ein Blockdiagramm ist, welches die Verwendung eines Eingabepunktobjektes veranschaulicht, um einen Zugriff über eine Firewall hinweg zu ermöglichen,
13 ein Blockdiagramm ist, welches die Verwendung einer globalen Datenstruktur, wie z. B. eines Arrays für den Zugriff über eine Firewall hinweg veranschaulicht,
14 ein Blockdiagramm ist, welches die Verwendung eines Superkontextes zeigt, um Zugriff über eine Firewall hinweg zu ermöglichen,
15 ein Blockdiagramm ist, welches die Verwendung von gemeinsam verwendbaren Interfaceobjekten darstellt, um Zugriff über eine Firewall hinweg zu ermöglichen,
16 ein Flußdiagramm eines Sicherheitserzwingungsvorgangs ist, der einen Zugriff über eine Firewall hinweg erlaubt,
17 das Flußdiagramm aus 16 mit Einzelheiten des Blockes 1620 zeigt,
18 ein Flußdiagramm ist, welches eine beispielhafte Implementierung des Blockes 1629 aus 17 zeigt.
BEZEICHNUNGEN UND NOMENKLATUR
Die folgende genaue Beschreibung wird im Zusammenhang mit Programmvorgängen präsentiert, die auf einem Computer oder auf einem Netzwerk aus Computern ausgeführt werden. Diese Beschreibungen und Darstellungen von Prozeduren sind die Mittel, die durch Fachleute auf diesem Gebiet verwendet werden, um in höchst effektiver Weise den wesentlichen Inhalt ihrer Arbeit anderen Fachleuten auf diesem Gebiet mitzuteilen.
Eine Prozedur bzw. Vorgang wird hier und allgemein als eine selbstkonsistente Sequenz aus Schritten verstanden, die zu einem gewünschten Ergebnis führt. Diese Schritte sind solche, welche physikalische Manipulationen physikalischer Größen erfordern. Üblicherweise, wenn auch nicht notwendigerweise, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die in der Lage sind, gespeichert, übertragen, kombiniert, verglichen oder in sonstiger Weise manipuliert zu werden. Es stellt sich gelegentlich als zweckmäßig heraus, insbesondere aus Gründen der gemeinsamen Verwendung, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen oder dergleichen zu bezeichnen. Es versteht sich jedoch, daß all diese und ähnliche Begriffe den passenden physikalischen Größen zuzuordnen sind und lediglich einfache Etiketten sind, die diesen Größen aufgeprägt werden.
Weiterhin werden die Manipulationen, welche ausgeführt werden, oftmals in Begriffen ausgedrückt, wie z. B. Addieren oder Vergleichen, welche üblicherweise mentalen Vorgängen zugeordnet werden, die durch eine Person ausgeführt werden. Eine solche Fähigkeit eines menschlichen Benutzers ist jedoch in den meisten Fällen nicht erforderlich oder wünschenswert bei den meisten der hier beschriebenen Vorgänge, die Teil der vorliegenden Erfindung bilden; die Vorgänge sind Maschinenvorgänge bzw. -operationen. Zweckmäßige Maschinen zum Ausführen der Vorgänge der vorliegenden Erfindung umfassen digitale Vielzweck- bzw. Allzweckrechner bzw. -computer oder sonstige Rechnereinrichtungen.
Die vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum Durchführen dieser Vorgänge. Die Vorrichtung kann speziell für den erforderlichen Zweck konstruiert sein oder sie kann aus einem Allzweck- oder Vielzweckcomputer bestehen, der gezielt aktiviert oder konfiguriert wird durch ein in dem Computer gespeichertes Computerprogramm. Die hier dargestellten Prozeduren bzw. Vorgänge beziehen sich nicht inhärent auf einen bestimmten Computer oder sonstige Vorrichtung. Es können verschiedene Maschinen für allgemeine Zwecke mit Programmen verwendet werden, die gemäß der hier bereitgestellten Lehre beschrieben sind oder es kann sich als bequemer herausstellen, eine besser spezialisierte Vorrichtung zu konstruieren und aufzubauen, um die erforderlichen Verfahrensschritte auszuführen. Die erforderliche Struktur für eine Vielfalt dieser Maschinen ergibt sich aus der hier gegebenen Beschreibung.
GENAUE BESCHREIBUNG
Als Anhang zu dieser Beschreibung findet sich Kapitel 6 eines Dokumentes mit dem Titel JAVA CARD RUNTIME ENVIRONMENT 2.1 SPECIFICATION. Dieser Entwurf eines Dokumentes, der eine weitere genaue Beschreibung spezieller Ausführungsformen der Erfindung bereitstellt, wird in seiner Gesamtheit als integrierter Teil der vorliegenden Erfindung einbezogen. Weitere Einzelheiten kann man aus der veröffentlichten Anmeldung entnehmen.
Auch wenn die ertinderischen Techniken nachstehend im Kontext des Beispiels einer Smart Card beschrieben werden, so ist dieses Beispiel lediglich veranschaulichend und soll nicht den Schutzumfang der Erfindung begrenzen.
1 ist eine Darstellung eines Computers 120, der mit einer Kartenannahmeeinrichtung 110 und einer Smart Card 100 für die Verwendung mit der Kartenannahmeeinrichtung 110 ausgerüstet ist. Im Betrieb wird die Smart Card 100 in die Kartenannahmeeinrichtung 110 eingesetzt und Stromversorgungs- und Datenverbindungen werden über einen Satz von Kontakten 105, welche an der Oberfläche der Smart Card 100 zugänglich sind, hergestellt. Wenn die Karte eingesetzt wird, stellen passende Kontakte von dem Kartenannahmegerät 110 eine Verbindung mit den Oberflächenkontakten 105 her, um die Karte mit Strom zu versorgen und um Kommunikationen mit dem darin enthaltenen Prozessor und Speicher zu ermöglichen.
2 ist eine Darstellung eines Computers, der mit einer Kartenannahmeeinrichtung ausgestattet ist, wie z. B. 120 in 1, und der mit einem Netzwerk 200 verbunden ist. Weiterhin ist mit dem Netzwerk eine Vielzahl weiterer Rechnereinrichtungen, wie z. B. ein Server 110, verbunden. Es ist möglich, Daten und Software über das Netzwerk 200 und unter Verwendung einer mit einer Karte ausgerüsteten Einrichtung 120 auf eine Smart Card zu laden. Ein Herunterladen dieser Art kann Applets oder andere Programme umfassen, die auf eine Smart Card geladen werden sollen, ebenso wie digitale Bargeldwerte und andere Informationen, die gemäß einer Vielfalt der elektronischen Geschäfts- und sonstiger Anwendungen verwendet werden. Diese Anweisungen und Daten, die verwendet werden, um Verarbeitungselemente der Kartenannahmeeinrichtung und der Smart Card zu steuern, können in einem flüchtigen oder nicht-flüchtigen Speicher gespeichert werden oder können direkt über eine Kommunikationsverbindung empfangen werden, wie z. B. eine Trägerwelle, welche die Instruktionen und/oder Daten enthält. Weiterhin kann das Netzwerk ein LAN oder WAN, wie z. B. das Internet, oder irgendein anderes Netzwerk sein.
3 ist eine beispielhafte Hardwarearchitektur eines kleinformatigen Gerätes, wie z. B. einer Smart Card, nach dem Stand der Technik. Wie in 3 dargestellt, ist ein Prozessor 300 mit einem Primärspeicher 310 verbunden, der einen Nur-Lese-Speicher 315 und/oder einen Speicher 316 mit wahlfreiem Zugriff (RAM) enthalten kann. Der Prozessor hat auch eine Verbindung zu einem sekundären Speicher 320, wie z. B. einem EEPROM, und zu einer Eingabe-/Ausgabeeinrichtung 330, wie z. B. einem seriellen Anschluß bzw. Port. Wie man sieht, können die kleinformatigen Geräte dieser Art sehr einfach sein.
4 zeigt, wie auf Objekte durch Hauptfunktionen zugegriffen wird, wie es im Stand der Technik geschieht. Wie in 4 dargestellt, kann das physikalische Gerät 400, wie z. B. die kleinformatige Einrichtung, eine oder mehrere Verarbeitungsmaschinen (virtuelle oder physikalische) enthalten, die auf einem Ausführungskontext 420 ablaufen. Der Ausführungskontext kann beispielsweise ein Kontext sein, der zu einem bestimmten Applet gehört. Ein oder mehrere Hauptfunktionen 430 (beispielsweise Applets oder Anwendungen) in dem Ausführungskontext können den Zugriff auf andere Objekte innerhalb des Ausführungskontexts anstreben. Solange der Zugriff innerhalb des Ausführungskontextes erfolgt, wird der Zugriff zugelassen und alles funktioniert normal.
5 ist ein beispielhaftes Sicherheitsmodell, welches für die Erläuterung der verschiedenen Ausführungsformen der Erfindung verwendet werden kann. Es ist nur eines von vielen Modellen, welche verwendet werden können, ist jedoch für diesen Zweck ein bequemes Modell. In diesem Modell schlägt eine Hauptfunktion (manchmal auch als Entität bezeichnet) 500 vor, mit einem Objekt, wie z. B. dem Objekt 520, eine Aktion 510 auszuführen. Der Hauptfunktion, dem Objekt und/oder der vorgeschlagenen Aktion können Sicherheitsüberprüfungen auferlegt werden.
In 5 sind zwei Typen von Objekten dargestellt, auf welche durch eine Hauptfunktion eine Aktion ausgeführt werden kann. Diese umfassen Datenobjekte (beispielsweise Daten1 und Daten2 (520, 520')) und die Entität 530. Eine Hauptfunktion kann mit irgendeinem dieser Objekte arbeiten oder versuchen zu arbeiten.
Während die Daten passiv sind, ist die Entität 530 aktiv. Die Diagrammlinie von der Hauptfunktion zu einer aktiven Entität wird ebenfalls als "Aktion" bezeichnet, jedoch könnte dies eine ausgeklügeltere und beliebig komplizierte Aktion sein, wie z. B. das Ausführen eines Funktions- oder Methodenaufrufs oder das Senden einer Nachricht, im Vergleich zu einer Aktion mit einem Datenobjekt. Wie auch mit den Daten, kann eine Sicherheitsüberprüfung, die durch das Betriebssystem erzwungen wird, die Identität der Hauptfunktion, die Identität der Entität und/oder der Art von Aktion verwenden. Weiterhin kann die Entität, wenn sie aktiv ist, ihre eigenen zusätzlichen Sicherheitsüberprüfungen ausführen. Diese können beliebig kompliziert sein, je nachdem, wie man es wünscht, und sie können die Identität der Hauptfunktion, die Identität der Entität selbst, der Aktion und/oder irgendeiner sonstigen Information verwenden, welche verfügbar ist.
In einem objektorientierten System (wie z. B. der Java Card^TM-Plattform) sind "Objekte" typischerweise eine Kombination aus Daten und Entität. Wenn eine Hauptfunktion versucht, auf ein Feld eines Objektes zuzugreifen, ist dies ein Datenzugriff – eine ziemlich einfache Aktion, die durch eine ziemlich einfache Sicherheitsüberprüfung geschützt ist. Wenn eine Hauptfunktion versucht, Zugriff auf eine Methode eines Objektes zu erhalten, so ist dies ein Entitätszugriff, der sowohl bei der Ausführung als auch bei der Sicherheitsüberprüfung beliebig kompliziert sein kann.
6 ist ein Blockdiagramm, welches die Trennung von Ausführungskontexten durch eine Firewall oder eine Kontextbarriere gemäß einem Aspekt der Erfindung zeigt. Die physikalische Einrichtung 400 und die Maschine 410 entsprechen denselben Gegenständen, wie sie in 4 dargestellt sind. Ein Ausführungskontext 420 zeigt eine Hauptfunktion 430, die versucht, auf das Objekt 440 innerhalb des Kontextes zuzugreifen. Dieser Zugriff wäre normalerweise erfolgreich. Der Ausführungskontext 420 zeigt jedoch auch eine Hauptfunktion 430, die versucht, auf das Objekt 640 des Ausführungskontextes 620 über eine Kontextbarriere 600 hinweg zuzugreifen. Normalerweise würde dieser Zugriff verhindert werden, wie es durch das X636 angezeigt wird, wo die Aktion 635 die Kontextbarriere 600 überschreitet.
7 ist eine Darstellung einer Softwarearchitektur, die beim Ausführen der Erfindung zweckmäßig ist. Diese Softwarearchitektur ist als eine Laufzeitumgebung 700 (Umgebung während der Laufzeit) dargestellt. Für das kleinformatige Gerät wird üblicherweise ein Betriebssystem 710 verwendet. Eine virtuelle Maschine 720 wird in einer beispielhaften Ausführungsform der Erfindung über das Betriebssystem implementiert. Die virtuelle Maschine könnte eine virtuelle Java Card^TM-Maschine oder irgendeine andere virtuelle Maschine sein. Die Leistungsmerkmale einer standardmäßigen virtuellen Maschine können erweitert werden, um die zusätzliche Funktionalität bereitzustellen, die hier beschrieben wird, oder die Funktionalität kann in Form getrennter Module bereitgestellt werden. Die virtuelle Maschine 720 kann einen Übersetzer oder eine integrierte Implementierung 730 enthalten, die einen Zugriff auf ein Laufzeitsystem 740 gewährt. Das Laufzeitsystem umfaßt das Objektsystem 750 zum Verwalten der objektorientierten Implementierung. Drei Kontexte 760, 770 und 780 sind dargestellt. Jeder Kontext wird von dem anderen durch eine Kontextbarriere (manchmal auch als Firewall bezeichnet) getrennt, die sich zwischen den Ausführungskontexten erstreckt. Der Kontext 760 ist in einer speziellen Ausführungsform ein Superkontext. Das heißt, der Kontext 760 hat Privilegien und Leistungsmerkmale bzw. Fähigkeiten, die für untergeordnete Kontexte 770 und 780 nicht verfügbar sind, möglicherweise unter Einschluß von Privilegien zur Erzeugung von Zugangspunktobjekten oder globalen Datenstrukturen für den Zugriff auf Objekte in untergeordneten Kontexten 770 und 780.
Jedes Objekt ist einem bestimmten Kontext zugeordnet. Man sagt, daß dieser Kontext jedes ihm zugeordnete Objekt besitzt. Das Laufzeitsystem 740 stellt eine Einrichtung zum eindeutigen Identifizieren von Kontexten bereit, sowie eine Einrichtung zum Spezifizieren und Identifizieren des aktuell laufenden Kontextes. Das Objektsystem 750 stellt einen Mechanismus für das Zuordnen von Objekten zu den besitzenden Kontexten bereit.
Beispielsweise kann das Laufzeitsystem 740 Kontexte mit einem eindeutigen Namen identifizieren und dementsprechend kann das Objektsystem 750 Objekte mit diesem Kontext zuordnen, indem es den Namen des Kontextes in der Kopfzeile bzw. Kopfdaten des Objektes zuordnet. Auf Information in den Kopfdaten des Objektes kann nicht durch Programme zugegriffen werden, die in der objektorientierten Sprache geschrieben sind, sondern diese sind nur für die virtuelle Maschine 720 selbst verfügbar. Alternativ kann das Laufzeitsystem 740 Kontexte identifizieren, indem es den Speicherraum in getrennte Bereiche aufteilt, und zwar jeweils für einen bestimmten Kontext, und dementsprechend kann das Objektsystem 750 Objekte diesem Kontext zuordnen, indem es den Speicher dieses Objektes dem Speicherraum des Kontextes zuordnet.
8 ist ein Flußdiagramm eines Sicherheitserzwingungsprozesses, der eine Kontextbarriere gemäß einem Aspekt der Erfindung implementiert. Wenn eine Hauptfunktion eine Aktion mit einem Objekt (800) aufruft, so wird eine Überprüfung vorgenommen, um zu bestimmen, ob das Objekt innerhalb des Kontextes der Hauptfunktion (810) liegt. Wenn dies nicht der Fall ist, wird die Aktion nicht zugelassen (840). Ansonsten wird die Aktion zugelassen (830). Dies ist die einfachste Form einer Kontextbarriere oder Firewall. In einer speziellen Ausführungsform wird die Aktion nicht zugelassen (840), indem eine Sicherheitsausnahme eingeworfen bzw. vorgebracht wird, falls das Objekt außerhalb des Namensraumes oder Speicherraumes des Kontextes liegt, welcher den Zugriff anfordert.
9 ist ein Blockdiagramm, welches den Objektzugriff über eine Firewall hinweg gemäß einem Aspekt der Erfindung zeigt. 9 ist 6 weitgehend ähnlich. 9 zeigt jedoch auch eine Hauptfunktion 900, die versucht, auf das Objekt 910 zuzugreifen, um die Aktion 905 mit dem Objekt 910 durchzuführen. Gemäß der Erfindung wird, anstatt den Zugriff durch die Firewall 600 zu blockieren in der Art und Weise, wie die Aktion 635 blockiert wird, die Aktion 905 zugelassen, so daß sie über die Firewall durch den Zugangspunkt 920 hinweg stattfindet, so daß die Hauptfunktion 900 die Aktion 905 mit dem Objekt 910 ausführen kann, ungeachtet der Tatsache, daß die Hauptfunktion und das Objekt sich in unterschiedlichen Ausführungskontexten befinden. Die Mechanismen hinter dem Zugangspunkt 920 werden unten unter Bezug auf die 12 bis 18 beschrieben. Man beachte, daß der Zugangspunkt 920 gemeinsam mit verhinderten Zugriffen, wie z. B. X636 existieren kann. Demnach stellt der Zugangspunkt 920 eine detaillierte bzw. feinabgestimmte Steuerung der gemeinsamen Verwendung (Sicherheit Objekt für Objekt) über die Kontextbarriere 600 hinweg bereit.
Wenn der Objektzugriff 900 ausgelöst wird, ist die Einstellung des aktuellen Kontextes der Kontext 420. Wenn das Objekt 910 ein Datenobjekt ist, so ist die Aktion 905 ein einfacher Datenzugriff und es wird kein Code in dem zweiten Kontext 620 ausgeführt. Wenn das Objekt 910 ein Entitätsobjekt ist und die Aktion 905 dazu führt, daß der Code des Objektes ausgeführt wird, so wird der Code in dem zweiten Kontext 620 ausgeführt. Damit der Code des Objektes 910 in dem richtigen Kontext 620 ausgeführt wird, führt die virtuelle Maschine 410 eine Kontextumschaltung durch. Die Kontextumschaltung ändert die Einstellung des aktuellen Kontextes so, daß es nunmehr der Kontext 620 wird und der vorherige Wert der Einstellung des aktuellen Kontextes wird gespeichert, so daß er später wiederhergestellt werden kann. Von diesem Zeitpunkt an wird Code in dem neuen aktuellen Kontext ausgeführt. Wenn die Aktion 905 abgeschlossen ist, wird die Steuerung an den Punkt zurückgegeben, der auf den Zugriff 900 folgt. Während dieser Rückkehr muß die virtuelle Maschine 410 den Wert der aktuellen Kontexteinstellung auf ihren vorherigen Wert wiederherstellen.
10 ist ein Blockdiagramm, welches kaskadenförmige Objektzugriffe über eine Firewall hinweg zeigt. 10 zeigt drei Ausführungskontexte 1000, 1010 und 1020. Die Hauptfunktion 1030 in dem Ausführungskontext 1 versucht, eine Aktion 1035 mit dem Objekt 1050 in dem Ausführungskontext 2 aufzurufen und macht dies über den Zugangspunkt 1070 in der Kontextbarriere 600. Das Objekt 1050 in dem Ausführungskontext 2 hat einen Objektzugriff 1040, der versucht, eine Aktion 1045 mit dem Objekt 1060 in dem Ausführungskontext 3 auszuführen. Er erreicht dies durch Verwendung des Zugangspunktes 1080 in der Kontextbarriere 600', welche die Ausführungskontexte 2 und 3 trennt. Das Objekt 1050 in dem Ausführungskontext 2 hat einen weiteren Objektzugang 1090, der eine Aktion 1095 auf einem Objekt 1099 in demselben Ausführungskontext ausführt, d. h. in dem Ausführungskontext 2. Beide Aktionen 1035 und 1045 führen zu Kontextumschaltungen, wie es im Zusammenhang mit der Erläuterung von 9 beschrieben wurde. Da jedoch die Aktion 1095 die Kontextbarriere nicht überschreitet, ist für diese Ausführung keine Kontextumschaltung erforderlich und geschieht deshalb auch nicht.
11 ist ein Flußdiagramm eines Prozesses für das Gewähren eines Zugriffs durch eine Hauptfunktion einem Kontext über eine Firewall hinweg in einen anderen Kontext hinein. Es gibt im wesentlichen drei Schritte in diesem Prozeß. In dem Ausführungskontext 2 wird ein Objekt erzeugt, auf welches zugegriffen werden soll, und es wird als ein gemeinsam verwendetes (1100) bezeichnet. In dem Ausführungskontext 1 erhält die Hauptfunktion einen Hinweis bzw. eine Referenz auf das Objekt in dem Ausführungskontext 2 (1110). Die Hauptfunktion in dem Ausführungskontext 1 ruft dann eine Aktion mit dem Kontext 2 als gemeinsam verwendet bezeichnetes Objekt auf (1120).
Bezüglich der Identifizierung oder Kennzeichnung eines erzeugten Objekts als gemeinsam verwendbar, wie es bezüglich des Gegenstandes 1100 in 11 diskutiert wurde, kann dies gemäß einer speziellen Ausführungsform der Erfindung geschehen, indem ein Attribut "gemeinsam verwendbar" in den Kopfdaten der Darstellung eines Objekts aufgenommen wird. Information in den Kopfdaten eines Objektes sind für Programme nicht zugänglich, die in der objektorientierten Sprache geschrieben sind, sondern sind nur für die VM selbst verfügbar.
Das Erhalten eines Hinweises bzw. einer Referenz auf ein Objekt in einem anderen Kontext ist ein besonderer Fall des Zugriffs auf ein Objekt in einem anderen Kontext. Ein Mechanismus, welcher Zugriff auf ein Objekt in einem anderen Kontext gewährt, kann auch andere Objekte verfügbar machen. Beispielsweise kann das Aufrufen einer Methode auf einem Objekt in einem anderen Kontext einen Hinweis auf ein zweites Objekt in einem wiederum anderen Kontext liefern. Ein zusätzlicher Mechanismus ist erforderlich, damit eine anfängliche Referenz auf ein Objekt in einem anderen Kontext erhalten werden kann. In einer speziellen Ausführungsform können Referenzen auf gewisse wohlbekannte Zugangspunktobjekte unter Verwendung einer öffentlichen API erhalten werden. Wenn die anfängliche Referenz auf ein Objekt in einem anderen Kontext erhalten wird, kann man weitere Referenzen von diesem Objekt erhalten usw.
Gemäß der Erfindung gibt es vier allgemeine Ansätze zum Erhalten von Information über eine Kontextbarriere hinweg. Diese Ansätze können individuell oder in Kombination miteinander verwendet werden, um auf ein Objekt über eine Kontextbarriere hinweg zuzugreifen oder um eine Referenz auf ein Objekt zu erhalten, auf welches über eine Kontextbarriere (1110) zugegriffen werden soll. Diese Ansätze werden in den 12 bis 18 beschrieben.
12 ist ein Blockdiagramm, welches die Verwendung von Zugangspunktobjekten darstellt, um Zugang über eine Kontextbarriere hinweg zu gewähren. Wie in 12 dargestellt, möchte irgendein Objekt 1200 in dem Kontext 770 (Kontext 1) Zugriff auf Information in dem Superkontext 760 haben. In der speziellen Ausführungsform enthält ein Superkontext 760 zumindest ein Zugangspunktobjekt 1210. Das Zugangspunktobjekt 1210 kann als Teil einer öffentlichen API veröffentlicht werden oder kann indirekt durch eine veröffentlichte API verfügbar gemacht werden (beispielsweise gemäß den zuvor unter Bezug auf 11 beschriebenen Mechanismen), so daß jeder Kontext, welcher dem Superkontext untergeordnet ist, mit dem Zugangspunktobjekt des Superkontextes kommunizieren kann. (Es versteht sich, daß in anderen Ausführungsformen Zugangspunktobjekte in einem Kontext enthalten sein können, der nicht der Superkontext ist.)
13 ist ein Blockdiagramm, welches die Verwendung von globalen Datenstrukturen für die Gewährung von Zugriff über eine Firewall hinweg zeigt. Bei diesem Ansatz erzeugt der Superkontext 760 eine globale Datenstruktur, wie z. B. ein globales Array. In der speziellen Ausführungsform ist der Superkontext 760 der einzige Kontext, der eine solche globale Datenstruktur erzeugen darf. (Es versteht sich, daß in anderen Ausführungsformen globale Daten in einem anderen Kontext enthalten sein können als in dem Superkontext.) Aufgrund ihres globalen Status kann jeder der Kontexte 770 und 780 die globale Datenstruktur lesen und in diese schreiben. Demnach kann Information, die durch einen Kontext in die globale Datenstruktur geschrieben wird, durch den anderen Kontext gelesen werden. Beispielsweise kann dieser Mechanismus verwendet werden, um binäre Daten oder Referenzen auf Objekte zwischen den Kontexten zu übertragen.
14 ist ein Blockdiagramm, welches die Verwendung von Superkontextprivilegien zeigt, um Zugriff über eine Kontextbarriere hinweg zu gewähren. In 14 möchte ein Objekt in dem Superkontext 716 Zugriff auf den Kontext 780 über die Kontextbarriere hinweg erhalten, welcher die beiden trennt. Der Superkontext 760 kann irgendeine der Methoden des Kontextes 780 aufrufen und kann auf irgendwelche der innerhalb des Kontextes 780 enthaltenen Daten zugreifen aufgrund der Privilegien, die dem Superkontext zugeordnet sind.
15 ist ein Blockdiagramm, welches die Verwendung von gemeinsam verwendbaren Schnittstellenobjekten zeigt, um Zugriff über eine Firewall hinweg zu gewähren. Eine gemeinsam verwendbare Schnittstelle definiert einen Satz von gemeinsam verwendbaren Schnittstellenmethoden. Ein gemeinsam verwendbares Schnittstellenobjekt ist ein Objekt, welches zumindest den Satz von Methoden implementiert, die in der gemeinsam verwendbaren Schnittstelle definiert sind. In 15 ist das Objekt 1210 in Kontext 2 (780) ein gemeinsam verwendbares Schnittstellenobjekt. Ein Objektzugriff 1200 in einem anderen Kontext 770 kann irgendeines der gemeinsam verwendbaren Schnittstellenverfahren auf dem Objekt 1210 aufrufen, wenn die Hauptfunktion des Objektzugriffs 1200 autorisiert ist, dies über das Objekt 1210 selbst zu tun. Diese Autorisierung wird unten unter Bezug auf 18 noch genauer diskutiert.
Es versteht sich, daß eine virtuelle Maschine, die mit der Erfindung konsistent ist, eine Funktionalität über die früheren virtuellen Maschinen, wie z. B. die in der Java^TM Virtual Machine Specification beschriebene virtuelle Maschine, hinaus bereitstellt. Insbesondere stellt die virtuelle Maschine, konsistent mit der vorliegenden Erfindung, eine Funktionalität für das Implementieren oder Ermöglichen eines Sicherheitserzwingungsvorganges bereit, welcher den Zugriff über eine Firewall hinweg erlaubt. Dieser Prozeß wird als nächstes unter Bezug auf die 16 bis 18 beschrieben. Man beachte, daß dies auf irgendeinen Ansatz anwendbar ist, um Zugriff über eine Firewall hinweg zu gewähren, einschließlich der vier unter Bezug auf die oben beschriebenen 12 bis 15 beschriebenen Ansätze, ohne jedoch hierauf beschränkt zu sein.
16 ist ein Flußdiagramm eines Sicherheitserzwingungsvorganges, der einen Zugriff über eine Firewall hinweg erlaubt. Wenn eine Hauptfunktion versucht, eine Aktion auf einem Objekt 1600 aufzurufen, so wird eine Überprüfung vorgenommen, um festzustellen, ob das Objekt innerhalb des Kontextes der Hauptfunktion (1610) liegt. Wenn dies der Fall ist (1610-Y), so wird die Aktion zugelassen (1630). Falls nicht (1610-N), so wird eine Überprüfung vorgenommen, um festzustellen, ob die Aktion durch die Hauptfunktion auf dem Objekt (1620) zugelassen ist. Wenn dies der Fall ist (1620-Y), so wird die Aktion zugelassen (1630). Falls nicht (1620-N), so wird die Aktion nicht zugelassen. In der speziellen Ausführungsform wird eine Sicherheitsausnahme eingeworfen bzw. vorgebracht (1640).
17 ist das Flußdiagramm nach 16, welches weitere Einzelheiten des Blockes 1620 zeigt. Wenn das Objekt nicht in dem Kontext der Hauptfunktion liegt (1610-N), so wird eine Mehrzahl von Tests 1621, 1622, 1623 ... 1629 durchgeführt, um festzustellen, ob die Aktion durch die Hauptfunktion auf dem Objekt zugelassen ist. Diese Tests können durch die virtuelle Maschine allein oder durch die virtuelle Maschine zusammen mit dem Objekt in einer objektorientierten Implementierung der virtuellen Maschine durchgeführt werden. Falls irgendwelche der Tests bestanden werden, so wird die Aktion zugelassen (1630). Wenn jedoch alle Tests zu einer negativen Feststellung führen (162X-NO), so wird die Aktion nicht zugelassen. In einer speziellen Ausführungsform wird eine Sicherheitsausnahme eingeworfen bzw. vorgebracht (1640). Diese Tests beziehen sich auf den zugelassenen Zugriff, der in Verbindung mit den 12 bis 15 erläutert wurde.
18 ist ein Flußdiagramm, welches eine beispielhafte Implementierung des Blockes 1629 aus 17 für die Verwendung mit dem Zugriffsverfahren zeigt, welches zu 15 beschrieben wurde. In einem Test, wie z. B. 829 oder 1629, überprüft eine virtuelle Maschine, ob das Objekt ein gemeinsam verwendetes Objekt 1810 ist. Wenn dies nicht der Fall ist (1810-NO) wird der Test nicht bestanden. Wenn dies jedoch der Fall ist (1810-YES), so ruft die virtuelle Maschine die Methode A auf Objekt O auf (1820). Wenn die Methode A auf dem Objekt O feststellt, daß die Hauptfunktion autorisiert ist (1830), so ist der Test bestanden (1840) und es wird Zugriff gewährt. Anderenfalls wird der Test nicht bestanden (1850). Dies ermöglicht es, daß der Autorisierungstext in den Code des Objektes selbst einprogrammiert wird.
Auch wenn die Erfindung in Bezug auf eine Smart-Card-Implementierung dargestellt worden ist, ist sie in gleicher Weise auf andere Einrichtungen kleinen Maßstabs, nicht nur für Smart Cards, anwendbar. Einrichtungen bzw. Geräte im Kleinformat werden allgemein als diejenigen betrachtet, die hinsichtlich ihres Speichers oder hinsichtlich ihrer Rechnerleistung oder -geschwindigkeit begrenzt oder eingeschränkt sind. Derartige kleinformatige Geräte können Geräte für Umgrenzungsabtastungen, feldprogrammierbare Einrichtungen, Pager und Mobiltelefone sein, die nur einige von vielen weiteren sind. Im allgemeinen sind kleinformatige Geräte hinsichtlich ihrer Ressourcen eingeschränkte Rechnereinrichtungen und Systeme, in welchen ein sicherer Betrieb zwischen Ausführungskontexten ein Problem darstellt. Derartige kleine Geräte legen wegen ihrer begrenzten Ressourcen der Implementierung von Sicherheitsmaßnahmen Einschränkungen auf. Wegen der Ressourceneinschränkungen muß in einer Implementierung einer virtuellen Maschine eine einzelne virtuelle oder physikalische Maschine verwendet werden, im Gegensatz zu einer Vielzahl virtueller Maschinen.
Die Erfindung kann auch auf Geräte mit größeren Formaten angewendet werden, in welchen die Eigenschaften der Erfindung sich als vorteilhaft erweisen können. Beispielsweise kann sich die Erfindung auch als vorteilhaft erweisen, wenn man Servlets verwendet, wenn es zwischen diesen eine gemeinsame Objektverwendung gibt. Selbst einige Desktop-Systeme können die Techniken der Erfindung in Nutzen bringender Weise verwenden.
Während die Java^TM-Sprache und -Plattform für die Erfindung geeignet sind, wäre jede beliebige Sprache oder Plattform, die gewisse Eigenschaften hat, ebensogut für die Implementierung der Erfindung geeignet. Diese charakteristischen Merkmale umfassen die Typsicherheit, die Zeigersicherheit, Objektorientierung, dynamische Verknüpfung und die Basis der virtuellen Maschine. Nicht alle diese Eigenschaften müssen in einer bestimmten Anwendung vorhanden sein. In einigen Ausführungsformen können Sprachen oder Plattformen verwendet werden, die eine oder mehrere dieser Eigenschaften nicht haben. Eine "virtuelle Maschine" könnte entweder in Bits (virtuelle Maschine) oder in Form von Silicium (reale/physikalische Maschine) implementiert sein.
Auch wenn die Erfindung unter Darstellung der objektweisen Sicherheit veranschaulicht worden ist, könnten andere Ansätze, wie z. B. klassenweise Sicherheit, verwendet werden.
Auch wenn die vorliegende Erfindung im einzelnen beschrieben und dargestellt worden ist, versteht es sich, daß dies nur der Veranschaulichung und beispielhaften Darstellung dient und nicht als eine Einschränkung verstanden werden soll, wobei der Gedanke und Schutzumfang der vorliegenden Erfindung nur anhand der anhängenden Ansprüche und Äquivalente beschränkt ist.
ANHANG
6. Applet-Isolierung und gemeinsame Objektverwendung
Jede Implementierung des JCRE soll die Isolation von Kontexten und Applets unterstützen. Isolation bedeutet, daß ein Applet nicht auf die Felder oder Objekte eines Applets in einem anderen Kontext zugreifen kann, es sei denn, das andere Applet stellt ausdrücklich eine Schnittstelle für den Zugriff bereit. Die JCRE-Mechanismen für die Applet-Isolierung und die gemeinsame Verwendung von Objekten werden in den folgenden Abschnitten im einzelnen beschrieben.
6.1 Applet-Firewall
Die Applet-Firewall in der Java-Kartentechnologie ist ein während der Laufzeit erzwungener Schutz und ist unabhängig von den Schutzmaßnahmen der Java-Technologie. Die Schutzmaßnahmen der Java-Sprache gelten nach wie vor für Java-Karten-Applets. Die Java-Sprache stellt sicher, daß starke Typisierungs- und Schutzeigenschaften in Kraft sind.
Applet-Firewalls sind in der Java Card VM immer in Kraft. Sie erlauben es, daß die VM au- tomatisch während der Laufzeit zusätzliche Sicherheitsüberprüfungen vornimmt.
6.1.1 Kontexte und Kontextumschaltung
Firewalls teilen im wesentlichen das Objektsystem der Java-Card-Plattform in getrennt geschützte Objekträume, welche Kontexte genannt werden. Die Firewall ist die Grenze zwischen einem Kontext und einem anderen. Die JCRE soll einen Applet-Kontext für jedes Applet, welches auf der Karte installiert ist, zuweisen und verwalten. (Siehe jedoch Absatz 6.1.1.2 unten bezüglich einer Diskussion von Gruppenkontexten.)
Zusätzlich behält die JCRE ihren eigenen JCRE-Kontext bei. Dieser Kontext ist einem Applet-Kontext weitgehend ähnlich, hat jedoch spezielle Systemprivilegien, so daß er Operationen ausführen kann, die für Applet-Kontexte abgelehnt werden.
Zu irgendeinem beliebigen Zeitpunkt gibt es nur einen Kontext innerhalb der VM (dieser wird der aktuell aktive Kontext genannt). Alle Bytecodes, die auf Objekte zugreifen, werden wäh- rend der Laufzeit gegenüber dem aktuell aktiven Kontext verglichen, um festzustellen, ob der Zugriff erlaubt ist. Eine java.lang.SecurityException wird eingeworfen bzw. vorgebracht, wenn ein Zugriff nicht zugelassen wird.
Wenn gewisse wohldefinierte Bedingungen während der Ausführung von Bytecodes vom Typ eines Aufrufes, wie sie in Abschnitt 6.2.8 beschrieben werden, erfüllt sind, führt die VM eine Kontextumschaltung durch. Der vorherige Kontext wird auf einen internen VM-Stack geschoben, ein neuer Kontext wird der aktuell aktive Kontext und die aufgerufene Methode läuft in diesem neuen Kontext ab. Beim Beenden der Methode führt die VM eine wiederherstellende Kontextumschaltung aus. Der ursprüngliche Kontext (des die Methode aufrufenden) wird von dem Stack wiederaufgenommen und wird als der aktuell aktive Kontext wiederhergestellt. Kontextumschaltungen können verschachtelt sein. Die maximale Tiefe hängt von der Menge an verfügbarem VM-Stack-Speicherraum ab.
Die meisten Methodenaufrufe in der Java-Kartentechnologie bewirken keine Kontextumschaltung. Kontextumschaltungen treten nur beim Aufruf von und bei der Rückkehr aus gewissen Methoden auf, ebenso wie während Exit-Ausnahmen aus diesen Methoden (siehe 6.2.8).
Während eines Methodenaufrufs mit Kontextumschaltung wird ein zusätzlicher Teil von Da- ten, welche den aktuell aktiven Kontext anzeigen, auf den Rückkehrstapel bzw. -stack verschoben. Dieser Kontext wird wiederhergestellt, wenn die Methode beendet wird.
Weitere Einzelheiten von Kontexten und Kontextumschaltung werden in späteren Abschnitten dieses Kapitels dargelegt.
6.1.1.1 Gruppenkontexte
Üblicherweise definiert jede Instanz eines Java-Card-Applets einen separaten Kontext. Mit der Java-Card-2.1-Technologie wird jedoch das Konzept des Gruppenkontexts eingeführt. Wenn mehr als ein Applet in einem einzelnen Java-Paket enthalten ist, so verwenden sie gemeinsam denselben Kontext. Zusätzlich verwenden alle Instanzen derselben Applet-Klasse gemeinsam denselben Kontext. Mit anderen Worten, es gibt keine Firewall zwischen zwei Applet-Instanzen in einem Gruppenkontext.
Die Diskussion von Kontexten und Kontextumschaltung oben in Abschnitt 6.11 geht von der Annahme aus, daß jeder Applet-Instanz ein getrennter Kontext zugeordnet ist. In der Java-Card-2.1-Technologie werden Kontexte verglichen, um die Firewall in Kraft zu setzen, und die Instanz AID wird auf den Stack verschoben. Zusätzlich geschieht dies nicht nur, wenn der Kontext umgeschaltet wird, sondern auch, wenn die Steuerung von einem Objekt, welches im Besitz einer Applet-Instanz ist, zu einem Objekt umschaltet, welches im Besitz einer anderen Instanz innerhalb desselben Paketes ist.
6.1.2 Objektbesitz
Wenn ein neues Objekt erzeugt wird, wird ihm der aktuell aktive Kontext zugewiesen. Das Objekt befindet sich jedoch im Besitz der Applet-Instanz innerhalb des aktuell aktiven Kontextes, wenn das Objekt instantüert wird. Ein Objekt ist im Besitz einer Applet-Instanz oder der JCRE.
6.1.3 Objektzugriff
Im allgemeinen kann auf ein Objekt nur durch den Kontext zugegriffen werden, der es besitzt, d. h. wenn der besitzende Kontext der aktuell aktive Kontext ist. Die Firewall verhindert, daß auf ein Objekt von einem anderen Applet in einem anderen Kontext zugegriffen wird.
Im Hinblick auf die Implementierung wird jedesmal dann, wenn auf ein Objekt zugegriffen wird, der Besitzerkontext des Objektes mit dem aktuell aktiven Kontext verglichen. Wenn diese nicht übereinstimmen, wird der Zugriff nicht durchgeführt und es wird eine Security Exception vorgebracht.
Auf ein Objekt wird zugegriffen, wenn einer der folgenden Bytecodes unter Venerendung der Referenz bzw. Bezugnahme auf das Objekt ausgeführt wird:
getfield, putfield, invokevirtual, invokeinterface, athrow, <T>aload, <T>astore, arraylength, checkcast, instanceof
<T> bezieht sich auf die verschiedenen Typen von Arraybytecodes, wie z. B. baload, sastore usw.
Diese Liste umfaßt jegliche speziellen oder optimierten Formen dieser Bytecodes, die in der Java Card VM implementiert sind, wie z. B. getfield_b, sgetfield_s_this etc.
6.1.4 Firewallschutz
Die Java-Card-Firewall stellt einen Schutz gegen den vermutlich häufigsten Sicherheitsfall bereit: Entwicklungsfehler und das Übersehen von Fehlern in der Auslegung, die es möglicherweise erlauben, daß empfindliche Daten zu einem anderen Applet hin "durchsickern". Ein Applet kann in der Lage sein, eine Objektreferenz von einer öffentlich zugänglichen Stelle zu erhalten, wenn jedoch das Objekt im Besitz eines anderen Applets ist, so stellt die Firewall eine Sicherheit bereit.
Die Firewall bietet auch Schutz gegen inkorrekten Code. Wenn inkorrekter Code auf eine Karte geladen wird, schützt die Firewall nach wie vor Objekte dagegen, daß durch diesen Code auf sie zugegriffen wird.
Die Java Card API 2.1 spezifiziert die grundlegenden, minimalen Schutzerfordernisse von Kontexten und Firewalls, da diese Merkmale in einer Weise unterstützt werden sollten, die für den Entwickler des Applets nicht transparent ist. Entwickler sollten sich des Verhaltens von Objekten, APIs und Ausnahmen, die sich auf die Firewall beziehen, bewußt sein.
JCRE-Implementierer sind darin frei, zusätzliche Sicherheitsmechanismen über diejenigen der Applet-Firewall hinaus zu implementieren, solange diese Mechanismen für Applets transparent sind und nicht den extern sichtbaren Betrieb der VM verändern.
6.1.5 Statische Felder und Methoden
Es versteht sich außerdem, daß Klassen nicht im Besitz von Kontexten sind. Es gibt keine Kontextüberprüfung während der Laufzeit, die ausgeführt werden kann, wenn auf das statische Feld einer Klasse zugegriffen wird. Es gibt auch keine Kontextumschaltung, wenn eine statische Methode aufgerufen wird. (In ähnlicher Weise verursacht invokespecial keine Kontextumschaltung.)
Öffentliche statische Felder und öffentliche statische Methoden sind von jedem Kontext aus zugänglich: Statische Methoden laufen in demselben Kontext ab wie derjenige, der sie aufruft.
Objekte, auf die in statischen Feldern verwiesen wird, sind einfach leere Objekte. Sie sind im Besitz dessen, der sie erzeugt hat und es gelten die standardmäßigen Regeln des Firewallzugriffs. Es ist notwendig, daß sie über mehrere Applet-Kontexte hinweg gemeinsam verwendet werden, denn diese Objekte müssen gemeinsam verwendbare Schnittstellenobjekte (SIOs) sein. (Siehe Paragraph 64 unten.)
Selbstverständlich sind die konventionellen Schutzmechanismen der Java-Technologie für statische Felder und Methoden weiterhin in Kraft. Zusätzlich verifiziert der Installierer, wenn Applets installiert werden, daß jeder Versuch, ein externes statisches Feld oder Verfahren anzuschließen, zugelassen wird. Die Installation und Einzelheiten der Verknüpfung liegen außerhalb des Bereiches dieser Beschreibung.
6.1.5.1 Optionale statische Zugriffsüberprüfungen
Die JCRE kann optionale Überprüfungen während der Laufzeit ausführen, die mit den Beschränkungen, welche durch einen Verifizierer durchgesetzt werden, redundant sind. Eine Java Card VM kann erfassen, wenn Code grundlegende Beschränkungen der Sprache verletzt, wie z. B. Aufrufen einer privaten Methode in einer anderen Klasse und Bericht über oder sonstige Ansprache der Verletzung
6.2 Objektzugriff über Kontexte hinweg
Um es Applets zu ermöglichen, daß sie miteinander und mit der JCRE in Wechselwirkung treten, stehen einige wohldefinierte und dennoch sichere Mechanismen bereit, so daß ein Kontext auf ein Objekt zugreifen kann, welches zu einem anderen Kontext gehört.
Diese Mechanismen werden in der Java Card API 2.1 bereitgestellt und werden in den folgenden Abschnitten diskutiert:

– JCRE-Zugangspunktobjekte
– globale Arrays
– JCRE-Privilegien
– gemeinsam verwendbare Schnittstellen

6.2.1 JCRE-Zugangspunktobjekte
Sichere Computersysteme sollten eine Möglichkeit für nicht-privilegierte Benutzervorgänge haben (die auf einen Teilsatz der Ressourcen beschränkt sind), um Systemdienste anzufordern, welche durch privilegierte "System"-Abläufe bzw. -Routinen ausgeführt werden.
In der Java Card API 2.1 wird dies erreicht unter Verwendung der JCRE-Zugangspunktobjekte. Dies sind Objekte, die im Besitz des JCRE-Kontextes sind, sie sind jedoch mit Flags als solche gekennzeichnet, die Zugangspunktmethoden enthalten.
In der Java Card API 2.1 wird dies erreicht durch Verwendung von JCRE-Zugangspunktobjekten. Dies sind Objekte, die im Besitz des JCRE-Kontextes sind, jedoch sind sie mit Flags als solche markiert worden, die Zugangspunktmethoden enthalten.
Die Firewall schützt diese Objekte gegen Zugriff durch Applets. Die Zugangspunktkennung ermöglicht es den Verfahren dieser Objekte, daß sie von irgendeinem Kontext aufgerufen werden. Wenn dies geschieht, wird eine Kontextumschaltung zu dem JCRE-Kontext durchgeführt. Diese Methoden sind die Tore, durch welche Applets privilegierte JCRE-Systemdienste anfordern.
Es gibt zwei Kategorien von JCRE-Zugangspunktobjekten:

– Zeitweilige JCRE-Zugangspunktobjekte Wie alle JCRE-Zugangspunktobjekte können Methoden zeitweiliger JCRE-Zugangspunktobjekte von irgendeinem beliebigen Applet-Kontext aus aufgerufen werden. Hinweise bzw. Referenzen auf diese Objekte können jedoch nicht in Klassenvariablen, Instanzvariablen oder Arraykomponenten gespeichert werden. Die JCRE erfaßt und beschränkt Versuche, Referenzen auf diese Objekte zu speichern, als Teil der Firewall-Funktionalität, eine nicht-autorisierte erneute Verwendung zu verhindern. Das APDU-Objekt und alle im Besitz der JCRE befindlichen Ausnahmeobjekte sind Beispiele zeitweiliger JCRE-Zugangspunktobjekte.
– Dauerhafte JCRE-Zugangspunktobjekte Wie alle JCRE-Zugangspunktobjekte können Methoden dauerhafter JCRE-Zugangspunktobjekte von irgendeinem beliebigen Applet-Kontext aus aufgerufen werden. Zusätzlich können Referenzen bzw. Hinweise auf diese Objekte gespeichert und frei wiederverwendet werden. Im JCRE-Besitz befindliche AID-Instanzen sind Beispiele dauerhafter JCRE-Zugangspunktobjekte.

Die JCRE ist verantwortlich für:

– Bestimmen, welche privilegierten Dienste für Applets bereitgestellt werden.
– Definieren von Klassen, die die Zugangspunktmethoden für diese Dienste enthalten.
– Erzeugen einer oder mehrerer Objektinstanzen dieser Klassen.
– Bezeichnen dieser Instanzen als JCRE-Zugangspunktobjekte.
– Bezeichnen der JCRE-Zugangspunktobjekte als zeitweilig oder dauerhaft.
– Hinweise geben auf diejenigen Objekte, die für Applets verfügbar sind, soweit erforderlich.

Zur Beachtung – Nur die Methoden dieser Objekte sind durch die Firewall zugänglich. Die Felder dieser Objekte sind nach wie vor durch die Firewall geschützt und auf diese kann nur von dem JCRE-Kontext aus zugegriffen werden.
Nur die JCRE selbst kann Zugangspunktobjekte kennzeichnen und angeben, ob sie zeitwei- lig (temporär) oder dauerhaft (permanent) sind. JCRE-Implementierer sind verantwortlich für die Implementierung des Mechanismus, durch welchen JCRE-Zugangspunktobjekte bezeichnet werden und auf welche Weise sie temporär oder permanent werden.
6.2.2 Globale Arrays
Die globale Natur einiger Objekte erfordert, daß auf sie von irgendeinem Applet-Kontext aus zugegriffen werden kann. Die Firewall würde normalerweise verhindern, daß diese Objekte in flexibler Weise verwendet werden. Die Java Card VM ermöglicht, daß ein Objekt als global bezeichnet wird.
Alle globalen Arrays sind zeitweilig globale Arrayobjekte. Diese Objekte befinden sich in dem Besitz des JCRE-Kontextes, auf sie kann jedoch von irgendeinem beliebigen Applet-Kontext aus zugegriffen werden. Referenzen zu bzw. Hinweise auf diese Objekte können jedoch nicht in Klassenvariablen, Instanzvariablen oder Arraykomponenten gespeichert werden. Die JCRE erfaßt und beschränkt Versuche, Referenzen und Bezugnahmen auf diese Objekte als Teil der Firewall-Funktionalität, um eine nicht-autorisierte erneute Verwendung zu verhindern.
Für zusätzliche Sicherheit können nur Arrays als global bezeichnet werden und nur die JCRE selbst kann globale Arrays auszeichnen. Da Applets diese nicht erzeugen können, sind keine API-Methoden definiert. JCRE-Implementierer sind verantwortlich für das Implementieren des Mechanismus, durch welchen globale Arrays gekennzeichnet bzw. als solche ausgezeichnet werden.
Zum Zeitpunkt der Veröffentlichung dieser Beschreibung sind die einzigen globalen Arrays, die in der Java Card API 2.1 erforderlich sind, der APDU-Puffer und der Bytearray-Eingabeparameter (bArray) für die Installierungsmethode des Applets.
Zur Beachtung – Wegen ihres globalen Status spezifiziert die API, daß der APDU-Puffer auf Nullen gelöscht wird, wann immer ein Applet ausgewählt wird, bevor die JCRE einen neuen APDU-Befehl annimmt. Dies dient dazu, die potentiell empfindlichen Daten eines Applets davor zu schützen, daß sie über den globalen APDU-Puffer an ein anderes Applet "durchsickern". Auf den APDU-Puffer kann von dem Kontext eines gemeinsam verwendeten Schnittstellenobjektes aus zugegriffen werden und er ist geeignet, Daten über Applet-Kontexte hinweg zu leiten. Das Applet ist verantwortlich für das Schützen geheimer Daten, auf welche von dem APDU-Puffer aus zugegriffen werden kann.
6.2.3 JCRE-Privilegien
Da der JCRE-Kontext der "System"-Kontext ist, hat er ein besonderes Privileg. Er kann eine Methode irgendeines Objektes auf der Karte aufrufen. Es sei beispielsweise angenommen, daß das Objekt im Besitz des Applets A ist. Normalerweise kann nur der Kontext A auf die Felder und Methoden von X zugreifen. Jedoch darf der JCRE-Kontext irgendeine der Methoden von X aufrufen. Während eines solchen Aufrufs erfolgt eine Kontextumschaltung von dem JCRE-Kontext zu dem Applet-Kontext, welcher X besitzt.
Zur Beachtung – Die JCRE kann sowohl auf Methoden als auch auf Felder von X zugreifen. Ein Methodenzugriff ist der Mechanismus, durch welchen die JCRE Zugang zu einem Ap plet-Kontext erhält. Auch wenn die JCRE jede beliebige Methode durch die Firewall aufrufen könnte, so sollte sie dennoch nur die Methoden select, process, deselect und getShareableInterfaceObject (siehe 6.2.7.1) aufrufen, die in der Applet-Klasse definiert sind.
Der JCRE-Kontext ist der aktuell aktive Kontext, wenn die VM nach einer Rückstellung (nach einem Reset) der Karte zu laufen beginnt. Der JCRE-Kontext ist der "Wurzel"- bzw. Basiskontext und ist entweder immer der aktuell aktive Kontext oder der untere Kontext, der im Stackspeicher aufbewahrt wird.
6.2.4 Gemeinsam verwendbare Schnittstellen
Gemeinsam verwendbare Schnittstellen sind ein neues Merkmal in der Java Card API 2.1, um eine Wechselwirkung zwischen Applets zu ermöglichen. Eine gemeinsam verwendbare Schnittstelle definiert einen Satz von gemeinsam verwendeten Schnittstellenverfahren. Diese Schnittstellenverfahren können von einem Applet-Kontext aus aufgerufen werden, selbst wenn das Objekt, welches sie implementiert, im Besitz eines anderen Applet-Kontextes ist.
In dieser Beschreibung wird eine Objektinstanz einer Klasse, welche eine gemeinsam verwendbare Schnittstelle implementiert, ein gemeinsam verwendbares Schnittstellenobjekt (SIO) genannt.
Für den besitzenden Kontext ist das SIO ein normales Objekt, auf dessen Felder und Methoden zugegriffen werden kann. Für irgendeinen anderen Kontext ist die SIO eine Instanz der gemeinsam verwendbaren Schnittstelle und nur die Methoden, die in der gemeinsam verwendbaren Schnittstelle definiert sind, sind zugänglich. Alle anderen Felder und Methoden der SIO sind durch die Firewall geschützt.
Gemeinsam verwendbare Schnittstellen stellen in folgender Weise einen Sicherheitsmechanismus für die Kommunikation zwischen Applets bereit:

1. Um ein Objekt für ein anderes Applet verfügbar zu machen, definiert Applet A zunächst eine gemeinsam verwendbare Schnittstelle SI. Eine gemeinsam verwendbare Schnittstelle erweitert das Interface javacard.framework.Shareable. Die Methoden, die in der gemeinsam verwendbaren Schnittstelle SI definiert sind, repräsentieren die Dienste, welche das Applet A für andere Applets vertügbar macht.
2. Dann definiert Applet A eine Klasse C, welche die gemeinsam verwendbare Schnittstelle SI implementiert. C implementiert die Methoden, die in SI definiert sind. C kann auch weitere Methoden und Felder definieren, jedoch sind diese durch die Applet-Firewall geschützt. Nur die in SI definierten Methoden sind für andere Applets verfügbar.
3. Applet A erzeugt eine Objektinstanz O der Klasse C. O gehört zu Applet A und die Firewall erlaubt A, auf irgendeines der Felder und Methoden von O zuzugreifen.
4. Um auf das Objekt O des Applets A zuzugreifen, erzeugt Applet B einen Objekthinweis bzw. eine Objektreferenz SIO des Typs SI.
5. Applet B ruft eine Spezialmethode auf (JCSystem.getAppletShareable Interfaceobject, wie es in Paragraph 6,2.7.2 beschrieben wird), um eine Referenz auf ein gemeinsam verwendetes Schnittstellenobjekt vom Applet A anzufordern.
6. Applet A empfängt die Anforderung und die AID des Anfordernden (B) über Applet.getShareableInterfaceObject und bestimmt, ob es das Objekt O mit dem Applet B gemeinsam verwendet.
7. Wenn Applet A der gemeinsamen Verwendung mit Applet B zustimmt, antwortet A auf die Anforderung mit einem Hinweis bzw. einer Referenz auf O. Diese Referenz wird in die Form des Typs gemeinsam verwendbar gebracht, so daß keines der Felder oder Methoden von O sichtbar ist.
B. Applet B empfängt die Objektreferenz von Applet A, bringt sie in die Form des Typs SI und speichert sie in der Objektreferenz SIO. Obwohl SIO tatsächlich auf das Objekt O von A hinweist, ist SIO von dem Typ SI. Nur die gemeinsam verwendbaren Schnittstellenmethoden, die in SI definiert sind, sind für B sichtbar. Die Firewall verhindert, daß auf die anderen Felder und Methoden von 0 von B zugegriffen wird.
9. Applet B kann einen Dienst von Applet A anfordern, indem es eine der gemeinsam verwendbaren Schnittstellenmethoden von SIO aufruft. Während des Aufrufs führt die Java Card VM eine Kontextumschaltung durch. Der ursprüngliche aktuell aktive Kontext (B) wird auf einem Stackspeicher aufbewahrt und der Kontext des Besitzers (A) des aktuellen Objekts (O) wird der neue aktive Kontext. Die Implementierung der gemeinsam verwendbaren Interfacemethode (SI-Methode) von A läuft in dem Kontext von A ab.
10. Die SI-Methode kann die AID ihres Client (B) über die Methode JCSystem.getPreviousContextAID herausfinden. Dies wird in Paragraph 6.2.5 beschrieben. Die Methode legt fest, ob sie den Dienst für das Applet B ausführt oder nicht.
11. Wegen der Kontextumschaltung erlaubt die Firewall der SI-Methode, auf alle die Felder und Methoden des Objekts O und irgendeines anderen im Besitz von A befindlichen Objektes zuzugreifen. Gleichzeitig verhindert die Firewall, daß die Methode auf im Besitz von B befindliche, nicht gemeinsam verwendete Objekte zugreift.
12. Die SI-Methode kann auf die Parameter zugreifen, welche durch B weitergeleitet werden und sie kann einen Rückkehr- bzw. Antwortwert an B liefern.
13. Während der Rückgabe führt die Java Card VM eine Wiederherstellung der Kontextumstellung durch. Der ursprünglich aktuell aktive Kontext (B) tritt aus dem Stackspeicher hervor und wird wieder der aktuelle Kontext.
14. Wegen der Kontextumschaltung erlaubt die Firewall B erneut, auf irgendeines seines Objekte zuzugreifen, und verhindert, daß B auf nicht gemeinsam verwendete, im Besitz von A befindliche Objekte zugreift.

6.2.5 Bestimmen des vorherigen Kontextes
Wenn ein Applet Jcsystem.getPreviousContextAID aufruft, so sollte der JCRE die Instanz AID der Applet-Instanz liefern, welche zum Zeitpunkt der letzten Kontextumschaltung aktiv war.
6.2.5.1 Der JCRE-Kontext
Der JCRE-Kontext hat keine AID. Wenn ein Applet die Methode getPrevious ContextAID aufruft, nachdem der Applet-Kontext direkt aus dem JCRE-Kontext eingegeben wurde, so liefert diese Methode das Ergebnis Null.
Wenn das Applet getPreviouscontextAID von einer Methode aufruft, von welcher entweder aus dem Applet selbst zugegriffen werden kann, oder wenn von einem externen Applet über eine gemeinsam verwendbare Schnittstelle darauf zugegriffen wird, so sollte es prüfen, daß eine Null geliefert wird, bevor eine AID-Authentisierung des Anrufers ausgeführt wird.
6.2.6 Einzelheiten der gemeinsam verwendbaren Schnittstelle
Eine gemeinsam verwendbare Schnittstelle ist einfach eine, die (entweder direkt oder indirekt) das markierende Interface javacard.framework.Shareable erweitert. Diese gemeinsam verwendbare Schnittstelle ist hinsichtlich ihres Konzeptes der ferngelegenen Schnittstelle ähnlich, die durch die RMI-Einrichtung verwendet wird, in welcher Anrufe an die Interface-Methoden über die Grenzen von lokal nach fern hinweg stattfinden.
6.2.6.1 Die gemeinsam verwendbare Java-Card-Schnittstelle
Schnittstellen, welche die gemeinsam verwendbare markierende Schnittstelle erweitern, haben diese spezielle Eigenschaft: Anrufe an Schnittstellenmethoden finden durch eine Kontextumschaltung über die Firewall-Grenze des Java-Card-Applets hinweg statt.
Die gemeinsam verwendbare Schnittstelle dient dazu, alle gemeinsam verwendeten Objekte zu identifizieren. Jedes Objekt, welches über die Applet-Firewall gemeinsam verwendet werden muß, soll diese Schnittstelle direkt oder indirekt implementieren. Nur diejenigen Methoden, die in einer gemeinsam verwendbaren Schnittstelle spezifiziert werden, sind durch die Firewall hindurch verfügbar.
Implementierungsklassen können irgendeine Anzahl gemeinsam verwendbarer Schnittstellen implementieren und sie können sich auf andere gemeinsam verwendbare Implementierungsklassen erstrecken.
Wie jede Java-Plattform-Schnittstelle definiert eine gemeinsam verwendbare Schnittstelle einfach einen Satz von Dienstmethoden. Eine Dienst- bzw. Service-Provider-Klasse erklärt, daß sie "die gemeinsam verwendbare Schnittstelle implementiert und Implementierungen für jede der Dienstmethoden auf der Schnittstelle bereitstellt". Eine Dienst-Client-Klasse greift auf die Dienste zu, indem sie eine Objektreferenz erhält, diese in einen gemeinsam ver wendbaren Schnittstellentyp umformt, falls erforderlich, und die Servicemethoden der Schnittstellen aufruft.
Die gemeinsam verwendbaren Schnittstellen in der Java-Card-Technologie haben die folgenden Eigenschaften:

– Wenn eine Methode in einer gemeinsam verwendbaren Schnittstelle aufgerufen wird, so erfolgt eine Kontextumschaltung zu dem Kontext des Besitzers des Objektes.
– Wenn das Verfahren beendet wird (Exit), wird der Kontext des Anrufers wiederhergestellt.
– Eine Ausnahmehandhabung wird verbessert, so daß der aktuell aktive Kontext in korrekter Weise wiederhergestellt wird während der Abwicklung des Stapelrahmens (stack frame), was erfolgt, wenn eine Ausnahme vorgebracht wird.

6.2.7 Erhalten von gemeinsam verwendbaren Schnittstellenobjekten
Die Kommunikation zwischen Applets wird gewährleistet, wenn ein Client-Applet eine gemeinsam verwendbare Schnittstellenmethode eines SIO aufruft, welcher zu einem Server-Applet gehört. Damit dies funktioniert, muß es für das Client-Applet eine Möglichkeit geben, die SIO von dem Server-Applet an erster Stelle zu erhalten. Der JCRE stellt einen Mechanismus bereit, um dieses möglich zu machen. Die Applet-Klasse und die JCSystem-Klasse stellen Verfahren bereit, um eine Anforderung von Diensten von dem Server zu ermöglichen.
6.2.7.1 Die Methode Applet.getShareableInterfaceObject
Diese Methode wird implementiert durch die Server-Applet-Instanz. Sie soll von der JCRE aufgerufen werden, um zwischen einem Client-Applet, welches die Verwendung eines Objektes anfordert, das zu einem andern Applet gehört, und dem Server-Applet zu vermitteln, welches seine Objekte für die gemeinsame Verwendung verfügbar macht.
Das Standardverhalten sollte eine Null zurückliefern, was anzeigt, daß ein Applet nicht an der Kommunikation zwischen Applets teilnimmt.
Ein Server-Applet, welches von irgendeinem anderen Applet aufgerufen werden soll, muß diese Methode außer Kraft setzen. Diese Methode sollte die ClientAID und die Parameter untersuchen. Wenn der ClientAID nicht eine der erwarteten AIDs ist, so sollte die Methode auf Null zurückkehren. In ähnlicher Weise sollte die Methode, wenn der Parameter nicht erkannt wird oder wenn er nicht für ClientAID zugelassen wird, das Verfahren ebenfalls eine Null liefern. Ansonsten sollte das Applet eine SIO des gemeinsam verwendbaren Schnittstellentyps liefern, welchen der Client angefordert. hat.
Das Server-Applet muß nicht auf alle Clients mit derselben SIO reagieren. Der Server kann mehrere Typen von gemeinsam verwendbaren Schnittstellen für unterschiedliche Zwecke und kann ClientAID und Parameter verwenden, um zu bestimmen, welche Art von SIO an den Client zurückzuliefern ist.
6.2.7.2 Die Methode JCSystem.getAppletShareableInterfaceObject
Die JCSystem-Klasse enthält die Methode getAppletshareableInterfaceObject, welche durch ein Client-Applet aufgerufen wird, um mit dem Server-Applet zu kommunizieren.
Die JCRE soll diese Methode so implementieren, daß sie sich folgendermaßen verhält:

1. Die JCRE durchsucht ihre interne Applet-Tabelle nach einer mit ServerAID. Falls sie eine solche nicht findet, so wird eine Null vorgebracht.
2. Die JCRE ruft die Methode getShareableInterfaceObject dieses Applets auf und leitet die ClientAID des Anrufers und des Parameters.
3. Eine Kontextumschaltung erfolgt mit dem Server-Applet und seine Implementierung von getshareableInterfaceObject läuft weiter, wie es in den vorherigen Abschnitten beschrieben wurde. Das Server-Applet liefert ein SIO zurück (oder Null).
4. getAppletshareableInterfaceObject liefert dieselbe SIO oder Null an ihren Anrufer.

Für eine verbesserte Sicherheit sollte die Implementierung es unmöglich machen, daß der Client sagt bzw. feststellt, welche der folgenden Bedingungen einen Null-Wert geliefert hat bzw. haben, der zurückgegeben werden soll:

– Die ServerAID wurde nicht gefunden.
– Das Server-Applet nimmt an der Kommunikation zwischen Applets nicht teil.
– Das Server-Applet erkennt nicht den ClientAID oder den Parameter.
– Das Server-Applet kommuniziert nicht mit diesem Client.
– Das Server-Applet kommuniziert nicht mit diesem Client, wie er durch die Parameter spezifiziert ist.

6.2.8 Klassen- und Objektzugriffsverhalten
Ein statisches Klassenfeld erfährt einen Zugriff, wenn einer der folgenden Java-Bytecodes ausgeführt wird:
getstatic, putstatic
Auf ein Objekt wird zugegriffen, wenn einer der folgenden Java-Bytecodes unter Verwendung der Referenz des Objektes bzw. des Hinweises auf das Objekt zugegriffen wird:
getfield, putfield, invokevirtual, invokeinterface, athrow, <T>aload, <T>store, arraylength, checkcast, instanceof
<T> bezieht sich auf die verschiedenen Typen von Arraybytecodes, wie z. B. baload, sastore etc.
Diese Liste umfaßt auch jegliche speziellen oder optimierten Formen dieser Bytecodes, die in der Java Card VM implementiert sein können, wie z. B. getfield_b, sgetfield_s_ this, etc.
Vor dem Durchführen der Arbeit des Bytecodes, wie es durch die Java VM spezifiziert wird, führt die Java Card VM eine Zugangsüberprüfung mit dem referenzierten Objekt (Objekt, auf welches hingewiesen wurde) durch. Wenn der Zugriff verweigert wird, so wird eine SecurityException (Ausnahme der Sicherheit) vorgebracht.
Die Zugangsüberprüfungen, die durch die Java Card VM durchgeführt werden, hängen vom Typ und vom Besitzer der referenzierten Objekte, dem Bytecode und dem aktuell aktiven Kontext ab. Sie werden in den folgenden Abschnitten beschrieben.
6.2.8.1 Zugreifen auf statische Klassenfelder
Bytecodes:
getstatic, putstatic

– Wenn die JCRE der aktuell aktive Kontext ist, so wird der Zugriff erlaubt.
– Ansonsten wird, wenn der Bytecode putstatic ist und das gespeicherte Feld vom Referenztyp ist und die Referenz, die gespeichert wird, eine Referenz auf ein temporäres JCRE-Zugangspunktobjekt oder ein globales Array ist, der Zugriff verweigert.
– Ansonsten wird der Zugriff erlaubt.

6.2.8.2 Zugreifen auf Array-Objekte
Bytecodes:
<T>aload, <T>astore, arraylength, checkcast, instanceof

– Wenn die JCRE der aktuell aktive Kontext ist, so wird der Zugriff erlaubt.
– Ansonsten wird, wenn der Bytecode aastore ist und die Komponente, welche gespeichert wird, vom Referenztyp ist und die gespeicherte Referenz eine Referenz auf ein temporäres JCRE-Zugangspunktobjekt oder ein globales Array ist, der Zugriff verweigert.
– Ansonsten wird, wenn sich das Array im Besitz des aktuell aktiven Kontextes befindet, der Zugriff erlaubt.
– Ansonsten wird, wenn das Array als global bezeichnet ist, der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.3 Zugreifen auf Klasseninstanzobjektfelder
Bytecodes:
getfield, putfield

– Wenn die JCRE der aktuell aktive Kontext ist, so wird der Zugriff erlaubt.
– Ansonsten wird, wenn der Bytecode putfield ist und das Feld, welches gespeichert wird, vom Referenztyp ist und die gespeicherte Referenz eine Referenz auf ein temporäres JCRE-Zugangspunktobjekt oder ein globales Array ist, der Zugriff verweigert.
– Ansonsten wird, wenn das Objekt im Besitz des aktuell aktiven Kontextes ist, der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.4 Zugreifen auf Klasseninstanzobjektmethoden
Bytecodes:
invokevirtual

– Wenn das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff gewährt. Der Kontext wird in den Kontext des Objektbesitzers umgeschaltet.
– Ansonsten wird, wenn das Objekt als ein JCRE-Zugangspunktobjekt ausgezeichnet ist, der Zugriff erlaubt. Der Kontext wird in den Kontext des Objektbesitzers umgeschaltet (sollte JCRE sein).
– Ansonsten wird, wenn JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt. Der Kontext wird in den Kontext des Objektbesitzers umgeschaltet.
– Ansonsten wird der Zugriff verweigert.

6.2.8.5 Zugreifen auf Standard-Interfacemethoden
Bytecodes:
invokeinterface

– Falls das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, falls der JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt, der Kontext wird in den Kontext des Objektbesitzers umgeschaltet.
– Ansonsten wird der Zugriff verweigert.

6.2.8.6 Zugreifen auf gemeinsam verwendbare Schnittstellenmethoden
Bytecodes:
invokeinterface

– Falls das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, falls die Klasse des Objektes eine gemeinsam verwendbare Schnittstelle implementiert und falls die aufgerufene Schnittstelle die gemeinsam verwendbare Schnittstelle erweitert, der Zugriff erlaubt. Der Kontext wird in den Kontext des Objektbesitzers umgeschaltet.
– Ansonsten wird, falls JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt. Der Kontext wird in den Kontext des Objektbesitzers umgeschaltet.
– Ansonsten wird der Zugriff verweigert.

6.2.8.7 Einwerten von Ausnahmeobjekten
Bytecodes:
athrow

– Wenn das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, wenn das Objekt als ein JCRE-Zugangspunktobjekt ausgezeichnet ist, der Zugriff erlaubt.
– Ansonsten wird, falls die JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.8 Zugreifen auf Klasseninstanzobjekte
Bytecodes:
checkcast, instanceof

– Falls das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, falls JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt.
– Ansonsten wird, falls das Objekt als ein JCRE-Zugangspunktobjekt ausgezeichnet ist, der Zugriff erlaubt.
– Ansonsten wird, falls JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt, ansonsten wird der Zugriff verweigert.

6.2.8.9 Zugreifen auf Standardschnittstellen
Bytecodes:
checkcast, instanceof

– Falls das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, falls JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.10 Zugreifen auf gemeinsam verwendbare Schnittstellen
Bytecodes:
checkcast, instanceof

– Wenn das Objekt im Besitz des aktuell aktiven Kontextes ist, so wird der Zugriff erlaubt.
– Ansonsten wird, falls die Klasse des Objekts eine gemeinsam verwendbare Schnittstelle implementiert und falls das Objekt in die Form einer Schnittstelle gebracht (checkcast) oder eine Instanz einer Schnittstelle ist (instanceof), die die gemeinsam verwendbare Schnittstelle erweitert, der Zugriff erlaubt.
– Ansonsten wird, falls JCRE der aktuell aktive Kontext ist, der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.3 Transiente Objekte und Applet-Kontexte
Transiente Objekte (Übergangsobjekte) des Typs CLEAR_ON_RESET (Löschen beim Zurücksetzen) verhalten sich wie dauerhafte Objekte insofern, als auf sie nur dann zugegriffen werden kann, wenn der aktuell aktive Applet-Kontext derselbe ist wie der Besitzer des Objektes (der aktuell aktive Applet-Kontext zu dem Zeitpunkt, als das Objekt erzeugt wurde).
Transiente Objekte des Typs CLEAR_ON_DESELECT (Löschen beim Aussortieren) können nur erzeugt werden und sind nur dann zugänglich, wenn der aktuell aktive Applet-Kontext der aktuell ausgewählte Applet-Kontext ist. Wenn irgendeine der transient machenden Fabrikmethoden aufgerufen wird, um ein transientes Objekt vom CLEAR_ON_DESELECT-Typ zu erzeugen, wenn der aktuell aktive Applet-Kontext nicht der aktuell ausgewählte Applet-Kontext ist, so soll die Methode eine systemexception mit dem Begründungscode von ILLEGAL_TRANSIENT vorbringen. Wenn ein Versuch unternommen wird, auf ein transientes Objekt des Typs CLEAR_ON_DESELECT zuzugreifen, wenn der aktuell aktive Applet-Kontext nicht der aktuell ausgewählte Applet-Kontext ist, so soll die JCRE eine Security Exception vorbringen.
Applets, die Teil desselben Paketes sind, verwenden denselben Gruppenkontext gemeinsam. Jede Applet-Instanz aus einem Paket verwendet all ihre Objektinstanzen mit allen anderen Instanzen aus demselben Paket gemeinsam. (Dies umfaßt transiente Objekte sowohl des Typs CLEAR_ON_RESET als auch des Typs CLEAR_ON_DESELECT, die im Besitz dieser Applet-Instanzen sind.)
Die transienten Objekte des Typs CLEAR_ON_DESELECT, die im Besitz irgendeiner Applet-Instanz innerhalb desselben Paketes sind, sollen zugänglich sein, wenn irgendeine der Applet-Instanzen in diesem Paket das aktuell ausgewählte Applet ist.
Glossar
AID ist ein Akronym für Application Identifier (Anwendungskennung), wie in ISO 7816-5 definiert.
APDU ist ein Akronym für Application Protocol Data Unit (Anwendungsprotokolldateneinheit) wie in ISO 7816-4 definiert.
API ist ein Akronym für Application Programming Interface (Anwendungsprogrammierschnittstelle). Die API definiert das Aufrufen von Konventionen, durch welche ein Anwendungsprogramm auf das Betriebssystem und andere Dienste zugreift.
Applet bedeutet im Kontext des vorliegenden Dokumentes ein Java-Card-Applet (kleine Anwendung einer Java-Karte), welche die Grundeinheit der Auswahl, des Kontextes, der Funktionalität und der Sicherheit in der Java-Kartentechnologie ist.
Applet Developer (Applet-Entwickler) bezieht sich auf Person, die unter Verwendung von Spezifikationen der Java-Card-Technology ein Java-Card-Applet erzeugt.
Applet-Firewall ist der Mechanismus in der Java-Kartentechnologie, durch welche die VM verhindert, daß ein Applet einen nicht-autorisierten Zugriff auf Objekte unternimmt, die im Besitz anderer Applet-Kontexte oder des JCRE-Kontextes sind, und über die Verletzung berichtet oder ansonsten die Verletzung anspricht.
CAD ist ein Akronym für Card Acceptance Device (Kartenannahmegerät). Das CAD ist das Gerät, in welches die Karte eingesetzt wird.
Cast (in eine Form bringen) ist die explizite Umwandlung von einem Datentyp in einen anderen.
Class (Klasse) ist der Prototyp für ein Objekt in einer objektorientierten Sprache. Eine Klasse kann auch als ein Satz von Objekten betrachtet werden, die eine gemeinsame Struktur und ein Verhalten gemeinsam zeigen. Die Struktur einer Klasse wird bestimmt durch die Klassenvariablen, welche den Zustand eines Objektes dieser Klasse repräsentieren und das Verhalten ist gegeben durch einen Satz von Methoden, welche zu der Klasse gehören.
Klassen sind in eine Klassenhierarchie eingeordnet. Eine Klasse kann eine Spezialisierung (eine Unterklasse) einer anderen (ihrer Oberklasse) sein, sie kann eine Referenz bzw. einen Hinweis auf andere Klassen haben und sie kann andere Klassen in einer Client-Server-Beziehung verwenden.
Kontext (siehe Applet-Ausführungskontext).
Currently active context (aktuell aktiver Kontext). Die JCRE verfolgt den aktuell aktiven Java-Karten-Applet-Kontext. Wenn eine virtuelle Methode auf einem Objekt aufgerufen wird und eine Kontextumschaltung erforderlich ist und zugelassen wird, so wird der aktuell aktive Kontext so geändert, daß er dem Applet-Kontext entspricht, der das Objekt besitzt. Wenn die Methode zurückkehrt bzw. beendet wird, so wird der vorherige Kontext wiederhergestellt. Aufrufe statischer Methoden haben keinen Einfluß auf den aktuell aktiven Kontext. Der aktuell aktive Kontext und der Zustand der gemeinsamen Verwendung eines Objektes bestimmen gemeinsam, ob ein Zugriff auf ein Objekt zulässig ist.
Currently selected applet (aktuell ausgewähltes Applet). Die JCRE verfolgt das aktuell ausgewählte Java-Card-Applet. Nach Erhalt eines Auswahlbefehls mit dieser AID des Applets macht die JCRE dieses Applet zu dem aktuell ausgewählten Applet. Die JCRE sendet alle APDU-Befehle an das aktuell ausgewählte Applet.
Firewall (siehe Applet-Firewall).
Framework (Rahmen) ist der Satz von Klassen, welche die API implementieren. Dies umfaßt Kernund Erweiterungspakete. Verantwortlichkeiten umfassen das Verarbeiten von APDUs, die Appletauswahl, das Verwalten von Unteilbarkeit und das Installieren von Applets.
Instanzvariablen, auch als Felder bekannt, repräsentieren einen Teil des internen Zustandes eines Objektes. Jedes Objekt hat seinen eigenen Satz von Instanzvariablen. Objekte derselben Klassen haben dieselben Instanzvariablen, jedoch kann jedes Objekt unterschiedliche Werte haben.
Instantiation (Instantiierung) bedeutet in der objektorientierten Programmierung das Erzeugen eines bestimmten Objektes aus seiner Klassenschablone. Dies beinhaltet die Zuordnung einer Datenstruktur mit den durch die Schablone spezifizierten Typen und die Initialisierung von Instanzvariablen entweder mit Standardwerten oder mit denjenigen, die durch die Aufbaufunktion der Klasse bereitgestellt werden.
Java Card Runtime Environment (JCRE – Java-Kartenumgebung während der Laufzeit) besteht aus der virtuellen Java-Kartenmaschine, dem Rahmen und den zugehörigen inhärenten (natürlichen) Methoden.
JC21RI ist ein Akronym für die Referenzimplementierung der Java Card 2.1.
JCRE implementer (JCRE-Implementierer) bezieht sich auf eine Person, die eine für einen Verkäufer spezifische Implementierung unter Verwendung der Java Card API erzeugt.
JCVM ist ein Akronym für Java Card Virtual Machine bzw. virtuelle Java-Kartenmaschine. Die JCVM ist die Grundlage der OP-Card-Architektur. Die JCVM führt Bytecode aus und verwaltet Klassen und Objekte. Sie setzt die Trennung zwischen Anwendungen (Firewalls) in Kraft und ermöglicht eine sichere gemeinsame Verwendung von Daten.
JDK ist ein Akronym für Java Development Kit (Java-Entwicklungsausrüstung). Die JDK ist ein Produkt von Sun Microsystems, Inc., welches die Umgebung bereitstellt, die für das Programmieren in Java erforderlich ist. Die JDK ist für eine Vielfalt von Plattformen verfügbar, wobei vor allem auf Sun Solaris und Microsoft Windows^® hinzuweisen ist.
Methode ist der Name, den man einem Vorgang oder einer Routine (Programm oder Unterprogramm) gibt, verknüpft mit einer oder mehreren Klassen, und zwar in der objektorientierten Sprache.
Namespace (Namensraum) ist ein Satz von Namen, in welchem alle Namen einzigartig bzw. eindeutig sind.
Objektorientiert ist eine Programmiertechnik, die auf dem Konzept eines Objektes beruht, das eine Datenstruktur ist, die in einen Satz von Routinen bzw. Programmen eingehüllt ist, welche Methoden genannt werden, die auf bzw. mit den Daten arbeiten.
Objekte sind in der objektorientierten Programmierung einzigartige bzw. eindeutige Instanzen einer Datenstruktur, die gemäß der Schablone definiert werden, welche durch ihre Klasse bereitgestellt wird. Jedes Objekt hat seine eigenen Werte für die Variablen, die zu seiner Klasse gehören, und kann auf die Nachrichten (Methoden) reagieren, welche durch seine Klasse definiert sind.
Package (Paket) ist ein Namensraum innerhalb der Java-Programmiersprache und kann Klassen und Schnittstellen haben. Ein Package bzw. Paket ist die kleinste Einheit innerhalb der Java-Programmiersprache.
Shareable interface (gemeinsam verwendbare Schnittstelle) definiert einen Satz von gemeinsam verwendbaren Schnittstellenmethoden. Diese Schnittstellenmethoden können von einem Applet-Kontext aufgerufen werden, wenn das Objekt, welches sie implementiert, im Besitz eines anderen Applet-Kontextes ist.
Shareable intertace object (gemeinsam verwendbares Interfaceobjekt – SIO): Ein Objekt, welches die gemeinsam verwendbare Schnittstelle implementiert.

Claims

Verfahren zum Betreiben einer kleinformatigen Einrichtung (400), welche eine Verarbeitungsmaschine (410) enthält, wobei Programmodule auf der Verarbeitungsmaschine ausgeführt werden können, gekennzeichnet durch: Ausführen von Gruppen eines oder mehrerer Programmodule in getrennten Kontexten (420, 620; 760, 770, 780; 1000, 1010, 1020), wobei Objekte eines Programmoduls einem bestimmten Kontext zugeordnet sind bzw. werden, und Bereitstellen einer Kontextabgrenzung bzw. -barriere (600; 600'), um die Kontexte abzutrennen und zu isolieren, und um den objektorientierten Zugriff eines Programmoduls zu kontrollieren, der in einem Kontext abläuft, und zwar gegenüber der Information und/oder einem Programmodul, welches in einem anderen Kontext abläuft, wobei das Kontrollieren bzw. Steuern weiterhin aufweist, daß der Zugriff verhindert wird, wenn der Zugriff nicht autorisiert ist, und der Zugriff ermöglicht wird, wenn der Zugriff autorisiert ist.
Verfahren nach Anspruch 1, wobei die Autorisierung des Zugriffs zumindest eine Sicherheitsüberprüfung umfaßt.
Verfahren nach Anspruch 1 oder 2, wobei das Verfahren weiterhin das Zuordnen entsprechender getrennter Namensräume bzw. -spaces für jeden Kontext aufweist.
Verfahren nach den Ansprüchen 1 oder 2, wobei das Verfahren weiterhin das Zuordnen entsprechender getrennter Speicherräume für jeden Kontext aufweist.
Verfahren nach einem der vorstehenden Ansprüche 1 bis 4, wobei die Verarbeitungsmaschine (410) eine virtuelle Maschine (720) aufweist, die auf einem Prozessor (300) abläuft.
Computerprogrammprodukt, welches ein Programm aus Anweisungen verkörpert, um eine kleinformatige Einrichtung (400) nach einem der Verfahrensansprüche 1 bis 5 zu betreiben.
Kleinformatige Einrichtung bzw. kleinformatiges Gerät (400), welches eine Verarbeitungsmaschine (410) umfaßt, wobei Programmodule auf der Verarbeitungsmaschine ausgeführt werden, gekennzeichnet durch Einrichtungen zum Ausführen von Gruppen eines oder mehrerer Programmodule in getrennten Kontexten (420, 620; 760, 770, 780; 1000, 1010, 1020), wobei Objekte eines Programmoduls einem bestimmten Kontext zugeordnet sind, und mit einer Kontextbarriere (600; 600') um die Kontexte abzutrennen und zu isolieren, und zum Kontrollieren des objektorientierten Zugriffs durch ein Programmodul, welches in einem Kontext abläuft, auf Information in einem ande ren Kontext und/oder auf ein in einem anderen Kontext ablaufendes Programmodul, wobei die Kontextbarriere weiterhin dafür ausgelegt ist, den Zugriff zu verhindern, wenn der Zugriff nicht autorisiert ist, und den Zugriff freizugeben, wenn der Zugriff autorisiert ist.
Kleinformatiges Gerät nach Anspruch 7, wobei die Autorisierung des Zugriffs zumindest eine Sicherheitsprüfung umfaßt.
Kleinformatiges Gerät nach Anspruch 7 oder 8, wobei das Gerät weiterhin Einrichtungen zum Zuordnen jeweils getrennter Namensräume für jeden Kontext aufweist.
Kleinformatiges Gerät nach Anspruch 7 oder 8, wobei das Gerät weiterhin Einrichtungen zum Zuordnen jeweils getrennter Speicherräume fürjeden Kontext aufweist.
Kleinformatiges Gerät nach einem der vorstehenden Ansprüche 7 bis 10, wobei die Verarbeitungsmaschine (410) eine virtuelle Maschine (720) aufweist, die auf einem Prozessor (300) läuft.
Verwendung eines Netzwerkes zum Übermitteln von Code von einem Server über eine Kommunikationsverbindung, wobei der Code Anweisungen zum Betreiben eines kleinformatigen Gerätes (400) gemäß einem der Verfahrensansprüche 1 bis 5 aufweist.