DE60002687T2

DE60002687T2 - Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von laufzeitumgebungsprivilegien

Info

Publication number: DE60002687T2
Application number: DE60002687T
Authority: DE
Inventors: Joshua Susser; B. Mitchel BUTLER; Andy Streich
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-01-22
Filing date: 2000-01-20
Publication date: 2004-03-25
Anticipated expiration: 2020-01-21
Also published as: JP5132853B2; WO2000043878A1; JP2013030175A; ATE240549T1; AU771765B2; US6922835B1; DE1163579T1; EP1163579A1; CN1351728A; CN1316360C; KR20010101622A; JP2002535772A; JP5483768B2; DE60002687D1; EP1163579B1; AU2617600A; KR100716699B1

Description

Dieser Patentantrag ist mit den Europäischen Patentanträgen EP 1155365 , EP 1155366, EP 1190316 und EP 1151378 verwandt.
HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die Erfindung betrifft das Gebiet der Computersicherheit, und insbesondere Techniken zur Implementierung von Sicherheit auf Geräten mit kleinem Platzbedarf, wie beispielsweise Smartcards.
Stand der Technik
Verschiedene objektorientierte Programmiersprachen sind in der Fachwelt gut bekannt. Beispiele dafür sind die Sprachen C++ und Smalltalk. Eine weitere solche objektorientierte Programmsprache ist die Sprache JAVA^TM. Diese Sprache wird in dem Buch JAVA^TM Language Specification von James Gosling et al., veröffentlicht von Addison-Wesley, beschrieben. Die Sprache JAVA^TM ist besonders gut für die Ausführung auf einer Java^TM Virtuellen Maschine geeignet. Eine solche Maschine ist in dem Buch Java^TM Virtual Machine Specification von Tim Lindholm und Frank Yellin beschrieben, ebenfalls veröffentlicht von Addison-Wesley.
In der Fachwelt sind unterschiedliche Geräte mit kleinem Platzbedarf bekannt. Dazu gehören Smartcards, Zelltelefone und verschiedene andere Klein- oder Miniaturgeräte.
Smartcards gleichen in Größe und Form den Kreditkarten, enthalten aber in der Regel in der Karte Datenverarbeitungsfähigkeiten (z. B. einen Prozessor oder logische Verarbeitungsfunktionen) und eine Gruppe von Kontakten, über die Programme, Daten und andere Kommunikationsereignisse mit der Smartcard vewirklicht werden können. Zu den Kontakten gehören typischerweise ein Stromanschluss sowie ein Rücksprung- und ein Takteingang, ein Rücksetzeingang und ein Datenanschluss, über den Datenkommunikation erreicht werden kann.
Informationen können mit einem Kartenannahmegerät auf eine Smartcard geschrieben und von einer Smartcard abgerufen werden. Ein Kartenannahmegerät ist: in der Regel ein peripheres, mit einem Host-Computer verbundenes Gerät, das einen Kartenanschluss, etwa einen Slot, besitzt, in den die Smartcard eingeführt werden kann. Nach der Einführung drücken die Kontakte oder Bürsten einer Steckerverbindung gegen den Oberflächenanschlussbereich auf der Smartcard, um Strom zu liefern und die Kommunikation mit dem Prozessor und Speicher zu ermöglichen, die typischerweise auf einer Smartcard vorhanden sind.
Smartcards und Kartenannahmegeräte (Card Acceptance Devices – CADs) sind Gegenstand umfassender Standardisierungsbemühungen, z. B. ISO 7816.
Die Verwendung von Firewalls zur Trennung autorisierter von nicht autorisierten Benutzern ist im Netzwerk-Bereich gut bekannt.
Für Geräte mit keinem Platzbedarf, wie beispielsweise Smartcards, wurde eine Teilgruppe der vollständigen Java^TM Plattformfunktionen definiert. Diese Teilgruppe wird als Java Card^TM Plattform bezeichnet. Die Einsatzmöglichkeiten der Java Card^TM Plattform werden in folgenden Veröffentlichungen beschrieben:
JAVA CARD^TM 2.0 – LANGUAGE SUBSET UND VIRTUAL MACHINE SPECIFICATION;
JAVA CARD^TM 2.1 – APPLICATION PROGRAMMING INTERFACES;
JAVA CARD^TM 2.0 – PROGRAMMING CONCEPTS;
JAVA CARD^TM APPLET DEVELOPERS GUIDE.
Das Konzept eines Ausführungskontexts ist in der Informatik gut bekannt. Allgemein gesagt, bietet die Anwendung mehrerer Ausführungskontexte in einem Computerumfeld eine Möglichkeit zur Trennung oder Isolierung unterschiedlicher Programmmodule oder Prozesse voneinander, so dass jedes und jeder ohne unerwünschte Interferenz von anderen arbeiten kann. Interaktionen zwischen unterschiedlichen Kontexten sind – wenn überhaupt – nicht zufällig, sondern freiwillig und sorgfältig geregelt, um die Integrität der einzelnen Kontexte nicht zu stören. Ein Beispiel für multiple Kontexte ist in größeren Hardwaregeräten zu sehen, etwa in Mainframes, wo eine Mehrzahl von virtuellen Maschinen definiert werden kann, wobei jede dieser virtuellen Maschinen ihren eigenen Ausführungskontext besitzt. Ein weiteres Beispiel ist in US-Patent Nr. 5,802,519 an den Erfinder De Jong zu sehen, wo die Verwendung multipler Ausführungskontexte auf einer Smartcard beschrieben wird. Fachleute erkennen, dass eine Computerumgebung, die multiple Ausführungskontexte bereitstellt, auch einen Mechanismus schaffen muss, mit dem jeder bestimmte Ausführungcode seinem entsprechenden Kontext zugeordnet wird.
Ebenfalls gut bekannt ist das Konzept eines aktuellen Kontexts. Bestimmte Computerumgebungen, die multiple Kontexte unterstützen, behandeln zu jedem Zeitpunkt einen Kontext im besonderen als aktiven Computerfokus. Der Kontext kann als "aktueller Kontext" bezeichnet. werden. Wenn sich der aktuelle Kontext ändert, so dass ein anderer Kontext zum aktuellen Kontext wird, findet ein sogenannter "Kontextwechsel" statt. Wie Fachpersonen bekannt, schaffen diese Computerumgebungen Mechanismen zur Bestimmung des jeweils aktuellen Kontexts und zur Ermöglichung der Kontextwechsel.
In der älteren Technik der Geräte mit kleinem Platzbedarf, insbesondere in der Welt der Smartcards, fand kein Zusammenwirken zwischen den in den Geräten mit kleinem Platzbedarf aktiven Kontexten statt. Jeder Kontext agierte völlig getrennt und konnte in seinem Kontextraum funktionieren oder fehlfunktionieren, ohne andere Anwendungen oder Prozesse in einem anderen Kontext zu beeinträchtigen.
Eine Schicht des von der Java^TM Plattform benützten Sicherheitsschutzes wird allgemein als Sandkastenmodell bezeichnet. Zweifelhafter Code wird in einem "Sandkasten" abgelegt, wo er sicher "spielen" kann, ohne in der "echten Welt" bzw. der vollwertigen Java^TM-Umgebung Schaden anzurichten. In einer solchen Umgebung findet keine Kommunikation zwischen den Java^TM-Applets statt, doch verfügt jedes über seine eigene Namensstelle. Ein solches Sandkastenmodell ist bekannt aus WO 98/19237.
Einige Smartcard-Betriebssysteme erlauben die direkte Kommunikation von Ausführungskontexten nicht, wohl aber die Kommunikation über ein Betriebssystem oder einen Server. Der Artikel von L. Gong et al. "Going Beyond the Sandbox: An Overview of the new Security Architecture in the Java^TM Development Kit 1.2", veröffentlicht unter der Nummer XP-002100907 in den PROCEEDINGS OF THE USENIX SYMPOSIUM ON INTERNET TECHNOLOGIES UND SYSTEMS, offenbart eine neue Sicherheitsarchitektur für eine feinabgestimmte Zugriffkontrolle, die Sicherheitsprüfungen erleichtert. Er offenbart Sicherheitsprinzipien für eine Code-basierte Programmstruktur. Die Sicherheitsprinzipien sind eine Abbildung einer Gruppe von Eigenschaften, die einen Ablaufcode charakterisieren, auf eine Gruppe von Zugriffgenehmigungen, die dem betreffenden Code gewährt werden.
Die Probleme
Eine Reihe von Problemen ergeben sich bei dem Versuch, Computerprogramme und andere Informationen in einem Gerät mit kleinem Platzbedarf unterzubringen. Eines der drängendsten Probleme ist der sehr beschränkte Speicherplatz. Dies erfordert oftmals außergewöhnliche Anstrengungen, um die benötigten Funktionen auf dem vorhandenen Speicherplatz unterzubringen.
Ein zweites Problem im Zusammenhang mit Geräten mit kleinem Platzbedarf ist die Tatsache, dass unterschiedliche Hersteller von Geräten mit kleinem Platzbedarf unterschiedliche Betriebssysteme verwenden können. Folglich sind Anwendungen, die für ein Betriebssystem entwickelt wurden, nicht unbedingt auf Geräte mit kleinem Platzbedarf übertragbar, die von einem anderen Hersteller produziert wurden.
Wenn Programme als mehr als einer Programmquelle (Hersteller oder Anbieter) auf einem einzigen Gerät mit kleinem Platzbedarf anzuwenden sind, wird die Sicherheit zu einem Faktor, insofern als versucht wird, die Korruption bestehender Programme und Daten zu verhindern, wenn auf das Gerät mit kleinem Plat bedarf ein neues Programm geladen wird. Dieselbe Sorge besteht, wenn man versucht, einen Hacker oder eine böswillige Person am Zugang zu Programmen und Daten zu hindern.
Es ist klar, das Geräte mit kleinem Platzbedarf, wie Smartcards, nicht über die nötigen Ressourcen verfügen, um getrennte virtuelle Maschinen zu implementieren. Dennoch ist es wünschenswert, zwischen getrennten Ausführungskontexten eine strikte Sicherheit einzuhalten.
In der Vergangenheit wurde Sicherheit damit gewährleistet, dass nur Anwendungen aus der selben Quelle oder aus einer bekannten und vertrauenswürdigen Quelle auf eine Smartcard oder ein anderes Gerät mit kleinem Platzbedarf geladen wurden.
Es wäre demnach wünschenswert, eine objektorientierte Interaktion zwischen ausgewählten Ausführungskontexten auf ausschließlich sichere Weise über schnelle, effiziente Peer-to-Peer-Kommunikationen zu ermöglichen, die dem Programmierer keine ungebührlichen Belastungen auferlegen, sondern das dynamische Laden von Applets erleichtern, die zu verschiedenen Zeitpunkten von nicht-zuverlässigen Quellen geschrieben wurden.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung betrifft die Bereitstellung einer (gelegentlich als "Firewall" bezeichneten) Kontextsperre zur Trennung und Isolierung eines Kontexts von einem anderen und zur Bereitstellung eines kontrollierten Zugriffs über die Sperre hinweg, wenn dies erforderlich ist.
Gemäß der Erfindung können zwei Ausführungskontexte, von denen beispielsweise jeder ein oder mehrere Applets enthält, die in der selben logischen (d. h. virtuellen oder realen) Maschine laufen und voreinander geschützt sind, Informationen auf kontrollierte, sicher Art und Weise austauschen, wofür sie Sprachmechanismen verwenden, wie etwa objektorientierte Mechanismen. Die Sicherheit kann beispielsweise nach Objekten gewährleistet. sein. So kann ein Verfahren in einem ersten Ausführungskontext auf selektiver Basis auf ein erstes Objekt A in einem zweiten Ausführungskontext zugreifen, nicht aber auf ein zweites Objekt B im zweiten Ausführungskontext.
Gemäß einem beispielhaften Ausführungsbeispiel schafft eine verbesserte Java^TM Virtuelle Maschine (VM) bestimmte Laufzeitprüfungen versuchter Zugriffe über Ausführungskontexte in der VM hinweg. Die Prüfungen können automatisch durch die VM oder codiert durch den Programmierer mit Unterstützung von der VM durchgeführt werden. Dies kann unter Verwendung von Kommunikationsmechanismen auf Sprachebene erfolgen. Auf diese Weise lässt sich ein Objektzugriff über Ausführungskontexte hinweg auf dieselbe Weise ausdrücken wie andere Objektzugriffe, die die selbe Sprache benützen, vorgenommen werden. Diese Laufzeitprüfungen schaffen eine zweite Dimension von Verteidigung/Sicherheit über jene hinaus, die von der Java^TM-Sprache und Plattform bereits geschaffen wird.
Diese Mechanismen bieten beispielsweise Schutz gegen Sicherheitslöcher infolge von Programmierungsfehlern (wie beispielsweise die Erklärung eines Datums als "öffentlich" (global), obwohl es eigentlich nicht für alle Kontexte zugänglich sein sollte). Sie ermöglichen zudem eine fein abgestimmte Kontrolle von Datenmitteilungen (wie etwa die Selektion von Objekten zur Weitergabe und von Applets als Empfänger von Weitergaben).
Die Erfindung betrifft auch Computerprogrammprodukte und Trägerwellen mit Bezug auf die anderen Aspekte der Erfindung.
Die oben genannten und andere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden besser ersichtlich in der folgenden detaillierten Beschreibung, wenn diese im Zusammenhang mit den begleitenden Zeichnungen gelesen wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und Vorteile der vorliegenden Erfindung gehen aus der nachstehenden Beschreibung hervor:
1 ist eine Illustration eines mit einem Kartenannahmegerät ausgerüsteten Computers und einer Smartcard zur Verwendung mit dem Kartenannahmegerät.
2 ist eine Illustration eines mit einem Kartenannahmegerät ausgerüsteten Computers, der an ein Netzwerk angeschlossen ist.
3 ist eine exemplarische Hardware-Architektur eines Geräts mit kleinem Platzbedarf, wie beispielsweise einer Smartcard, der älteren Technik.
4 stellt Objekte dar, auf die von Principals zugegriffen wird, wie in der älteren Technik erfolgt.
5 ist ein exemplarisches Sicherheitsmodell, das zur Erklärung der unterschiedlicher. Ausführungsbeispiele der Erfindung herangezogen werden kann.
6 ist ein Blockdiagramm, das die Trennung von Ausführungskontexten durch eine Firewall oder Kontextsperre gemäß einem Aspekt der Erfindung darstellt.
7 ist die Wiedergabe einer Software-Architektur, die sich zur Ausführung der Erfindung eignet.
8 ist ein Fließdiagramm eines Sicherheitsumsetzungsprozesses zur Implementierung einer Firewall gemäß einem Aspekt der Erfindung.
9 ist ein Blockdiagramm, das den Objektzugriff über ein Firewall hinweg gemäß einem Aspekt, der Erfindung darstellt.
10 ist ein Blockdiagramm, das einen kaskadierten Objektzugriff über eine Firewall hinweg zeigt.
11 ist ein Fließdiagramm eines Prozesses für die Zulassung eines Zugriffs durch einen Principal in einem Kontext über eine Firewall hinweg in einen anderen Kontext.
12 ist ein Blockdiagramm, das die Verwendung eines Einsprungstellenobjekts für die Zulassung eines Zugriffs über eine Firewall hinweg darstellt.
13 ist ein Blockdiagramm, das die Verwendung einer globalen Datenstruktur darstellt, wie etwa einen Array für den Zugriff über eine Firewall hinweg.
14 ist ein Blockdiagramm, das die Verwendung eines Superkontexts zur Zulassung eines Zugriffs über eine Firewall hinweg darstellt.
15 ist ein Blockdiagramm, das die Verwendung gemeinsam benutzbarer Interface-Objekte für die Zulassung eines Zugriffs über eine Firewall hinweg darstellt.
16 ist ein Fließdiagramm eines Sicherheitsumsetzungsprozesses, der den Zugriff über eine Firewall hinweg zulässt.
17 ist das Fließdiagramm der 16 mit der Darstellung von Details des Blocks 1620.
18 ist ein Fließdiagramm, das eine beispielhafte Implementierung des Blocks 1629 der 17 darstellt.
SCHREIBWEISEN UND BENENNUNGEN
Die nun folgende detaillierte Beschreibung kann nach Programmprozeduren dargelegt werden, die auf einem Computer oder in einem Computer-Netzwerk ausgeführt werden. Anhand dieser Prozedurbeschreibungen und Darstellungen wird von Fachleuten die Substanz ihrer Arbeit am wirksamsten anderen Fachleuten mitgeteilt.
Eine Prozedur ist hier und allgemein definiert als in sich einheitliche Abfolge von Schritten, die zu einem gewünschten Ergebnis führen. Diese Schritte sind jene, die physische Manipulationen von physischen Quantitäten erfordern. Üblicherweise, wenn auch nicht notwendigerweise nehmen diese Quantitäten die Form elektrischer oder magnetischer Signale an, die gespeichert, übertragen, kombiniert, verglichen und auf andere Weise manipuliert werden können. Es erweist sich - vor allem aus Gründen eines gemeinsamen Gebrauchs – verschiedentlich als praktisch, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Nummern oder Ähnliches zu bezeichnen. Es ist jedoch zu beachten, dass alle diese und ähnliche Termini den entsprechenden physischen Quantitäten zugeordnet werden müssen und nur praktische Etiketten sind, die auf diese Quantitäten angewendet werden.
Des weiteren werden die durchgeführten Manipulationen oftmals mit bestimmten Termini bezeichnet, wie Hinzufügen oder Vergleichen, die im allgemeinen mentalen Vorgängen eines menschlichen Handelnden zugeordnet werden. Es ist indessen in keiner der hier beschriebenen Operationen, die einen Teil der vorliegenden Erfindung bilden, eine derartige Fähigkeit eines menschlichen Handelnden erforderlich oder – in den meisten Fällen - auch nur wünschenswert; die Operationen sind Maschinen-Operationen. Nützliche Maschinen zur Ausführung der Operationen der vorliegenden Erfindung umfassen allgemein gebräuchliche Digital-Computer oder andere Computergeräte.
Die vorliegende Erfindung betrifft zudem eine Vorrichtung zur Ausführung dieser Operationen. Diese Vorrichtung kann eigens für den erforderlichen Zweck konstruiert sein oder einen allgemein gebräuchlichen Computer umfassen, der mit Hilfe eines im Computer gespeicherten Computerprogramms selektiv aktiviert oder rekonfiguriert wurde. Die hier dargestellten Verfahren sind nicht an sich auf einen bestimmten Computer oder eine andere Vorrichtung bezogen. Unterschiedliche allgemein gebräuchliche Maschinen mit Programmen gemäß der hier enthaltenen Erkenntnisse können verwendet werden; es kann sich aber auch als praktischer erweisen, weitergehend spezialisiertere Vorrichtungen zu konstruieren, um die gewünschten Verfahrensschritte auszuführen. Die erforderliche Struktur für unterschiedliche dieser Maschinen ergibt sich aus der gegebenen Beschreibung.
DETAILLIERTE BESCHREIBUNG
Dieser Schrift liegt als Anhang ein unveröffentlichter Entwurf von Kapitel 6 eines Dokuments mit dem Titel JAVA CARD RUNTIME ENVIRONMENT 2.1 SPECIFIKATION bei. Dieser Entwurf bietet eine weitere detaillierte Beschreibung spezifischer Ausführungsbeispiele der Erfindung.
Zwar werden die Techniken der Erfindung im folgenden im Kontext eines Smartcard-Beispiels beschrieben, doch hat das Beispiel nur illustrativen Charakter und ist nicht geeignet, den Geltungsbereich der Erfindung einzuschränken.
1 ist eine Illustration eines Computers 120, der mit einem Kartenannahmegerät 110 und einer Smartcard 100 zur Verwendung in dem Kartenannahmegerät 110 ausgerüstet ist. Im Betrieb wird die Smartcard 100 in das Kartenannahmegerät 110 eingeführt, und Strom- und Datenanschlüsse über eine Gruppe von Kontakten 105 hergestellt, die an der Oberfläche der Smartcard 100 zugänglich sind. Wenn die Karte eingeführt wird, verbinden sich die zusammengehörenden Kontakte vom Kartenannahmegerät 110 mit den Oberflächenkontakten 105, um die Karte mit Energie zu versorgen und die Kommunikation mit dem Onboard-Prozessor und die Speicherung zu ermöglichen.
2 ist eine Illustration eines an ein Netzwerk 200 angeschlossenen Computers, der mit einem Kartenannahmegerät, wie 120 in 1, ausgerüstet ist. Ebenfalls an ein Netzwerk angeschlossen ist eine Mehrzahl von anderen Computergeräten, wie der Server 210. Es ist möglich, über das Netzwerk 20C unter Anwendung des Kartengeräts 120 Daten und Software auf eine Smartcard zu laden. Herunterladungen dieser Art können auf eine Smartcard zu ladende Applets oder andere Programme enthalten, sowie auch digitale Cash- und andere Informationen, wie sie in verschiedenen elektronischen Handels- und anderen Anwendungen benützt werden. Die Anweisungen und Daten, die zur Kontrolle von Verarbeitungselementen des Kartenannahmegeräts und der Smartcard dienen, können in einem flüchtigen oder nicht-flüchtigen Speicher abgelegt oder direkt über eine Kommunikationsverbindung empfangen werden, z. B. als Trägerwelle, die die Anweisungen und/oder Daten enthält. Des weiteren kann das Netzwerk beispielsweise ein LAN oder ein WAN sein, wie das Internet oder ein anderes Netz.
3 ist eine exemplarische Hardware-Architektur eines Geräts mit kleinem Platzbedarf, wie etwa einer Smartcard, der älteren Technik. Wie in 3 dargestellt, verbindet sich ein Prozessor 300 mit dem Primärspeicher 310, der den Festspeicher 315 und/oder den Direktzugriffsspeicher 316 enthalten kann. Der Prozessor verbindet sich auch mit einem Sekundärspeicher 320, wie einem EEPROM, und mit einem Eingang/Ausgang 330, die einem seriellen Port. Es ist zu sehen, dass die Geräte mit kleinem Platzbedarf dieser Art sehr einfach sein können.
4 illustriert Objekte, auf die von Principals nach der älteren Technik zugegriffen wird. Wie in 4 dargestellt, kann ein physisches Gerät 400, wie das Gerät mit kleinem Platzbedarf, eine oder mehrere (virtuelle oder physische) Verarbeitungsmaschinen enthalten, die einen Ausführungskontext 420 ablaufen lassen. Der Ausführungskontext kann beispielsweise ein Kontext in Verbindung mit einem bestimmten Applet sein. Ein oder mehrere Principals 430 (z. B. Applets oder Anwendungen) im Ausführungskontext können versuchen, auf andere Objekte im Ausführungskontext zuzugreifen. Solange der Zugriff im Ausführungskontext stattfindet, wird der Zugriff erlaubt, und alles funktioniert normal.
5 ist ein exemplarisches Sicherheitsmodell, das zur Erklärung der unterschiedlichen Ausführungsbeispiele dieser Erfindung dienen kann. Es ist nur eines von vielen Modellen, die zur Anwendung kommen könnten, aber es ist gut geeignet für diesen Zweck. In diesem Modell schickt sich ein Principal 500 (manchmal als Entity bezeichnet) an, eine Aktion 510 an einem Objekt auszuführen, beispielsweise am Objekt 520. Der Principal, das Objekt und/oder die intendierte Aktion können Sicherheitsprüfungen unterzogen werden.
In 5 sind zwei Arten von Objekten dargestellt, an denen ein Principal Aktionen vornehmen kann. Dazu gehören Datenobjekte (z. B. Datal und Data2 (520, 520')) und die Entity 530. Ein Principal kann eines dieser Objekte betreiben oder zu betreiben versuchen.
Während die Daten passiv sind, ist eine Entity 530 aktiv. Die Diagrammlinie vom Principal zu einer aktiven Entity wird auch als "Aktion" bezeichnet, doch könnte es sich um eine anspruchsvollere und absichtlich komplexere Aktion handeln, wie beispielsweise ein Funktions- oder methodenaufruf oder das Versenden einer Mitteilung, verglichen mit einer Aktion an, einem Datenobjekt. Wie bei den Daten, kann eine vom Betriebssystem durchgeführte Sicherheitsprüfung die Identität des Principals, die Identität der Entity und/oder den Typ der Aktion benützen. Des weiteren kann die – aktive – Entity ihre eigenen zusätzlichen Sicherheitsprüfungen durchführen. Diese können so absichtlich komplex sein wie gewünscht und sieh der Identität des Principals, der Identität der Entity selbst, der Aktion und/oder aller anderen verfügbaren Informationen bedienen.
In einem objektorientierten System (wie der Java Card^TM Plattform) sind "Objekte" in der Regel eine Kombination von Daten und Entity. Wenn ein Principal versucht, auf ein Feld eines Objekts zuzugreifen, ist dies ein Datenzugriff – eine recht einfache Aktion, geschützt von einer recht einfachen Sicherheitsprüfung. Wenn ein Principal versucht, auf die Methode eines Objekts zuzugreifen, ist dies ein Entity-Zugriff, der in der Aktion und in der Sicherheitsprüfung absichtlich komplex sein kann.
6 ist ein Blockdiagramm, das die Trennung von Ausführungskontexten durch eine Firewall oder Kontextsperre gemäß einem Aspekt der vorliegenden Erfindung darstellt. Das physische Gerät 400 und die Maschine 410 entsprechen den selben Einheiten der 4. Ein Ausführungskontext 420 zeigt einen Principal 930, der versucht, auf das Objekt 440 im Kontext zuzugreifen. Dieser Zugriff wäre normalerweise erfolgreich. Allerdings zeigt der Ausführungskontext 420 auch einen Principal 630, der versucht, über eine Kontextsperre 600 auf ein Objekt 640 des Ausführungskontexts 620 zuzugreifen. Normalerweise wäre dieser Zugriff verboten, wie vom X 636 angezeigt, wo die Aktion 635 die Kontextsperre 600 überschreitet.
7 ist eine Darstellung einer Software-Architektur, die zur Ausführung der Erfindung dient. Diese Software-Architektur ist als Laufzeit-Umgebung 700 dargestellt, Ein Betriebssystem 710 für das Gerät mit kleinem Platzbedarf wird allgemein verwendet. Eine virtuelle Maschine 720 wird in einem beispielhaften Ausführungsbeispiel der Erfindung über dem Betriebssystem implementiert. Die virtuelle Maschine könnte eine Java Card^TM virtuelle Maschine oder eine andere virtuelle Maschine sein. Die Fähigkeiten einer normalen virtuellen Maschine können erweitert werden, um die hier beschriebene zusätzliche Funktionalität zu schaffen, oder die Funktionalität kann in Form getrennter Module geschaffen werden. Die virtuelle Maschine 720 kann einen Interpreter oder eine native Implementierung 730 enthalten, die Zugriff auf ein Laufzeitsystem 740 schafft. Das Laufzeitsystem umfasst das Objektsystem 750 zum Management der Objekte einer objektorientierten Implementierung. Drei Kontexte, 760, 770 und 780, werden dargestellt. Jeder Kontext ist vom anderen durch eine (manchmal als Firewall bezeichnete) Kontextsperre zwischen den Ausführungskontexten getrennt. Der Kontext 760 ist in einem spezifischen Ausführungsbeispiel ein Superkontext. Das heißt, der Kontext 760 hat Privilegien und Fähigkeiten, die den untergeordneten Kontexten 770 und 780 nicht zur Verfügung stehen. Dazu gehören potentiell Privilegien zur Schaffung von Einsprungstellenobjekten oder globalen Datenstrukturen und zum Zugreifen auf Objekte in untergeordneten Kontexten 770 und 780.
Jedes Objekt ist einem bestimmten Kontext zugeordnet. Von diesem Kontext wird gesagt, er besitze das Objekt, das ihm zugeordnet ist. Das Laufzeitsystem 740 schafft ein Mittel zur eindeutigen Identifizierung von Kontexten und ein Mittel zur Spezifizierung und Identifizierung des aktuell ausgeführten Kontexts. Das Objektsystem 750 schafft einen Mechanismus zur Zuordnung von Objekten zu ihren Eigentümer-Kontexten.
Beispielsweise kann die Laufzeit 740 Kontexte mit einem eindeutigen Namen identifizieren, und entsprechend kann das Objektsystem 750 Objekte mit diesem Kontext assoziieren, indem der Name des Kontexts im Header des Objekts eingetragen wird. Auf Informationen im Header des Objekts kann nicht mit Programmen zugegriffen werden, die in der objektorientierten Sprache geschrieben wurden; sie stehen nur in der virtuellen Maschine 720 selbst zur Verfügung. Ansonsten kann das Laufzeitsystem 740 Kontexte identifizieren, indem der Speicherplatz in getrennte Bereiche je für einen bestimmten Kontext, unterteilt wird, und entsprechend kann das Objektsystem 750 Objekte mit diesem Kontext assoziieren, indem die Speicherung des Objekt: dem Speicherplatz dieses Objekts zugeteilt wird.
8 ist ein Fließdiagramm eines Sicherheitsumsetzungsprozesses, der eine Kontextsperre gemäß einem Aspekt der Erfindung implementiert. Wenn ein Principal zu einem Objekt eine Aktion abruft (800), wird eine Prüfung vorgenommen, ob sich das Objekt im Kontext des Principals befindet (810). Ist dies nicht der Fall, wird die Aktion verboten (840). Andernfalls wird die Aktion erlaubt (830). Dies ist die einfachste Form einer Kontextsperre bzw. Firewall. In einem besonderen Ausführungsbeispiel wird die Aktion verboten (840), indem eine Sicherheitsausnahme ausgeworfen wird, wenn sich das Objekt außerhalb der Namensstelle oder des Speicherplatzes des Zugriff verlangenden Kontexts befindet.
9 ist ein Blockdiagramm, in dem der Objektzugriff über eine Firewall gemäß einem Aspekt der Erfindung dargestellt ist. 9 ist im wesentlichen gleich wie 6. Allerdings ist in 9 auch Principal 900 dargestellt, der auf das Objekt 910 zugreifen will, um die Aktion 905 am Objekt 910 durchzuführen. Gemäß der Erfindung wird der Zugriff nicht durch die Firewall 600 blockiert, so wie die Aktion 635 blockiert wird, sondern die Aktion 905 über die Firewall durch die Zugriffstelle 920 erlaubt, so dass der Principal 900 die Aktion 905 am Objekt 910 ausführen kann, ungeachtet der Tatsache, dass der Principal und das Objekt in unterschiedlichen Ausführungskontexten sind. Die Mechanismen hinter der Zugriffstelle 920 werden unten unter Bezugnahme auf 12-18 beschrieben. Es ist zu beachten, dass die Zugriffstelle 920 mit gesperrten Zugriffen wie X 636 koexistieren kann. So schafft die Zugriffstelle 920 eine Feinkontrolle für das Sharing (objektbezogene Sicherheit) über die Kontextsperre 600 hinweg.
Wenn, der Objektzugriff 900 initiiert wird, ist die aktuelle Kontexteinstellung Kontext 420. Wenn das Objekt 910 ein Datenobjekt ist, ist die Aktion 905 ein einfacher Datenzugriff, und im zweiten Kontext 620 wird kein Code ausgeführt. Wenn das Objekt 910 ein Entity-Objekt ist und die Aktion 905 in der Ausführung des Codes dieses Objekts resultiert, wird dieser Code im zweiten Kontext 620 ausgeführt. Um den Code des Objekts 910 im richtigen Kontext 620 auszuführen, führt die virtuelle Maschine 410 einen Kontextwechsel durch. Der Kontextwechsel ändert die aktuelle Kontexteinstellung auf Kontext 620, und der ältere Wert der aktuellen Kontexteinstellung wird gespeichert, damit er später wiederhergestellt werden kann. Von diesem Punkt an führt der Code im neuen aktuellen Kontext aus. Wenn die Aktion 905 abgeschlossen ist, springt die Kontrolle an den Punkt nach dem Zugriff 900 zurück. Während des Rücksprungs muss die virtuelle Maschine 410 den Wert der aktuellen Kontexteinstellung auf seinem früheren Wert wiederherstellen.
10 ist ein Blockdiagramm, das kaskadierte Objektzugriffe über eine Firewall zeigt. 10 zeigt die drei Ausführungskontexte 1000, 1010 und 1020. Der Principal 1030 im Ausführungskontext 1 möchte eine Aktion 1035 an Objekt 1050 im Ausführungskontext 2 abrufen und unternimmt dies durch die Zugriffstelle 1070 in der Kontextsperre 600. Das Objekt 1050 im Ausführungskontext 2 hat einen Objektzugriff 1040, der eine Aktion 1045 am Objekt 1060 im Ausführungskontext 3 durchführen will. Er erreicht dies durch die Benutzung der Zugriffstelle 1080 in der Kontextsperre 600', die die Ausführungskontexte 2 und 3 trennt. Das Objekt 1050 im Ausführungskontext 2 hat auch einen anderen Objektzugriff 1090, der eine Aktion 1095 an einem Objekt 1099 im selben Ausführungskontext abruft, also im Ausführungskontext 2. Beide Aktionen 1035 und 1095 ergeben Kontextwechsel, wie in der Erklärung der 9 beschrieben. Doch da die Aktion 1095 die Kontextsperre nicht überschreitet, ist für die Ausführung kein Kontextwechsel erforderlich und findet deshalb auch nicht statt.
11 ist ein Fließdiagramm eines Verfahrens zur Ermöglichung des Zugriffs durch einen Principal in einem Kontext über eine Firewall in einen andern Kontext. Dieser Prozess besteht im wesentlichen aus drei Schritten. Im Ausführungskontext 2 wird ein Objekt, auf das zugegriffen werden soll, geschaffen und als gemeinsam (Shared) bezeichnet (1100). Im Ausführungskontext 1 erhält der Principal einen Verweis auf das Objekt im Ausführungskontext 2 (1110). Der Principal im Ausführungskontext 1 ruft dann eine Aktion zu dem in Kontext 2 als gemeinsam bezeichneten Objekt ab (1120).
Bezüglich der Identifizierung oder Bezeichnung eines erzeugten Objekts als gemeinsam benutzbar (shareable), wie in Punkt, 1100 der 11 diskutiert, ist diese gemäß einem bestimmten Ausführungsbeispiel der Erfindung durchführbar durch Einführung eines gemeinsam benutzbaren Attributs in den Header einer Objektdarstellung. Auf die Informationen im Header eines Objekts kann nicht durch Programme zugegriffen werden, die in der objektorientierten Sprache geschrieben wurden; sie stehen nur der VM selbst zur Verfügung.
Das Einholen einer Referenz zu einem Objekt in einem anderen Kontext ist ein Sonderfall eines Zugriffs auf ein Objekt in einem anderen Kontext. Ein Mechanismus, der den Zugriff auf ein Objekt in einem anderen Kontext bietet, kann auch andere Objekte verfügbar machen. Beispielsweise kann das Abrufen einer Methode zu einem Objekt in einem anderen Kontext. einen Verweis auf ein zweites Objekt in einem anderen Kontext ergeben. Ein zusätzlicher Mechanismus ist erforderlich, um einen Erstverweis auf ein Objekt in einem anderen einzuholenden Kontext zu erlauben. In einem besonderen Ausführungsbeispiel können unter Verwendung einer öffentlichen API Verweise auf bestimmte gut bekannte Einsprungstellenobjekte eingeholt werden. Nachdem der Erstverweis auf ein Objekt in einem anderen Kontext eingeholt ist, können weitere Verweise von diesem Objekt eingeholt werden, und so weiter.
Es gibt nach der Erfindung vier allgemeine Ansätze zum Einholen von Informationen über eine Kontextsperre hinweg. Diese Ansätze können einzeln oder in Kombination benützt werden, um auf ein Objekt über eine Kontextsperre hinweg zuzugreifen oder einen Verweis von einem Objekt zu erhalten, auf das über eine Kontextsperre zugegriffen werden soll (1110). Diese Ansätze werden in 12-18 beschrieben.
12 ist ein Blockdiagramm, in dem die Verwendung von Einsprungstellenobjekten für Zugriffe über eine Kontextsperre dargestellt ist. Wie in 12 dargestellt, will ein Objekt 1200 im Kontext 770 (Kontext 1) Zugriff auf Informationen im Superkontext 760 zugreifen. In dem spezifischen Ausführungsbeispiel enthält ein Superkontext 760 mindestens ein Einsprungstellenobjekt 1210. Das Einsprungstellenobjekt 1210 kann als Teil einer öffentlichen API veröffentlicht werden oder indirekt über eine veröffentlichte API verfügbar gemacht werden (z. B. gemäß den Mechanismen, die oben in Bezug zu 11 beschrieben wurden), so dass jeder dem Superkontext untergeordnete Kontext mit dem Einsprungstellenobjekt des Superkontexts kommunizieren kann. (Es versteht sich, dass in anderen Ausführungsbeispielen Einsprungstellenobjekte von einem anderen Kontext als dem Superkontext beherbergt werden können.)
13 ist ein Blockdiagramm, in dem die Verwendung globaler Datenstrukturen zum Erlauben des Zugriffs über eine Firewall dargestellt ist. In diesem Ansatz schafft der Superkontext 760 eine globale Datenstruktur, wie ein globales Array. Im spezifischen Ausführungsbeispiel ist der Superkontext 760 der einzige Kontext, dem die Erzeugung einer solchen globalen Datenstruktur erlaubt ist. (Es versteht sich, dass in anderen Ausführungsbeispielen globale Daten durch einen anderen Kontext als den Superkontext beherbergt werden können). Kraft seines globalen Status kann jeder der Kontexte 770 und 780 an die globale Datenstruktur schreiben und diese lesen. Folglich können Informationen, die von einem Kontext in die globale Datenstruktur geschrieben werden, von einem anderen Kontext gelesen werden. Beispielsweise kann dieser Mechanismus dazu verwendet werden, binäre Daten oder Verweise an Objekte zwischen Kontexten weiter zu geben.
14 ist ein Blockdiagramm, in dem die Verwendung von Superkontext-Privilegien für den Zugriff über eine Kontextsperre dargestellt ist. In 14 will ein Objekt im Superkontext 760 Zugriff auf den Kontext 780 über die diese beiden trennende Kontextsperre hinweg. Der Superkontext 760 kann jede der Methoden des Kontexts 780 abrufen und kraft der mit dem Superkontext verbundenen Privilegien auf alle im Kontext 780 enthaltenen Daten zugreifen.
15 ist ein Blockdiagramm, in dem die Verwendung gemeinsam benutzbarer Interface-Objekte für den Zugriff über eine Firewall dargestellt ist. Eine gemeinsam benutzbare Interface (Shareable Interface) definiert eine Gruppe gemeinsam benutzbarer Interface-Methoden. Ein gemeinsam benutzbares Interface-Objekt ist ein Objekt, das mindestens die Gruppe von Methoden implementiert, die in einer gemeinsam benutzbaren Interface definiert sind. In 15 ist das Objekt 1210 in Kontext 2 (780) ein gemeinsam benutzbares Interface-Objekt. Ein Objektzugriff 1200 in einem anderen Kontext 770 kann jede der gemeinsam benutzbaren Interface-Methoden zum. Objekt 1210 abrufen, wenn der Principal des Objektzugriffs 1200 vom Objekt 1210 selbst dazu autorisiert ist. Diese Autorisierung wird unter Bezugnahme auf 18 unten näher erörtert.
Es versteht sich, dass eine virtuelle Maschine in Entsprechung mit der Erfindung eine Funktionalität über die früherer virtueller Maschinen hinaus besitzt, wie etwa die in der Java^TM Virtual Machine Specification beschriebene Maschine. Insbesondere bietet die virtuelle Maschine im Einklang mit der Erfindung die Funktionalität, einen Sicherheitsumsetzungsprozess zu implementieren oder zu ermöglichen, der einen Zugriff über eine Firewall hinweg erlaubt. Dieser Prozess wird als nächstes unter Bezugnahme auf 16-18 beschrieben. Es ist zu beachten, dass er für jede Variante zur Gewährung des Zugriffs über eine Firewall gültig ist, einschließlich aber nicht beschränkt auf die vier Verfahren, die unter Bezugnahme auf 12-15 oben beschrieben wurden.
16 ist ein Fließdiagramm eines Sicherheitsumsetzungsprozesses, der den Zugriff über eine Firewall hinweg gestattet. Wenn ein Principal versucht, eine Aktion zu einem Objekt 1600 abzurufen, wird eine Prüfung ausgeführt, um festzustellen, ob das Objekt sich im Kontext des Principals befindet (1610). Ist dies der Fall (1610-Y), wird die Aktion zugelassen (1630). Ist dies nicht der Fall (1610-N), wird eine Prüfung vorgenommen, um festzustellen, ob die Aktion vom Principal auf das Objekt zugelassen ist (1620). Ist dies der Fall (1620-Y), wird die Aktion erlaubt (1630). Ist dies nicht der Fall (1620-N), wird die Aktion verboten. In dem spezifischen Ausführungsbeispiel wird eine Sicherheitsausnahme ausgeworfen (1640).
17 ist das Fließdiagramm der 16, in dem weitere Details des Blocks 1620 dargestellt sind. Wenn sich das Objekt nicht im Kontext des Principals befindet (1610-N), wird eine Mehrzahl von Tests 1621, 1622, 1623,... 1629 durchgeführt, um festzustellen, ob die Aktion durch den Principal auf das Objekt erlaubt ist. Diese Tests können von der virtuellen Maschine allein durchgeführt werden, oder in einer Virtualmaschinen-objektorientierten Implementierung von der virtuellen Maschine plus dem Objekt. Wenn einer der Tests bestanden wird, ward die Aktion erlaubt (1630). Wenn allerdings alle Tests eine negative Bestimmung ergeben (162X-No), wird die Aktion verboten. In einem spezifischen Ausführungsbeispiel wird eine Sicherheitsausnahme ausgeworfen (1640). Diese Tests beziehen sich auf den erlaubten Zugriff in Verbindung mit 12-15.
18 ist ein Fließdiagramm, das eine exemplarische Implementierung von Block 1629 der 17 zur Verwendung mit einer in 15 beschriebenen Zugriffsmethode darstellt. In einem Test, wie etwa 829 oder 1629, prüft eine virtuelle Maschine, ob das Objekt ein gemeinsames Objekt 1810 ist. Ist dies nicht der Fall (1810-No), scheitert der Test. Ist dies jedoch der Fall (1810-Yes), ruft die virtuelle Maschine die Methode A zu Objekt 0 ab (820). Wenn die Methode A zu Objekt 0 feststellt, dass der Principal autorisiert ist (1830), ist der Test bestanden (1840) und wird der Zugriff erlaubt. Ansonsten scheitert der (1850). Dies ermöglicht die Programmierung des Autorisierungstexts in den Code des Objekts selbst.
Zwar wurde die Erfindung mit Bezug auf eine Smartcard-Implementierung illustriert, doch ist sie für andere Geräte mit kleinem Platzbedarf ebenfalls gültig, nicht nur für Smartcards. Als Geräte mit kleinem Platzbedarf gelten allgemein solche, deren Speicher, Rechenleistung oder Geschwindigkeit beschränkt oder limitiert ist. Solche Geräte mit kleinem Platzbedarf können neben vielen anderen Grenz-Scangeräte, feldprogrammierbare Geräte, Pager und Zelltelefone umfassen.
Im allgemeinen sind Geräte mit kleinem Platzbedarf ressourcenbeschränkte Computergeräte und Systeme, bei denen es auf die sichere Zusammenarbeit von Ausführungskontexten ankommt. Solche Kleingeräte legen der Implementierung von Sicherheitsvorkehrungen aufgrund ihrer limitierten Ressourcen Beschränkungen auf. Infolge von Ressourcenbeschränkungen muss in einer Virtuell-Maschinen-Implementierung eine einzelne virtuelle oder physische Maschine verwendet werden, im Gegensatz zu mehreren virtuellen Maschinen.
Die Erfindung kann auch auf Geräte mit größerem Platzbedarf angewendet werden, sofern sich die Merkmale der Erfindung als vorteilhaft erweisen. Beispielsweise kann sich die Erfindung als vorteilhaft bei der Verwendung von Servlets erweisen, wenn zwischen diesen ein Objekt-Sharing stattfindet. Auch einige Desktop-Systeme können die Techniken der Erfindung zu ihrem Vorteil nutzen.
Zwar eignen sich die Sprache und Plattform Java^TM gut für die Erfindung, doch wären auch andere Sprachen und Plattformen mit bestimmten Merkmalen gut für die Implementierung der Erfindung geeignet. Zu diesen Merkmalen gehören Typensicherheit, Pointer-Sicherheit, objektorientiert, dynamisch verknüpft und auf virtueller Maschine basierend. Nicht alle diese Merkmale müssen in einer bestimmten Implementierung vorhanden sein. In einigen Ausführungsbeispielen können auch Sprachen oder Plattformen verwendet werden, denen eine oder mehrere dieser Eigenschaften fehlen. Eine "virtuelle Maschine" könnte entweder in Bits (virtuelle Maschine) oder in Silikon (reale/physische Maschine) implementiert werden.
Zwar wurde die Erfindung nach Objekt-bezogener Sicherheit veranschaulicht, doch könnten auch andere Ansätze, wie beispielsweise Klassen-bezogene Sicherheit, herangezogen werden.
Obwohl die vorliegende Erfindung detailliert beschrieben und illustriert wurde, versteht es sich von selbst, dass die Beschreibung nur illustrativen und beispielhaften Charakter hat und ihr keine einschränkende Bedeutung zukommt, so dass der Geltungsbereich der vorliegenden Erfindung nur durch die angehängten Patentansprüche und deren Äquivalente eingeschränkt werden kann.
6. Applet-Isolierung und Objekt-Sharing
Jede Implementierung des Java^TM Card^TM Runtime Environment (JCRE - Java Card Laufzeitumgehung) unterstützt die Isolierung von Inhalten und Applets. Isolierung bedeutet, dass ein Applet nicht auf die Felder oder Objekte eines Applets in einem anderen Kontext zugreifen kann, es sei denn, das andere Applet bietet ausdrücklich eine Interface für den Zugriff. Die JCRE-Mechanismen für Applet-Isolierung und Objekt-Sharing werden in den nachstehenden Kapiteln beschrieben.
6.1 Applet-Firewall
Die Applet-Firewall ist im Rahmen der Java-Card-Technologie ein Laufzeit-realisierter Schutz und von den Schutzvorkehrungen der Java-Technologie getrennt. Sie Java Sprach-Schutzvorkehrungen sind für Java Card Applets nach wie vor gültig. Die Sprache Java stellt sicher, dass starke Typing- und Schutzattribute umgesetzt werden.
Applet-Firewalls werden immer in der Java Card VM durchgesetzt. Sie ermöglichen der VM die automatische Durchführung zusätzlicher Sicherheitsprüfungen bei der Laufzeit.
6.1.1 Kontexte und Kontextwechsel
Firewalls unterteilen im wesentlichen das Objektsystem der Java Card Plattform in getrennte, geschützte Objektstellen, die als Kontexte bezeichnet werden. Die Firewall ist die Grenze zwischen einem Kontext und einem anderen. Die JCRE hat die Aufgabe, einen Applet-Kontext für jedes auf der Karte installierte Applet zuzuteilen und zu verwalten (vgl. aber Paragraph 6.1.1.2 zu einer Diskussion von Gruppenkontexten.)
Zusätzlich behält die JCRE ihren eigenen JCRE-Kontext. Dieser Kontext ähnelt stark einem Applet-Kontext, hat aber spezielle Systemprivilegien, so dass er Operationen ausführen kann, die Applet-Kontexten verwehrt sind.
Zu jedem bestimmten Zeitpunkt gibt es in der VM nur einen aktiven Kontext (dieser wird als aktuell aktiver Kontext bezeichnet). Alle Bytecodes, die auf Objekte zugreifen, werden zur Laufzeit mit dem aktuell aktiven Kontext verglichen, um festzustellen, ob der Zugriff erlaubt ist. Wenn ein Zugriff nicht erlaubt ist, wird eine java.lang.SecurityException ausgeworfen.
Wenn bestimmte, genau definierte Bedingungen während der Ausführung von. Aufruf-Bytecodes erfüllt sind, wie in Paragraph 6.2.8. beschrieben, führt die VM einen Kontextwechsel durch. Der vorherige Kontext wird in einen internen VM-Stack verschoben, ein neuer Kontext wird zum aktuell aktiven Kontext, und die aufgerufene Methode wird im neuen Kontext ausgeführt. Nach dem Ende dieser Methode führt die VM einen wiederherstellenden Kontextwechsel durch. Der ursprüngliche Kontext (vom Aufrufer der Methode) wird aus dem Stack geholt und als aktuell aktiver Kontext wiederhergestellt. Kontextwechsel können verschachtelt sein. Die Maximaltiefe ist von der Menge an verfügbarem VM-Stack-Platz abhängig.
Die meisten Methodenabrufe in der Java-Card-Technologie lösen keinen Kontextwechsel aus. Zu Kontextwechseln kommt es nur während eines Aufrufs bestimmter und einer Rückkehr von bestimmten Methoden sowie während Ausnahme-Ausstiegen von diesen Methoden (vgl. 6.2.8).
Während des Aufrufs einer kontextwechselnden Methode wird ein zusätzliches Datum, das den aktuell aktiven Kontext anzeigt, auf den Rücksprung-Stack verschoben. Dieser Kontext wird wiederhergestellt, wenn die Methode beendet wird.
Weitere Einzelheiten zu Kontexten und Kontextwechseln finden sich in späteren Abschnitten dieses Kapitels.
6.1.1.1 Gruppenkontexte
In der Regel definiert jede Instanz eines Java Card Applets einen eigenen Kontext, aber mit der Java Card 2.1 Technologie wird das Konzept des Gruppenkontexts eingeführt. Wenn in einem einzelnen Java-Paket mehr als ein Applet enthalten ist, so teilen sie den selben Kontext. Außerdem teilen alle Instanzen der selben Applet-Klasse den selben Kontext. Mit anderen Worten, es befindet sich keine Firewall zwischen zwei Applet-Instanzen in einem Gruppenkontext.
Die oben in Abschnitt 6.1.1 gegebene Erörterung zu Kontexten und Kontextwechseln geht davon aus, dass jede Applet-Instanz mit einem eigenen Kontext assoziiert ist. In der Java Card 2.1 Technologie werden Kontexte verglichen, um die Firewall durchzusetzen, und die Instanz-AID wird auf den Stack verschoben. Außerdem passiert dies nicht nur, wenn der Kontext wechselt, sondern auch wenn die Kontrolle von einem Objekt im Eigentum einer Applet-Instanz zu einem Objekt übergeht, das im Eigentum einer anderen Instanz innerhalb des selben Pakets ist.
6.1.2 Objekt-Eigentum
Wenn ein neues Objekt geschaffen wird, wird es mit dem aktuell aktiven Kontext assoziiert. Doch das Objekt befindet sich im Eigentum der Applet-Instanz innerhalb des aktuell aktiven Kontexts, wenn das Objekt als Instanz gebildet wird. Ein Objekt ist im Eigentum einer Applet-Instanz oder der JCRE.
6.1.3 Objektzugriff
Im allgemeinen kann auf ein Objekt nur von seinem Eigentümer-Kontext zugegriffen werden, das heißt, wenn der besitzende Kontext der aktuell aktive Kontext ist. Die Firewall verhindert, dass auf ein Objekt von einem anderen Applet in einem anderen Kontext zugegriffen werden kann.
Bezüglich Implententierung wird jedes Mal, wenn auf ein Objekt zugegriffen wird, der Eigentümerkontext des Objekts mit dem aktuell aktiven Kontext verglichen. Wenn diese nicht zusammen passen, wird der Zugriff nicht ausgeführt und eine SecrityException ausgeworfen.
Auf ein Objekt wird zugegriffen, wenn einer der folgenden Bytecodes unter Verwendung des Objekt-Verweises ausgeführt wird:
getfield, putfeld, invokevirtual, invokeinterface,
athrow, <T>aload, <T>astore, arraylength, checkcast, instanceof
<T> bezieht sich auf die unterschiedlichen Typen von Array-Bytecodes, wie baload, sastore usw.
Diese Liste enthält alle speziellen oder optimierten Formen dieser Bytecodes, die in der Java Card VM implementiert werden, wie getfield_b, sgetfield_s_this, usw.
6.1.4 Firewall-Schutz
Die Java Card Firewall bietet Schutz gegen das am häufigsten zu erwartende Sicherheitsproblem: Entwicklerfehler und Designübersehungen, die sensitiven Daten ein "Aussickern" in ein anderes Applet erlauben könnten. Ein Applet kann fähig sein, einen Objektverweis von einer öffentlich zugänglichen Stelle zu erhalten, doch wenn das Objekt im Eigentum eines anderen Applets ist, gewährleistet die Firewall die Sicherheit.
Die Firewall bietet zudem Schutz vor inkorrektem Code. Wenn inkorrekter Code auf eine Karte geladen wird, schützt die Firewall die Objekte nach wie vor vor einem Zugriff durch diesen Code.
Die Java Card API 2.1 spezifiziert die grundlegenden Mindestschutzerfordernisse von Kontexten und Firewalls, weil diese Features auf eine Art und Weise unterstützt werden, die für den Applet-Entwickler nicht transparent sind. Die Entwickler achten auf das Verhalten von Objekten, APIs und Ausnahmen mit Bezug auf die Firewall.
JCRE-Implementoren können ohne weiteres zusätzliche, über jene der Applet Firewall hinausgehende Sicherheitsmechanismen implementieren, solange diese Mechanismen für Applets transparent sind und die extern sichtbare Operation der VM nicht verändern.
6.1.5 Statische Felder und Methoden
Es ist ebenfalls festzuhalten, dass Klassen nicht im Eigentum von Kontexten stehen. Es gibt keine Laufzeitkontextprüfung, die ausgeführt werden kann, wenn auf ein statisches Klassenfeld zugegriffen wird. Noch gibt es einen Kontextwechsel, wenn eine statische Methode; aufgerufen wird. (Ähnlicherweise verursacht auch invokespecial keinen Kontextwechsel.) Öffentliche statische Felder und öffentliche statische Methoden sind aus jedem Kontext. zugreifbar: statische Methoden führen im selben Kontext aus wie ihr Aufrufer.
Objekte, auf die in statischen Feldern verwiesen wird, sind nur reguläre Objekte. Sie stehen im Eigentum dessen, der sie geschaffen hat, und es gelten die standardmäßigen Firewall-Zugriffsregeln. Wenn es erforderlich ist, sie über mehrere Applet-Kontexte hinweg zu teilen, müssen diese Objekte Shareable Interface Objects (SIOs - Gemeinsam benutzbare Interface-Objekte) sein. (Vgl. Paragraph 6.2.9 unten.)
Natürlich werden die herkömmlichen Schutzvorkehrungen der Java Technologie für statische Felder und Methoden nach wie vor angewendet. Wenn Applets installiert werden, überzeugt sich außerdem der Installierende davon, dass jeder Versuch einer Verknüpfung mit einem externen statischen Feld oder einer Methode erlaubt ist. Die Installation und Spezifika über die Verknüpfung gehen über den Aufgabenbereich dieser Spezifikation hinaus.
6.1.5.1 Optionale statische Zugriffsprüfungen
Die JCRE kann opionale Laufzeitprüfungen vornehmen, die zu den von einem Verifizierer umgesetzten Beschränkungen redundant sind. Eine Java Card VM kann feststellen, wenn von einem Code fundamentale Sprachrestriktionen verletzt werden, wie der Aufruf einer privaten Methode in einer anderen Klasse, und die Verletzung berichten oder auf andere Weise bearbeiten.
6.2 Objektzugriff über Kontexte hinweg
Um Applets die Interaktion untereiander und mit der JCRE zu gestatten, werden einige gut definierte, doch sichere Mechanismen bereitgestellt, damit ein Kontext auf ein Objekt zugreifen kann, das zu einem anderen Kontext gehört.
Diese Mechanismen werden in der Java Card API 2.1 bereitgestellt und in den folgenden Abschnitten erörtert:

– JCRE Einsprungstellen-Objekte
– Globale Arrays
– JCRE Privilegien
– Gemeinsam benutzbare Interfaces

6.2.1 JCRE Einsprungstellen-Objekte
Sichere Computersysteme bieten eine Möglichkeit für nicht-privilegierte Benutzerprozesse (die auf eine Teilgruppe von Ressourcen beschränkt sind), Systemdienste zu verlangen, die von privilegierten "System"-Routinen ausgeführt werden.
In der Java Card API 2.1 wird dies erreicht durch die Verwendung von JCRE Einsprungstellen-Objekten. Dabei handelt es sich um Objekte im Eigentum des JCRE-Kontexts, die jedoch markiert wurden, dass sie Einsprungstellenmethoden enthalten.
Die Firewall schützt diese Objekte vor einem Zugriff durch Applets. Die Einsprungstellenbezeichnung ermöglicht es den Methoden dieser Objekte, von jedem Kontext aufgerufen zu werden. Wenn dies stattfindet, wird ein Kontextwechsel zum JCRE-Kontext ausgeführt. Diese Methoden sind die Zugänge, über die Applets privilegierte JCRE Systemdienste verlangen.
Es gibt zwei Kategorien von JCRE Einsprungstellen-Objekten:

– Temporäre JCRE Einsprungstellen-Objekte

Wie alle JCRE Einsprungstellen-Objekte können die Methoden temporärer JCRE Einsprungstellen-Objekte von jedem Applet-Kontext aufgerufen werden. Allerdings können die Verweise auf diese Objekte nicht in Klassenvariablen, Instanzvariablen oder Array-Komponenten gespeichert werden. Im Rahmen der Firewall-Funktionalität zur Verhinderung unzulässiger Wiederverwendung entdeckt und beschränkt die JCRE Versuche, Verweise auf diese Objekte zu speichern.
Das APDU-Objekt und alle Ausnahmeobjekte im JCRE-Eigentum sind Beispiele temporärer JCRE Einsprungstellen-Objekte.

– Permanente JCRE Einsprungstellen-Objekte

Wie alle JCRE Einsprungstellen-Objekte können die Methoden permanenter JCRE Einsprungstellen-Objekte von jedem Applet-Kontext aufgerufen werden. Zusätzlich können Verweise auf diese Objekte gespeichert und frei wiederverwendet werden.
AID-Instanzen im JCRE-Eigentum sind Beispiele permanenter JCRE Einsprungstellen-Objekte.
Die JCRE ist verantwortlich für:

– Feststellung, welche privilegierten Services den Applets erbracht werden.
– Definition vor Klassen, welche die Einsprungstellen-Methoden für diese Services enthalten.
– Schaffen einer oder mehrerer Objekt-Instanzen dieser Klassen.
– Bezeichnung dieser Instanzen als JCRE Einsprungstellen-Objekte.
– Bezeichnung der JCRE Einsprungstellen-Objekte als temporär oder permanent.
– Erzeugen von Verweisen auf die Objekte, die für Applets so wie benötigt verfügbar sind.

Hinweis: Nur die: Methoden dieser Objekte sind durch die Firewall zugreifbar. Die Felder dieser Objekte sind nach wie vor von der Firewall geschützt und nur vom JCRE-Kontext zugreifbar.
Nur die JCRE selbst kann Einsprungstellen-Objekte bezeichnen und ob diese temporär oder permanent sind. JCRE-Implementierer sind verantwortlich für die Implementierung des Mechanismus, durch den JCRE Einsprungstellen-Objekte bezeichnet werden und wie diese temporär oder permanent werden.
6.2.2 Globale Arrays
Die globale Natur einiger Objekte erfordert, dass sie von jedem Applet-Kontext zugreifbar sind. Die Firewall würde die flexible Verwendung dieser Objekte normalerweise verhindern. Die Java Card VM ermöglicht die Bezeichnung eines Objekts als global.
Alle globalen Arrays sind temporäre globale Array-Objekte. Diese Objekte sind im Eigentum des JCRE-Kontexts, können aber von jedem Applet-Kontext aus zugegriffen werden. Verweise auf diese Objekte können allerdings nicht in Klassenvariablen, Instanzvariablen oder Array-Komponenten gespeichert werden. Im Rahmen der Firewall-Funktionalität zur Verhinderung unzulässiger Wiederverwendung entdeckt und beschränkt die JCRE Versuche, Verweise auf. diese Objekte zu speichern.
Im Sinne einer zusätzlichen Sicherheit können nur Arrays als global bezeichnet werden, und nur die JCRE selbst kann globale Arrays bezeichnen. Da Applets sie nicht erzeugen können, werden keine API-Methoden definiert. JCRE-Implementierer sind für die Implementierung des Mechansimus verantwortlich, mit dem globale Arrays bezeichnet werden.
Zur Zeit der Veröffentlichung dieser Spezifikation sind die einzigen globalen Arrays, die in der Java Card API 2.1 erforderlich sind, der APDU-Puffer und der Byte-Array-Eingabeparameter (bArray) in die install-Methode des Applets.
Hinweis: Aufgrund seines globalen Status legt die API fest, dass der APDU-Puffer immer bei der Auswahl eines Applets auf Nullen rückgesetzt wird, bevor die. JCRE ein neues APDU-Kommando annimmt. Damit soll verhindert werden, dass die potentiell sensitiven Daten eines Applets über den globalen APDU-Puffer zu einem anderen Applet "durchsickern". Auf den APDU-Puffer kann von einem gemeinsamen Interface-Objekt-Kontext zugegriffen werden, und er eignet sich für die Weitergabe von Daten über Applet-Kontexte hinweg. Das Applet ist verantwortlich für den Schutz geheimer Daten, auf die von dem APDU-Puffer zugegriffen werden kann.
6.2.3 JCRE-Privilegien
Da es sich um den "System"-Kontext handelt, hat der JCRE-Kontext ein Sonderprivileg. Er kann eine Methode jedes Objekts auf der Karte aufrufen. Nehmen wir beispielsweise an, das Objekt X ist im Eigentum eines Applets A. Normalerweise kann nur der Kontext A auf die Felder und Methoden von X zugreifen. Doch der JCRE-Kontext darf jede Methode von X aufrufen. Während eines solchen Aufrufs findet ein Kontextwechsel vom JCRE-Kontext zum Applet-Kontext, der X besitzt, statt.
Hinweis: Die JCRE kann sowohl auf Methoden wie auf Felder von X zugreifen. Der Methoden-Zugriff ist der Mechanismus, mit dem die JCRE in einen Applet-Kontext eindringt. Obwohl die JCRE jede Methode durch die Firewall aufrufen könnte, ruft sie nur die in der Applet-Klasse definierten Methoden Select, process, deselect und getShareableInterfaceObject auf (vgl . 6.2.7.1).
Der JCRE-Kontext ist der aktuell aktive Kontext, wenn die VM nach einer Kartenrücksetzung zu laufen beginnt. Der JCRE-Kontext ist der "Wurzel"-Kontext und immer entweder der aktuell aktive Kontext oder der auf dem Stark gespeicherte Grundkontext.
6.2.4 Gemeinsam benutzbare Interfaces
Gemeinsam benutzbare Interfaces (Shareable Interfaces) sind ein neues Feature in der Java Card API 2.1 zur Ermöglichung von Applet-Interaktion. Eine gemeinsam benutzbare Interface definiert eine Gruppe gemeinsamer Interface-Methoden. Diese Interface-Methoden können von einem Applet-Kontext aufgerufen werden, auch wenn das sie implementierende Objekt einem anderen Applet-Kontext gehört.
In dieser Spezifikation wird eine Objekt-Instanz einer Klasse, die eine gemeinsam benutzbare Interface implementiert, als Shareable Interface Object: (SIO – Gemeinsam benutzbares Interface-Objekt) bezeichnet.
Für den besitzenden Kontext ist das SIO ein normales Objekt, auf dessen Felder und Methoden zugegriffen werden kann. Für jeden anderen Kontext ist das SIO eine Instanz der gemeinsam benutzbaren Interface, und nur auf die Methoden, die in der gemeinsam benutzbaren Interface definiert sind, kann zugegriffen werden. Alle anderen Felder und Methoden des SIO werden von der Firewall beschützt.
Gemeinsam benutztare Interfaces bieten einen sicheren Mechanismus für die Kommunikation zwischen Applets, wie folgt:

1. Um ein Objekt für ein anderes Applet verfügbar zu machen, definiert das Applet A zunächst eine gemeinsam benutzbare Interface SI. Eine gemeinsam benutzbare Interface erweitert die Interface javacard.framework.Shareable. Die in der gemeinsam benutzbaren Interface SI definierten Methoden repräsentieren die Services, die Applet A anderen Applets zugänglich macht.
2. Applet A definiert dann eine Klasse C, welche die gemeinsam benutzbare Interface SI implementiert. C implementiert die in SI definierten Methoden. C kann auch andere Methoden und Felder definieren, doch diese werden von der Applet-Firewall beschützt. Nur die in SI definierten Methoden sind für andere Applets zugreifbar.
3. Applet A erzeugt eine Objekt-Instanz 0 der Klasse C. 0 gehört dem A, und die Firewall erlaubt A den Zugriff auf eines der Felder und Methoden von 0.
4. Um auf das Objekt 0 des Applet A zuzugreifen, schafft Applet B einen Objektverweis SIO des Typs S2.
5. Applet B ruft eine spezielle Methode ab (JCSystem.getAppletShareableInterfaceObject, beschrieben in Paragraph 6.2.7.2), um einen Shared-Interface-Objekt-Verweis von Applet A zu verlangen.
6. Applet A empfängt die Anfrage und die AID des Anfragenden (B) über Applet.getShareableInterfaceObject und bestimmt, ob es das Objekt 0 mit Applet B gemeinsam benützen will oder nicht.
7. Wenn Applet der gemeinsamen Benutzung mit Applet B zustimmt, antwortet A auf die Anfrage mit einem Verweis auf 0. Dieser Verweis wird auf den Typ Shareable (gemeinsam benutzbar) umgewandelt, damit keines der Felder oder Methoden von 0 sichtbar sind.
8. Applet B empfängt den Objektverweis von Applet A, wandelt ihn in den Typ SI um und legt ihn in der Objektreferenz SIO ab. Auch wenn SIO eigentlich auf das Objekt 0 von A verweist, ist SIO vom Typ SI. Nur die in SI definierten gemeinsam benutzbaren Interface-Methoden sind für B sichtbar. Die Firewall verhindert den Zugriff von B auf die anderen Felder und Methoden von 0.
9. Applet B kann einen Service von Applet A durch Aufrufen einer der gemeinsam benutzbaren Interface-Methoden von SIO verlangen. Während des Aufrufs führt die Java Card VM einen Kontextwechsel aus. Der ursprüngliche aktuell aktive Kontext (B) wird auf einem Stack gespeichert, und der Kontext des Eigentümers (A) des aktuellen Objekts (0) wird der neue aktuell aktive Kontext. Die Implementierung der gemeinsam benutzbaren Interface-Methode (SI-Methode) durch A wird im Kontext von A ausgeführt.
10. Die SI-Methode kann die AID ihres Clients (B) über die Methode JCSystem,getPreviousContextAID herausfinden. Diese wird in Paragraf 6.2.5. beschrieben. Die Methode legt fest, ob sie den Service für das Applet B ausführen wird oder nicht.
11. Aufgrund des Kontextwechsels erlaubt die Firewall der SI-Methode den Zugriff auf alle Felder und Methoden des Objekts 0 und jedes andere Objekt im Eigentum von A. Gleichzeitig hindert die Firewall die Methode am Zugriff auf nicht gemeinsam benutzbare Objekte ("non-shared objects") im Eigentum von B.
12. Die SI-Methode kann auf die von B weitergegeben Parameter zugreifen und B einen Rücksprungwert bereitstellen.
13. Während des Rücksprungs führt die Java Card VM einen wiederherstellenden Kontextwechsel aus. Der ursprüngliche aktuell aktive Kontext (B) wird vom Stack ausgespeichert und wird wieder zum aktuellen Kontext.
14. Aufgrund des Kontextwechsels erlaubt die Firewall B erneut, auf eines seiner Objekte zuzugreifen und hindert B am Zugriff auf nicht gemeinsam benutzbare Objekte im Eigentum von A.

6.2.5 Ermittlung des vorhergehenden Kontexts
Wenn ein Applet JCSySfem.getPrevioUSConteXtAID aufruft, gibt die JCRE die Instanz-AID der Applet-Instanz aus, die zum Zeitpunkt des letzten Kontextwechsels aktiv war.
6.2.5.1 Der JCRE-Kontext
Der JCRE-Kontext hat keine AID. Wenn ein Applet die Methode getPreviousContextAID aufruft, wenn der Applet-Kontext direkt vom JCRE-Kontext eingegeben wurde, gibt diese Methode null aus.
Wenn das Applet gefPreviousContextAID von einer Methode aufruft, auf die entweder von innerhalb des Applets selbst oder bei Zugriff über eine gemeinsam benutzbare Interface von einem externen Applet zugegriffen werden kann, prüft es auf eine null-Ausgabe, bevor es eine Aufrufer-AID-Berechtigungsprüfung vornimmt.
6.2.6 Gemeinsam benutzbare Interface (Shareable Interface)
Eine gemeinsam benutzbare Interface ist einfach eine solche, die (direkt oder indirekt) die identifizierende Interface ("tagging" Interface) javaprd.framework.Shareable erweitert. Diese Shareable Interface ähnelt im Konzept der von der RMI-Funktion verwendeten Entfernten Interface ("Remote" Interface), bei der Aufrufe zu den Interface-Methoden über eine lokale/entfernte Grenze stattfinden.
6.2.6.1 Die Java Card Shareable Interface
Interfaces, welche die Shareable Tagging Interface erweitern, besitzen diese besondere Eigenschaft: Aufrufe an die Interface-Methode finden via Kontextwechsel über die Firewall-Grenze des Java Card Applets statt.
Die Shareable Interface dient der Identifizierung aller gemeinsam benutzten Objekte. Alle Objekte, die durch die Applet Firewall geteilt werden müssen, müssen diese Interface direkt oder indirekt implementieren. Nur die in. einer gemeinsam benutzbaren Interface spezifizierten Methoden sind durch die Firewall verfügbar.
Implementierungsklassen können jede beliebige Zahl von gemeinsam benutzbaren Interfaces implementieren und andere gemeinsam benutzbare Implementierungsklassen erweitern.
Wie jede Java Plattform Interface, definiert eine gemeinsam benutzbare Interface einfach eine Gruppe von Service-Methoden. Eine Service-Anbieter-Klasse erklärt, dass sie die gemeinsam benutzbare Interface "implementiert" und schafft Implementierungen für jede Service-Methode der Interface. Eine Service-Client-Klasse greift auf die Services zu, indem sie einen Objektverweis erlangt, diesen wenn nötig in den Typ "Benutzbare Interface" umwandelt und die Service-Methoden der Interface aufruft.
Die gemeinsam benutzbaren Interfaces im Rahmen der Java Card Technologie haben folgende Eigenschaften:

– Wenn eine Methode in einer gemeinsam benutzbaren Interface aufgerufen wird, findet ein Kontextwechsel zu dem Kontext des Objekt-Eigentümers statt.
– Wenn die Methode endet, wird der Kontext des Aufrufers wiederhergestellt.
– Ausnahmen-Handling wird verbessert, so dass der aktuell aktive Kontext während der Stack-Rahmen-Abwickelung, die sich ereignet, wenn eine Ausnahme ausgeworfen wird, korrekt wiederhergestellt wird.

6.2.7 Einholen gemeinsam benutzbarer Interface Objekte
Die Kommunikation zwischen Applets wird erreicht, wenn ein Client-Applet eine gemeinsam benutzbare Interface Methode eines einem Server-Applet gehörenden SIO aufruft. Damit dies funktioniert muss es eine Möglichkeit für das Client-Applet geben, das SIO vom Server-Applet einzuholen. Die JCRE bietet einen Mechanismus, um dies zu ermöglichen. Die Applet-Klasse und die JCSystem-Klasse stellen Verfahren zur Verfügung, mit denen ein Client Services vom Server abfragen kann.
6.2.7.1 Die Methode Applet.getShareableInterfaceObject
Diese Methode wird von der Server-Applet-Instanz implementiert. Sie wird. von der JCR: aufgerufen, um zwischen einem Client-Applet, das die Benützung eines Objekts, das einem anderen Applet gehört, verlangt, und dem Server-Applet, das seine Objekte zum Sharing verfügbar macht, zu vermitteln.
Das Standardverhalten gibt null aus, was darauf hinweist, dass ein Applet nicht an der Kommunikation zwischen Applets teilnimmt.
Ein Server-Applet, das von einem anderen Applet aufgerufen werden soll, muss diese Methode unterdrücken. Diese Methode muss die ClientAID und den parameter prüfen. Wenn die ClientAID nicht eine der erwarteten AIDs ist, muss die Methode null ausgeben. Auch wenn der parameter nicht erkannt wird oder für die ClientAID nicht zulässig ist, muss die Methode ebenfalls null ausgeben. Ansonsten muss das Applet ein SIO des Typs der gemeinsam benutzbaren Interface, den der Client verlangt hat, ausgeben.
Das Server-Applet muss nicht allen Clients mit der selben SIO antworten. Der Server kann mehrere Typen von gemeinsam benutzbaren Interfaces für unterschiedliche Zwecke unterstützen und ClientAID und parameter verwenden, um zu bestimmen, welche Art von SIO an den Client ausgegeben wird.
6.2.7.2 Die Methode JCSystem.getAppletShareableInterfaceObject
Die JCSystem-Klasse enthält die Methode getAppletShareableInterfaceObject, die von einem Client-Applet aufgerufen wird, um mit einem Server-Applet zu kommunizieren.
Die JCRE implementiert diese Methode so, dass sie sich wie folgt verhält:

1. Die JCRE durhsucht ihre interne Applet-Tabelle nach einem mit serverAID. Wird keines gefunden, wird null ausgegeben.
2. Die JCRE ruft die Methode getShareableInterfaceObject dieses Applets auf und gibt die clientAID des Aufrufers und den parameter weiter.
3. Ein Kontextwechsel findet am Server-Applet statt, und dessen Implementierung von getShareableInterfaceObjeCt läuft wie im vorigen Abschnitt beshrieben ab. Das Server-Applet gibt ein SIO (oder null) aus.
4. getAppletShareableInterfaceObjeCt gibt die selbe SIO (oder null) an seinen Aufrufer aus.

Für erhöhte Sicherheit ermöglicht die Implementierung dem Client, zu erkennen, welche der folgenden Bedingungen die Ausgabe eines Nullwerts verursacht hat:

– Die serverAID wurde nicht gefunden.
– Das Server-Applet nimmt an der Applet-internen Kommunikation nicht teil.
– Das Server-Aplet erkennt die ClientAID oder den parameter nicht.
– Das Server-Aplet kommuniziert mit diesem Client nicht.
– Das Server-Applet kommuniziert nicht mit diesem Client gemäß Spezifizierung durch den parameter.

6.2.8 Klassen- und Objektzugriffsverhalten.
Auf ein statisches Klassenfeld wird zugegriffen, wenn einer der folgenden Java Bytecodes ausgeführt wird:
getstatic, putstatic
Auf ein Objekt wird zugegriffen, wenn einer der folgenden Java Bytecodes unter Verwendung des Objektverweises ausgeführt wird:
getfield, putfield, invokevirtual, invokeinterface, athrow,
<T>aload, <T>astore, arraylength, checkcast, instanceof
<T> verweist auf die unterschiedlichen Typen von Array-Bytecodes, wie baload, sastore, usw.
Diese Liste enthält auch alle speziellen oder optimierten Formen dieser Bytecodes , die in der Java Card VM implementiert werden können, wie getfield_b, sgetfield_s_this, usw.
Vor der Erbringung der Arbeit des Bytecodes, wie von der Java VM spezifiziert, führt die Java Card VM eine Zugriffsprüfung am verwiesenen Objekt durch. Wird der Zugriff verweigert, dann wird eine SecurityException ausgeworfen.
Die von der Java Card VM durchgeführten Zugriffsprüfungen sind von Typ und Eigentümer des verwiesenen Objekts, dem Bytecode und dem aktuell aktiven Kontext abhängig. Diese werden in den folgenden Abschnitten beschrieben.
6.2.8.1 Zugriff auf statische Klassenfelder
Bytecodes:
getstatic, putstatic

– Wenn die JCRE der aktuell aktive Kontext ist, ist der Zugriff erlaubt.
– Ansonsten, wenn der Bytecode putstatic ist und das gespeicherte Feld ein Verweistyp und der gespeicherte Verweis ein Verweis auf ein temporärer JCRE Einsprungstellen-Objekt oder einen globalen Array, wird der Zugriff verweigert.
– Ansonsten ist der Zugriff erlaubt

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

– Wenn die JCRE; der aktuell aktive Kontext ist, ist der Zugriff erlaubt.
– Ansonsten, wenn der Bytecode aasfore und die gespeicherte Komponente ein Verweistyp ist und der gespeicherte Verweis ein Verweis auf ein temporäres JCRE-Einsprungstellen-Objekt oder einen globalem Array ist, dann wird der Zugriff verweigert.
– Ansonsten, wenn der Array dem aktuell aktiven Kontext gehört, ist der Zugriff erlaubt.
– Ansonsten, wenn der Array als global bezeichnet wird, ist der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.3 Zugriff auf Klasseninstanz-Objektfelder
Bytecodes:
getfield, putfield

– Wenn die JCRE der aktuell aktive Kontext ist, ist der Zugriff erlaubt.
– Ansonsten, wenn der Bytecode putfield und das gespeicherte Feld ein Verweistyp ist und der gespeicherte Verweis ein Verweis auf ein temporäres JCRE-Einsprungstellen-Objekt oder einen globalen Array ist, dann wird der Zugriff verweigert.
– Ansonsten, wenn das Objekt dem aktuell aktiven Kontext gehört, ist der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.4 Zugriff auf Klasseninstanz-Objektmethoden
Bytecodes:
invokevirtual

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt. Der Kontext wird auf den Kontext des Objekteigentümers gewechselt.
– Ansonsten, wenn das Objekt als JCRE-Einsprungstellenobjekt bezeichnet ist, wird der Zugriff erlaubt. Der Kontext wechselt auf den Kontext: des Objekteigentümers (wird JCRE sein).
– Ansonsten, wenn JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt. Der Kontext wechselt auf den Kontext des Objekteigentümers.
– Ansonsten wird der Zugriff verweigert.

6.2.8.5 Zugriff auf Standard-Interface-Methoden
Bytecodes:
invokeinterface

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt. Der Kontext wechselt zum Kontext des Objekteigentümers.
– Ansonsten wird der Zugriff verweigert.

6.2.8.6 Zugriff auf gemeinsam benutzbare Interface-Methoden
Bytecodes:
invokeinterface

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn die Klasse des Objekts eine Shareable Interface implementiert und wenn die aufgerufene Interface die Shareable Interface erweitert, wird der Zugriff erlaubt. Der Kontext wechselt auf den Kontext des Objekteigentümers.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt. Der Kontext wechselt zum Kontext des Objekteigentümers.
– Ansonsten wird der Zugriff verweigert.

6.2.8.7 Auswerfen von Ausnahme-Objekten
Bytecodes:
athrow

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn das Objekt als JCRE-Einsprungstellenobjekt bezeichnet ist, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.8 Zugriff auf Klasseninstanz-Objekte
Bytecodes:
checkcast, instanceof

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt.
– Ansonsten, wenn das Objekt als JCRE-Einsprungstellenobjekt bezeichnet ist, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaube.
– Ansonsten wird der Zugriff verweigert.

6.2.8.9 Zugriff auf Standard-Interfaces
Bytecodes:
checkcast, instanceof

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.2.8.10 Zugriff auf gemeinsam benutzbare Interfaces
Bytecodes:
checkcast, instanceof

– Wenn das Objekt dem aktuell aktiven Kontext gehört, wird der Zugriff erlaubt.
– Ansonsten, wenn die Klasse des Objekts eine Shareable Interface implementiert und wenn das Objekt zu einer Interface umgewandelt (checkcast) wird oder eine Instanz (instanceof) einer Interface ist, welche die Shareable Interface erweitert, wird der Zugriff erlaubt.
– Ansonsten, wenn die JCRE der aktuell aktive Kontext ist, wird der Zugriff erlaubt.
– Ansonsten wird der Zugriff verweigert.

6.3 Nicht residente Objekte und Applet-Kontexte
Nicht residente Objekte des Typs CLEAR_ON_RESET verhalten sich wie ständige Objekte, insofern auf sie nur zugegriffen werden kann, wenn der aktuell aktive Applet-Kontext der selbe ist wie der Eigentümer des Objekts (der aktuell aktive Applet-Kontext zum Erzeugungszeitpunkt des Objekts).
Nicht residente Objekte des Typs CLEAR_ON_DESELECT können nur erzeugt bzw. auf diese kann nur zugegriffen werden, wenn der aktuell aktive Applet-Kontext der aktuell ausgewählte Applet-Kontext ist. Wenn eine der makeTransient Fabrikmethoden aufgerufen wird, ein nicht residentes Objekt vom Typ CLEAR_ON_DESELECT zu erzeugen, wenn der aktuell aktive Applet-Kontext nicht der aktuell ausgewählte Applet-Kontext ist, so wirft die Methode eine SystemException mit dem Begründungscode ILLEGAL_TRANSIENT aus. Wenn ein Versuch unternommen wird, auf ein nicht residentes Objekt des Typs CLEAR ON DESELECT zuzugreifen, wenn der aktuell aktive Applet-Kontext nicht der aktuell ausgewählte Applet-Kontext ist, wirft die JCRE eine SecurityException aus.
Applets, die Teil des selben Pakets sind, haben den selben Gruppenkontext. Jede Applet-Instanz von einem Paket teilt alle ihre Objekt-Instanzen mit allen anderen Instanzen aus dem selben Paket. (Dies schließt nicht residente Objekte des Typs CLEAR ON RESET und CLEAR ON DESELECT im Eigentum dieser Applet-Instanzen ein.)
Die nicht residenten Objekte des Typs CLEAR ON DESELECT, die einer Applet-Instanz im selben Paket gehören, sind zugreifbar, wenn eine der Applet-Instanzen in diesem Paket das aktuell ausgewählte Applet ist.
Glossar
AID ist ein Akronym für Application IDentifier gemäß Definition in ISO 7816-5.
APDU ist ein Akronym für Application Protocol Data Unit gemäß Definition in ISO 7816-4.
API ist ein Akronym für Application Programming Interface. Die API definiert Aufrufkonventionen, mit denen ein Anwendungsprogramm auf das Betriebssystem und andere Dienste zugreift.
Applet bedeutet im Zusammenhang dieser Schrift ein Java Card Applet, welches in der Java-Card-Technologie die Grundeinheit für Auswahl, Kontext, Funktionalität und Sicherheit ist.
Applet-Entwickler bezieht sich auf eine Person, die mit Hilfe der Java Card Technologie-Spezifikationen ein Java Card Applet erzeugt.
Applet Firewall ist der Mechanismus in der Java-Card-Technologie, mit dem die VM ein Applet daran hindert, unzulässige Zugriffe auf Objekte vorzunehmen, die andern Applet-Kontexten oder dem JCRE-Kontext gehören, und mit dem die Verletzung berichtet oder sonstwie behandelt wird.
CAD ist ein Akronym für Card Acceptance Device (Kartenannahmegerät). Das CAD ist das Gerät, in das die Karte eingeführt wird.
Umwandeln (cast) bezeichnet die ausdrückliche Konvertierung von einem Datentyp zu einem anderen.
Klasse ist der Prototyp für ein Objekt in einer objektorientierten Sprache. Eine Klasse kann auch als Gruppe von Objekten betrachtet werden, die eine gemeinsame Struktur und ein gemeinsames Verhalten aufweisen. Die Struktur einer Klasse wird festgelegt durch die Klassen-Variablen, die den Zustand eines Objekts dieser Klasse darstellen, und das Verhalten ist durch eine Gruppe von Methoden gegeben, die mit der Klasse assoziiiert sind.
Klassen stehen in einer Klassenhierarchie. Eine Klasse kann eine Spezialisierung (eine Unterklasse) einer anderen (ihrer Oberklasse) sein, sie kann einen Verweis auf andere Klassen haben und andere Klassen in einer Client-Server-Beziehugn benützen.
Kontext (Vgl. Applet-Ausführungskontext).
Aktuell aktiver Kontext. Die JCRE kontrolliert den aktuell aktiven Java: Card Applet Kontext. Wenn eine virtuelle Methode zu einem Objekt aufgerufen wird und ein Kontextwechsel verlangt und erlaubt ist, ändert sich der aktuell aktive Kontext, so dass er einem Applet-Kontext entspricht, der das Objekt besitzt. Wenn diese Methode zurückkehrt, wird der vorhergehende Kontext wiederhergestellt. Aufrufe statischer Methoden haben keine Auswirkung auf den aktuell aktiven Kontext. Der aktuell aktive Kontext und Sharing-Status eines Objekts bestimmen gemeinsam, ob ein Zugriff auf ein Objekt zulässig ist.
Aktuell ausgewähltes Applet. Die JCRE kontrolliert das aktuell ausgewählte Java Card Applet. Nach Empfang eines SELECT-Kommandos mit der AID dieses Applets macht die JCRE dieses Applet zum aktuell ausgewählten Applet. Die JCRE sendet alle APDU-Kommandos zu dem aktuell ausgewählten Applet.
Firewall (vgl. Applet Firewall).
Framework ist die Gruppe von Klassen, die die API implementieren. Dazu gehören Kern- und Erweiterungspakete. Zu den Aufgaben gehören das Versenden von APDUs, Applet-Auswahl, Atomizitäts-Verwaltung und die Installation von Applets.
Instanz-Variable, auch bekannt als Felder, repräsentieren einen Teil des inneren Zustands eines Objekts. Jedes Objekt hat seine eigene Gruppe von Instanz-Variablen. Objekte der selben Klasse haben die selben Instanz-Variablen, doch jedes Objekt kann unterschiedliche Werte haben.
Instanzbildung bedeutet in objektorientierter Programmierung die Produktion eines bestimmten Objekts aus seiner Klassenschablone. Dies inkludiert die Zuteilung einer Datenstruktur mit den von der Schablone vorgegebenen Typen und die Initialisierung von Instanz-Variablen mit Standardwerten oder solchen, die durch die Konstruktorfunktion der Klasse vorgegeben sind.
Java Card Runtime Environment (JCRE – Java Card Laufzeitumgebung) besteht aus der Java Card Virtuellen Maschine, dem Rahmenwerk und den assoziierten nativen Methoden.
JC21RI ist ein Akronym für die Java Card 2.1 Verweis-Implementierung.
JCRE Implementierer bezeichnet eine Person, die unter Verwendung der Java Card API eine Anbieter-spezifische Implementierung realisiert.
JCVM ist ein Akronym für die Java Card Virtuelle Maschine. Die JCVM ist die Grundlage der OP-Kartenarchitektur. Die JCVM führt Bytecode aus und verwaltet Klassen und Objekte. Sie realisiert die Trennung zwischen Anwendungen (Firewalls) und ermöglicht ein sicheres Daten-Sharing.
JDK ist ein Akronym für Java Development Kit. Das JDK ist ein Produkt der Sun Microsystems Inc., das die Umgebung bereitstellt, die zur Programmierung in Java nötig ist. Das JDK ist für mehrere Plattformen verfügbar, vornehmlich aber für Sun Solaris und Microsoft Windows® Methode ist die Bezeichnung für ein mit einer oder mehr Klassen assoziiertes Verfahren oder eine Routine in objektorientierten Sprachen.
Namenstelle ist eine Gruppe von Namen, in der alle Namen eindeutig sind.
Objektorientiert ist eine Programmierungsmethode auf Basis von Objekten, bei denen es sich um eine Datenstruktur handelt, die in einer Gruppe von Routinen, sogenannten Methoden, die mit den Daten arbeiten, eingekapselt ist.
Objekte sind in objektorientierter Programmierung die eindeutigen Instanzen einer Datenstruktur, die gemäß der von ihrer Klasse bereitgestellten Schablone definiert ist. Jedes Objekt hat seine eigenen Werte für die Variablen, die zu seiner Klasse gehören, und kann auf die von seiner Klasse definierten Mitteilungen (Methoden) reagieren.
Paket ist eine Namenstelle in der Java Programmiersprache, die Klassen und Interfaces haben kann. Ein Paket (Package) ist die kleinste Einheit in der Java Programmiersprache.
Shareable Interface (gemeinsam benutzbares Interface) definiert eine Gruppe gemeinsam benützter Interface-Methoden. Diese Interface-Methoden können von einem Applet-Kontext abgerufen werden, wenn das sie implementierende Objekt einem anderen Applet-Kontext gehört.
Shareable Interface Object (SIO - gemeinsam benutzbares Interface-Objekt) - Ein Objekt, das das gemeinsam benutzbare Interface implementiert.

Claims

Verfahren zum Betrieb eines Geräts mit kleinem Platzbedarf (400), das eine Verarbeitungsmaschine (410) umfasst, wobei Programmmodule auf der Verarbeitungsmaschine ausgeführt werden, das Verfahren umfassend: Ausführen von Gruppen von einem oder mehreren Programmmodulen in separaten Kontexten (420, 620; 760, 770, 780; 1000, 1010, 1020), Bereitstellen einer Kontextsperre (600; 600') zum Trennen und Isolieren der Kontexte und zum Steuern des Zugriffs eines Programmmoduls, das in einem Kontext ausgeführt wird, auf Informationen und/oder ein Programmmodul, das in einem anderen Kontext ausgeführt wird, und Bereitstellen eines privilegierten Kontextes (760), der seinen Programmmodulen unbeschränkten Zugriff auf Informationen und Programmmodule der anderen Kontexte erlaubt.
Verfahren nach Anspruch 1, wobei das Steuern des Weiteren das Verhindern des Zugriffs, wenn der Zugriff nicht autorisiert ist, und das Ermöglichen des Zugriffs, wenn der Zugriff autorisiert ist, umfasst.
Verfahren nach. Anspruch 2, wobei die Autorisierung des Zugriffs mindestens eine Sicherheitsprüfung umfasst.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 3, wobei das Verfahren des Weiteren das Zuordnen jeweiliger separater Namensstellen für jeden Kontext umfasst.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 3, wobei das Verfahren des Weiteren das Zuordnen jeweiliger Specherstellen für jeden Kontext umfasst.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 5, wobei die Verarbeitungsmaschine (410) eine virtuelle Maschine (720) umfasst, die auf einem Prozessor (300) läuft.
Verfahren nach einem der vorhergehenden Ansprüche 1 bis 6, wobei wenigtens ein Teil des Programms objektorientiert ist.
Computerprogrammprodukt, das ein Programm von Befehlen für den Betrieb eines Geräts mit kleinem Platzbedarf (400) gemäss einem der Verfahrensansprüche 1 bis 7 enthält.
Gerät mit kleinem Platzbedarf (400), das eine Verarbeitungsmaschine (410) umfasst, wobei Programmmodule auf der Verarbeitungsmaschine ausgeführt werden, das Gerät mit kleinem Platzbedarf (400) umfassend: Mittel zum Ausführen von Gruppen von einem oder mehreren Programmmodulen in separaten Kontexten (420, 620; 760, 770, 780; 1000, 1010, 1020), eine Kontextsperre (600; 600') zum Trennen und Isolieren der Kontexte, dadurch gekennzeichnet, dass die Kontextsperre (600; 600') weiter den Zugriff eines Programmmodul, das in einem Kontext ausgeführt wird, auf Informationen und/oder ein Programmmodul steuert, das in einem anderen Kontext ausgeführt wird, und dass das Gerät mit kleinem Platzbedarf (400) weiter einen privilegierten Kontext (760) umfasst, der seinen Programmmodulen unbeschränkten Zugriff auf Informationen und Programmmodule der anderen Kontexte erlaubt.
Gerät mit kleinem Platzbedarf nach Anspruch 9, wobei die Kontextbarriere des weiteren Mittel für das Verhindern des Zugriffs, wenn der Zugriff nicht autorisiert ist, und das Ermöglichen des Zugriffs, wenn der Zugriff autorisiert ist, umfasst.
Verfahren nach Anspruch 10, wobei die Autorisierung des Zugriffs mindestens eine Sicherheitsprüfung umfasst.
Gerät mit kleinem Platzbedarf nach einem der vorhergehenden Ansprüche 9 bis 11, wobei das Gerät des Weiteren Mittel für das Zuordnen jeweiliger separater Namenstellen für jeden Kontext umfasst.
Gerät mit kleinem Platzbedarf nach einem der vorhergehenden Ansprüche 9 bis 12, wobei das Gerät des Weiteren Mittel für das Zuordnen jeweiliger Speicherstellen für jeden Kontext umfasst.
Gerät mit kleinem Platzbedarf nach einem der vorhergehenden Ansprüche 9 bis 13, wobei die Verarbeitungsmaschine (410) eine virtuelle Maschine (720) umfasst, die auf einem Prozessor (300) läuft.
Gerät mit kleinem Platzbedarf nach einem der vorhergehenden Ansprüche 9 bis 14, wobei wenigstens ein Teil des Programms objektorientiert ist.
Verwendung eines Netzwerks zur Übertragung von Code von einem Server über eine Kommunikationsverbindung, wobei der Code Anweisungen zum Betrieb eines Geräts mit kleinem Platzbedarf (400) gemäss einem der Verfahrensansprüche 1 bis 7 umfasst.