DE60011615T3 - Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen - Google Patents

Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen Download PDF

Info

Publication number
DE60011615T3
DE60011615T3 DE60011615.8T DE60011615T DE60011615T3 DE 60011615 T3 DE60011615 T3 DE 60011615T3 DE 60011615 T DE60011615 T DE 60011615T DE 60011615 T3 DE60011615 T3 DE 60011615T3
Authority
DE
Germany
Prior art keywords
applet
context
jcre
access
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60011615.8T
Other languages
English (en)
Other versions
DE60011615D1 (de
DE60011615T2 (de
Inventor
Joshua Susser
Mitchel Butler
Andy Streich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle America Inc
Original Assignee
Oracle America Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=22884324&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE60011615(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Oracle America Inc filed Critical Oracle America Inc
Publication of DE60011615D1 publication Critical patent/DE60011615D1/de
Publication of DE60011615T2 publication Critical patent/DE60011615T2/de
Application granted granted Critical
Publication of DE60011615T3 publication Critical patent/DE60011615T3/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Burglar Alarm Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)
  • Radar Systems Or Details Thereof (AREA)

Description

  • VERWEISE AUF BEZOGENE ANMELDUNGEN
  • Diese Anmeldung ist auf das Dokument US-A-6 092 147 bezogen, das den Titel ”VIRTUAL MACHINE WITH SECURELY DISTRIBUTED BYTE CODE VERIFICATION” (”VIRTUELLE MASCHINE MIT SICHER VERTEILTER BYTECODEPRÜFUNG) trägt, und die Erfinder heißen Moshe Levy und Judy Schwabe.
  • Diese Anmeldung ist auf das Dokument EP-A-1 155 365 bezogen, das den Titel ”VERFAHREN ZUR DURCHFÜHRUNG VON SICHERHEIT IN EINEM KLEINGERÄT UNTER VERWENDUNG VON EINER KONTEXTSPERRE” trägt, und die Erfinder heißen Joshua Susser, Mitchel B. Butler und Andy Streich.
  • Diese Anmeldung ist auf das Dokument EP-A-1 155 366 bezogen, das den Titel ”TECHNIKEN ZUM GEWÄHREN DES ZUGRIFFS DURCH EINE KONTEXTSPERRE IN EINEM GERÄT MIT KLEINEM PLATZBEDARF UNTER VERWENDUNG VON EINEM EINGANGSPUNKTOBJEKT” trägt, und die Erfinder heißen Joshua Susser, Mitchel B. Butler und Andy Streich.
  • Diese Anmeldung ist auf das Dokument EP-A-1 163 579 bezogen, das den Titel ”TECHNIKEN ZUM GEWÄHREN DES ZUGRIFFS DURCH EINE KONTEXTSPERRE IN EINEM GERÄT MIT KLEINEM PLATZBEDARF UNTER VERWENDUNG VON LAUFZEITUMGEBUNGSPRIVILEGIEN” trägt, und die Erfinder heißen Joshua Susser, Mitchel B. Butler und Andy Streich.
  • Dieser Anmeldung ist auf das Dokument EP-A-1 151 378 bezogen, das den Titel ”TECHNIKEN ZUM GEWÄHREN DES ZUGRIFFS DURCH EINE KONTEXTSPERRE IN EINEM GERÄT MIT KLEINEM PLATZBEDARF UNTER VERWENDUNG VON GEMEINSAMEN OBJEKTSCHNITTSTELLEN” trägt, und die Erfinder heißen Joshua Susser, Mitchel B. Butler und Andy Streich.
  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die Erfindung bezieht sich auf die Computersicherheit und genauer gesagt auf Techniken zum Implementieren von Sicherheit 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 JavaTM-Sprache. Diese Sprache wird in dem Buch JavaTM Language Specification von James Gosling et al., veröffentlicht bei Addison-Wesley, beschrieben. Diese Veröffentlichung wird hier durch Verweisung in ihrer Gesamtheit einbezogen. Die JavaTM-Sprache ist besonders gut geeignet, auf einer virtuellen JavaTM-Maschine bzw. JavaTM Virtual Machine zu laufen. Eine derartige Maschine wird beschrieben in dem Buch JavaTM 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 Kommunikationen mit der Smart Card erreicht werden können. Typischer weise umfasst der Satz von Kontakten eine Stromversorgungsverbindung und eine Masse, ebenso wie einen Takteingang, einen Rückstelleingang und einen Datenanschluss, ü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 Kartenanschluss 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 Anschluss gegen den oberflächlichen Anschlussbereich 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.
  • Die Verwendung von Firewalls für das Trennen autorisierter von nichtautorisierten Benutzern ist in der Netzwerkumgebung wohlbekannt. Zum Beispiel, eine solche Firewall wird im Dokument US 2002169980 offenbart, das den Titel ”AUTHENTICATED FIREWALL TUNNELLING FRAMEWORK” (”BESTÄTIGTE RAHMENUMGEBUNG EINES FIREWALLS DURCH TUNNELWIRKUNG”) trägt, und der Erfinder heißt David Brownell.
  • Ein Teilsatz der vollständigen Leistungsmerkmale der JavaTM-Plattform ist für kleinformatige Geräte, wie z. B. Smart Cards, definiert worden. Dieser Teilsatz wird die Java CardTM-Plattform genannt. Die Verwendungen der Java CardTM-Plattform werden in den folgenden Veröffentlichungen beschrieben.
    JAVA CARDTM 2.0 – LANGUAGE SUBSET AND VIRTUAL MACHINE SPECIFICATION,
    JAVA CARDTM 2.1 – APPLICATION PROGRAMMING INTERFACES,
    JAVA CARDTM 2.0 – PROGRAMMING CONCEPTS,
    JAVA CARDTM APPLET DEVELOPER'S GUIDE.
  • Diese Veröffentlichungen werden hier durch Verweisung in ihrer Gesamtheit einbezogen.
  • 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. Ein Exemplar dieses Entwurfs wird hier durch Verweisung in seiner Gesamtheit einbezogen.
  • Die Idee eines Ausführungskontexts ist in der Computerwissenschaft wohlbekannt. Allgemein gesprochen stellt die Verwendung von mehreren Ausführungskontexten in einer Computerumgebung eine Möglichkeit bereit, unterschiedliche Programmmodule oder Prozesse voneinander zu trennen oder zu isolieren, so dass sie ohne unangemessene wechselseitige Störung unabhängig voneinander arbeiten können. Wechselwirkungen zwischen verschiedenen Kontexten, falls überhaupt vorhanden, sind gewollt, anstatt dass 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, dass eine Rechnerumgebung, die mehrere Ausführungskontexte bereitstellt, auch einen Mechanismus bereitstellen muss, 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 dass irgendein anderer Kontext der aktuelle Kontext wird, so spricht man davon, dass eine ”Kontextumschaltung” erfolgt. Es versteht sich für Fachleute auf diesem Gebiet, dass diese 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 ablaufen oder fehlschlagen, ohne andere Anwendungen oder Vorgänge in einem anderen Kontext zu beeinflussen.
  • Eine Ebene des Sicherheitsschutzes, welche durch die JavaTM-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 JavaTM-Umgebung irgendeinen Schaden anzurichten. In einer solchen Umgebung kommunizieren JavaTM-Applets nicht, sondern stattdessen hat jedes seinen eigenen Namensraum.
  • Einige Betriebssysteme für Smart Cards erlauben nicht die Ausführung von Kontexten in der Weise, dass 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 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, dass unterschiedliche Hersteller kleinformatiger Geräte unterschiedliche Betriebssysteme verwenden können. 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 sollen, wird die Sicherheit zu einem Faktor, 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, dass 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 Einrichtung 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.
  • KURZFASSUNG DER ERFINDUNG
  • Die 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 ein 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 einem 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 JavaTM-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 über 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 JavaTM-Sprache und -Plattform bereits bereitstellen.
  • Diese Mechanismen stellen einen Schutz beispielsweise gegen Sicherheitslöcher aufgrund von Programmierfehlern (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 verwendenden Applets).
  • Die Erfindung ist auch auf Computerprogrammprodukte gerichtet.
  • 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 ZEICHNUNGEN
  • 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 Flussdiagramm 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 Flussdiagramm 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 Flussdiagramm eines Sicherheitserzwingungsvorgangs ist, der einen Zugriff über eine Firewall hinweg erlaubt,
  • 17 das Flussdiagramm aus 16 mit Einzelheiten des Blockes 1620 zeigt,
  • 18 ein Flussdiagramm ist, welches eine beispielhafte Implementierung des Blockes 1629 aus 17 zeigt.
  • BEZEICHNUNGEN UND NOMENKLATUR
  • Die folgenden genauen Beschreibungen können im Zusammenhang mit Programmvorgängen präsentiert werden, 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 physische 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, dass 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 bei den hier beschriebenen Vorgängen, die Teil der vorliegenden Erfindung bilden, nicht erforderlich oder wünschenswert; die Vorgänge sind Maschinenvorgänge. Zweckmäßige Maschinen zum Ausführen der Vorgänge der vorliegenden Erfindung umfassen digitale Vielzweck- bzw. Allzweckrechner oder sonstige Rechnereinrichtungen.
  • Eine Vorrichtung zum Durchführen dieser Vorgänge kann speziell für den erforderlichen Zweck konstruiert sein oder sie kann aus einem Allzweck- oder Vielzweckcomputer bestehen, der gezielt aktiviert oder rekonfiguriert 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 geschrieben sind, oder es kann sich als bequemer herausstellen, eine besser spezialisierte Vorrichtung zu konstruieren, 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 wird ein unveröffentlichter Entwurf eines Dokuments beigefügt, das den Titel ”JAVA CARD RUNTIME ENVIRONMENT 2.1 SPECIFICATION” (”LAUFZEITUMGEBUNG VON JAVA CARD 2.1 BESCHREIBUNG) trägt. Dieser Entwurf eines Dokumentes, das eine weitere genaue Beschreibung spezieller Ausführungsformen der Erfindung bereitstellt, wird in seiner Gesamtheit als integrierter Teil der vorliegenden Erfindung einbezogen.
  • Auch wenn die erfinderischen 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 einem Netzwerk eine Vielzahl weiterer Rechnereinrichtungen, wie z. B. ein Server 210, verbunden. Es ist möglich, Daten und Software über das Netzwerk 200 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 von elektronischen Geschäfts- und sonstigen Anwendungen verwendet werden. Die Anweisungen und Daten, die verwendet werden, um Verarbeitungselemente der Kartenannahmeeinrichtung und der Smart Card zu steuern, können in einem flüchtigen oder nichtflü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 beispielsweise 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 Anschluss 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 physische) enthalten, die einen Ausführungskontext 420 ablaufen lassen. 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, an welchen 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 Daten passiv sind, ist eine 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 CardTM-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 physische 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 630, 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 X 636 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 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 CardTM-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 umfasst das Objektsystem 750 zum Verwalten der Objekte einer 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 Einschluss von Privilegien zur Erzeugung von Zugangspunktobjekten oder globalen Datenstrukturen und für den Zugriff auf Objekte in untergeordneten Kontexten 770 und 780.
  • Jedes Objekt ist einem bestimmten Kontext zugeordnet. Man sagt, dass 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 ihren 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 den Kopfdaten des Objektes aufzeichnet. 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 dieses Kontextes zuordnet.
  • 8 ist ein Flussdiagramm 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 dass sie über die Firewall durch den Zugangspunkt 920 hinweg stattfindet, so dass die Hauptfunktion 900 die Aktion 905 mit dem Objekt 910 ausführen kann, ungeachtet der Tatsache, dass 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, dass der Zugangspunkt 920 gemeinsam mit verhinderten Zugriffen, wie z. B. X 636 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, dass 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, dass es nunmehr der Kontext 620 wird, und der vorherige Wert der Einstellung des aktuellen Kontextes wird gespeichert, so dass 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 muss 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 auch einen weiteren Objektzugang 1090, der eine Aktion 1095 mit einem Objekt 1099 in demselben Ausführungskontext aufruft, 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 ihre Ausführung keine Kontextumschaltung erforderlich und geschieht deshalb auch nicht.
  • 11 ist ein Flussdiagramm eines Prozesses für das Gewähren eines Zugriffs durch eine Hauptfunktion in einem Kontext über eine Firewall hinweg in einen anderen Kontext hinein. Es gibt im Wesentlichen drei Schritte in diesem Prozess. 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 in Kontext 2 als gemeinsam verwendet bezeichneten 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 die 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 dass jeder Kontext, welcher dem Superkontext untergeordnet ist, mit dem Zugangspunktobjekt des Superkontextes kommunizieren kann. (Es versteht sich, dass 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, dass 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 einen 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 760 Zugriff auf den Kontext 780 über die Kontextbarriere hinweg erhalten, welche 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 einer 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 durch das Objekt 1210 selbst autorisiert ist, dies zu tun. Diese Autorisierung wird unten unter Bezug auf 18 weiter diskutiert.
  • Es versteht sich, dass eine virtuelle Maschine, die mit der Erfindung konsistent ist, eine Funktionalität über die früheren virtuellen Maschinen, wie z. B. die in der JavaTM 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 Prozess wird als nächstes unter Bezug auf die 16 bis 18 beschrieben. Man beachte, dass dies auf irgendeinen Ansatz anwendbar ist, um Zugriff über die Firewall hinweg zu gewähren, einschließlich der vier unter Bezug auf die obigen 12 bis 15 beschriebenen Ansätze, ohne jedoch hierauf beschränkt zu sein.
  • 16 ist ein Flussdiagramm 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 Flussdiagramm 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 Flussdiagramm, welches eine beispielhafte Implementierung des Blockes 1629 aus 17 für die Verwendung mit dem Zugriffsverfahren zeigt, welches in 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, dass 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, dass der Autorisierungstext in den Code des Objektes selbst einprogrammiert wird.
  • Als Einrichtungen bzw. Geräte im Kleinformat werden allgemein 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 erlegen wegen ihrer begrenzten Ressourcen der Implementierung von Sicherheitsmaßnahmen Einschränkungen auf. Wegen der Ressourceneinschränkungen muss in einer Implementierung einer virtuellen Maschine eine einzelne virtuelle oder physikalische Maschine verwendet werden, im Gegensatz zu einer Vielzahl virtueller Maschinen.
  • Während die JavaTM-Sprache und -Plattform für die Erfindung geeignet sind, wäre jede beliebige Sprache oder Plattform, die gewisse Eigenschaften hat, gut für die Implementierung der Erfindung geeignet. Diese charakteristischen Merkmale umfassen Typsicherheit, Zeigersicherheit, Objektorientierung, dynamische Verknüpfung und als Basis eine virtuelle 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, dass dies nur der Veranschaulichung und beispielhaften Darstellung dient und nicht als eine Einschränkung verstanden werden soll, wobei der Schutzumfang der vorliegenden Erfindung nur anhand der anhängenden Ansprüche und ihrer Äquivalente beschränkt ist.
  • JavaTM-CardTM-Laufzeitumgebung (JavaTM CardTM Runtime Environment, JCRE)
  • 2.1 Spezifikation
    • Entwurf 2 Sun Microsystems Inc. 901 San Antonio Road Palo Alto, CA 94303 USA 650 960-1300
    • Entwurf 2, 14. Dezember 1998 Copyright© 1998 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, CA 94303 USA
  • Alle Rechte vorbehalten. Das Copyright für dieses Dokument liegt bei Sun Microsystems, Inc. Sun Microsystems, Inc. (SUN) gewährt Ihnen hiermit ohne Berechnung eine nicht exklusive, nicht übertragbare, weltweite, eingeschränkte Lizenz (ohne das Recht, Unterlizenzen zu vergeben) auf der Grundlage der geistigen Eigentumsrechte von SUN, die für die Ausführung der JavaTM-CardTM-Laufzeitumgebung (JCRE) 2. Spezifikation (”Spezifikation”) unabdingbar sind, um die Spezifikation nur für Zwecke der internen Auswertung zu verwenden. Außer dieser eingeschränkten Lizenz erhalten Sie kein Recht, keinen Titel oder keine Beteiligung an der oder auf die Spezifikation und Sie haben nicht das Recht, die Spezifikation für Herstellungszwecke oder kommerzielle Anwendungen zu benutzen.
  • AUFLISTUNG EINGESCHRÄNKTER RECHTE
  • Gebrauch, Vervielfältigung oder Verbreitung durch die US-Regierung unterliegt den Beschränkungen von FAR 52.227-14(g)(2)(6/87) und FAR 52.227-19(6/87), oder DFAR 252.227-7015(b)(6/95) und DFAR 227.7202-1(a).
  • SUN bietet keine Zusicherungen oder Gewährleistungen bezüglich der Eignung der Software, weder ausdrücklich noch implizit, einschließlich, jedoch nicht beschränkt auf die implizierte Gewährleistung für Marktgängigkeit, Tauglichkeit für einen bestimmten Zweck oder Freiheit von Rechtsverletzungen. SUN haftet nicht für irgendwelche Schäden, die dem Lizenznehmer als eine Folge des Gebrauchs, der Änderung oder der Verteilung dieser Software oder ihrer Derivate entstehen.
  • WARENZEICHEN
  • Sun, das Sun-Logo, Sun Microsystems, JavaSoft, JavaBeans, JDK, Java, Java Card, HotJava, HotJava Views, Visual Java, Solaris, NEO, Joe, Netra, NFS, ONC, ONC+, Open Windows, PC-NFS, EmbeddedJava, PersonalJava, SNM, SunNet Manager, Solaris sunburst design, Solstice, SunCore, SolarNet, SunWeb, Sun Workstation, The Network Is The Computer, ToolTalk, Ultra, Ultracomputing, Ultraserver, Where The Network Is Going, Sun Workshop, XView, Java Workshop, das Java-Kaffeetassen-Logo und Visual Java sind Markenzeichen oder eingetragene Markenzeichen von Sun Microsystems Inc. in den Vereinigten Staaten und anderen Ländern.
  • Diese Veröffentlichung wird ”so, wie sie ist” ohne Gewährleistung irgendeiner Art, weder ausdrücklich noch implizit, einschließlich, jedoch nicht beschränkt auf die implizierte Gewährleistung für Marktgängigkeit, Tauglichkeit für einen bestimmten Zweck oder Freiheit von Rechtsverletzungen zur Verfügung gestellt.
  • Diese Publikation könnte technische Irrtümer bzw. Ungenauigkeiten oder typografische Fehler enthalten. Änderungen werden den vorliegenden Informationen regelmäßig hinzugefügt; diese Änderungen werden in neue Ausgaben der Publikation aufgenommen. Sun Microsystems Inc. kann Verbesserungen und/oder Änderungen an dem oder den Produkt(en) und/oder dem oder den Programm(en), die in dieser Publikation beschrieben sind, zu jeder Zeit vornehmen.
  • JavaTM-CardTM-Laufzeitumgebung (JCRE) 2.1 Spezifikation
  • Inhalt
    • Vorwort
    • 1. Einleitung
    • 2. Lebensdauer der virtuellen Maschine zu Java-Card
    • 3. Lebensdauer des Java-Card-Applets
    • 3.1 Die Methode install
    • 3.2 Die Methode select
    • 3.3 Die Methode process
    • 3.4 Die Methode deselect
    • 3.5 Verlust der Stromzufuhr und Rücksetzen
    • 4. Transiente Objekte
    • 4.1 Ereignisse, die transiente Objekte löschen
    • 5. Auswahl bzw. Selektion
    • 5.1 Das Default-Applet
    • 5.2 Verarbeitung des SELECT-Kommandos
    • 5.3 Verarbeitung eines Nicht-SELECT-Kommandos
    • 6. Applet-Isolierung und gemeinsame Objektverwendung
    • 6.1 Applet-Firewall
    • 6.1.1 Kontexte und Kontextumschaltung
    • 6.1.2 Objektbesitz
    • 6.1.3 Objektzugriff
    • 6.1.4 Firewallschutz
    • 6.1.5 Statische Felder und Methoden
    • 6.2 Objektzugriff über Kontexte hinweg
    • 6.2.1 JCRE-Zugangspunktobjekte
    • 6.2.2 Globale Arrays
    • 6.2.3 JCRE-Privilegien
    • 6.2.4 Gemeinsam verwendbare Schnittstellen
    • 6.2.5 Bestimmen des vorherigen Kontextes
    • 6.2.6. Einzelheiten der gemeinsam verwendbaren Schnittstelle
    • 6.2.7 Erhalten von gemeinsam verwendbaren Schnittstellenobjekten
    • 6.2.8 Objektzugriffsverhalten
    • 6.3 Transiente Objekte und Applet-Kontexte
    • 7. Transaktionen und Atomizität
    • 7.1 Atomizität
    • 7.2 Transaktionen
    • 7.3 Transaktionsdauer
    • 7.4 Verschachtelte Transaktionen
    • 7.5 Scheitern einer Transaktion wegen Herausziehen oder Rücksetzen
    • 7.6 Abbrechen einer Transaktion
    • 7.6.1 Programmtechnischer Abbruch
    • 7.6.2 Abbruch durch die JCRE
    • 7.6.3 Aufräum-Verantwortlichkeiten der JCRE
    • 7.7 Transiente Objekte
    • 7.8 Commit-Kapazität
    • 8. API-Themen
    • 8.1 Die APDU-Klasse
    • 8.1.1 T = 0-Spezifika für ausgehende Datenübertragung
    • 8.1.2 T = 1-Spezifika für ausgehende Datenübertragung
    • 8.2 Die Sicherheits- und Verschlüsselungspakete
    • 8.3 Die JCSystem-Klasse
    • 9. Themen der virtuellen Maschine
    • 9.1 Ressourcen-Fehler
    • 10. Applet-Installierer
    • 10.1 Der Installierer
    • 10.1.1 Installierer-Implementierung
    • 10.1.2 Installierer-AID
    • 10.1.3 Installierer-APDUs
    • 10.1.4 Installierer-Verhalten
    • 10.1.5 Installierer-Privilegien
    • 10.2 Das neu installierte Applet
    • 10.2.1 Installationsparameter
    • 11. API-Konstanten
  • VORWORT
  • Die JavaTM-CardTM-Technologie kombiniert einen Teil der Programmiersprache Java mit einer Laufzeitumgebung, die für Smart-Cards und verwandte eingebettete Einrichtungen mit kleinem Speicher optimiert ist. Das Ziel der Java-Card-Technologie ist es, viele der Vorteile der Java-Softwareprogrammierung in die ressourcenbeschränkte Welt der Smart-Cards zu bringen.
  • Dieses Dokument ist eine Spezifikation der Java-Card-Laufzeitumgebung (JCRE) 2.1. Ein Verkäufer einer Java-Card-fähigen Einrichtung liefert eine Implementierung der JCRE. Eine JCRE-Implementierung im Kontext dieser Spezifikation bezeichnet eine von einem Verkäufer stammende Implementierung der virtuellen Maschine (VM) zu Java-Card, der Anwendungsprogrammierschnittstelle (Application Programming Interface, API) von Java-Card oder anderer auf den Spezifikationen der Java-Card-Technologie basierender Komponenten. Eine Referenzimplementierung ist eine von Sun Microsystems Inc. hergestellte Implementierung. Für die Java-Card-Plattform geschriebene Applets werden als Java-Card-Applets bezeichnet.
  • Wer sollte diese Spezifikation verwenden?
  • Diese Spezifikation ist dafür gedacht, JCRE-Implementierer bei der Erstellung einer Implementierung, beim Entwickeln einer Spezifikation zur Erweiterung der Spezifikationen der Java-Card-Technologie oder beim Erstellen einer Erweiterung der Java-Card-Laufzeitumgebung (JCRE) zu unterstützen. Diese Spezifikation ist außerdem für Entwickler von Java-Card-Applets gedacht, die ein tieferes Verständnis der Spezifikationen der Java-Card-Technologie erlangen möchten.
  • Bevor Sie diese Spezifikation lesen
  • Bevor Sie diesen Führer lesen, sollten Sie mit der Programmiersprache Java, den Spezifikationen der Java-Card-Technologie und der Smart-Card-Technologie vertraut sein. Eine gute Quelle zum Vertrautwerden mit der Java-Technologie und der Java-Card-Technologie ist die Website von Sun Microsystems Inc. unter http://java.sun.com.
  • Wie ist diese Spezifikation aufgebaut
    • Kapitel 1 ”Der Anwendungsbereich und die Zuständigkeiten von JCRE” gibt einen Überblick der Dienste, die von einer JCRE-Implementierung gefordert werden.
    • Kapitel 2 ”Lebensdauer der virtuellen Maschine” definiert die Lebensdauer der virtuellen Maschine.
    • Kapitel 3 ”Applet-Lebensdauer” definiert die Lebensdauer eines Applets.
    • Kapitel 4 ”Transiente Objekte” bietet eine Übersicht über transiente Objekte.
    • Kapitel 5 ”Auswahl” beschreibt, wie die JCRE die Auswahl von Applets handhabt.
    • Kapitel 6 ”Applet-Isolierung und gemeinsame Objektnutzung” beschreibt die Applet-Isolierung und die gemeinsame Objektnutzung.
    • Kapitel 7 ”Transaktionen und Atomizität” bietet eine Übersicht über die Atomizität (Unteilbarkeit) während Transaktionen.
    • Kapitel 8 ”API-Themen” beschreibt die API-Funktionalität, die von einer JCRE gefordert wird, jedoch nicht vollständig in der Java-Card 2.1 API-Spezifikation spezifiziert ist.
    • Kapitel 9 ”Themen zur virtuellen Maschine” beschreibt spezielle Eigenschaften der virtuellen Maschine.
    • Kapitel 10 ”Applet-Installierer” bietet eine Übersicht über den Applet-Installierer.
    • Kapitel 11 ”API-Konstanten” liefert die numerischen Werte von Konstanten, die nicht in der Java-Card 2.1 API-Spezifikation angegeben sind.
  • Das Glossar ist eine Liste von Wörtern und ihrer Definitionen, um Sie bei der Verwendung dieses Buches zu unterstützen.
  • Verwandte Dokumente und Publikationen
  • In diesem Handbuch wird auf verschiedene Dokumente oder Produkte Bezug genommen. Sie sollten die folgenden Dokumente verfügbar haben:
    • • Java Card 2.1 API Draft 2 Specification, Sun Microsystems Inc.
    • • Java Card 2.0 Language Subset and Virtual Machine Specification, October 13, 1997, Revision 1.0 Final, Sun Microsystems Inc.
    • • Java Card Applet Developer's Guide, Sun Microsystems Inc.
    • • The Java Language Specification von James Gosling, Bill Joy und Guy L. Steele. Addison-Wesley, 1996, ISBN 0-201-63451-1.
    • • The Java Virtual Machine Specification (Java-Reihe) von Tim Lindholm und Frank Yellin. Addison-Wesley, 1996, ISBN 0-201-63452-X.
    • • The Java Class Libraries: An Annotated Reference (Java-Reihe) von Patrick Chan und Rosanna Lee. Addison-Wesley, zwei Bände, ISBN 0201310023 und 0201310031.
    • • ISO 7816 Spezifikation, Teile 1–6.
    • • EMV '96 Integrated Circuit Card Specification for Payment Systems.
  • 1. EINLEITUNG
  • Die Java-Card-Laufzeitumgebung (JCRE) 2.1 enthält die virtuelle Maschine (VM) zu Java-Card, die Java-Card-Anwendungsprogrammierschnittstelle-(API)-Klassen (und industriespezifische Erweiterungen) und Unterstützungsdienste.
  • Dieses Dokument, die Spezifikation von JCRE 2.1, spezifiziert die JCRE-Funktionalität, die von der Java-Card-Technologie gefordert wird. Jede Implementierung der Java-Card-Technologie soll dieses notwendige Verhalten und diese notwendige Umgebung bereitstellen.
  • 2. LEBENSDAUER DER VIRTUELLEN MASCHINE ZU JAVA-CARD
  • In einem PC oder einer Workstation läuft die virtuelle Maschine von Java als Prozess des Betriebssystems (OS). Wenn der OS-Prozess beendet wird, werden die Java-Anwendungen und ihre Objekte automatisch zerstört.
  • In der Java-Card-Technologie ist die Ausführungslebensdauer der virtuellen Maschine (VM) die Lebensdauer der Karte. Der größte Teil der Information, die auf einer Karte gespeichert ist, soll sogar dann erhalten bleiben, wenn die Stromzufuhr von der Karte entfernt wird. Persistente Speichertechnologie (wie EEPROM) versetzt eine Smart-Card in die Lage, Information zu speichern, wenn die Stromzufuhr entfernt wird. Da die VM und die auf der Karte erzeugten Objekte verwendet werden, um Anwendungsinformation zu repräsentieren, die persistent (dauerhaft) ist, scheint die Java-Card-VM für immer zu laufen. Wenn die Stromzufuhr entfernt wird, hält die VM nur vorübergehend an. Wenn die Karte das nächste Mal zurückgesetzt wird, fängt die VM wieder an und stellt ihre vorige Objektmenge aus dem persistenten Speicher wieder her.
  • Neben ihrem persistenten Wesen verhält sich die virtuelle Maschine von Java-Card genau wie die virtuelle Maschine von Java.
  • Der Initialisierungszeitpunkt der Karte ist der Zeitpunkt nach dem Maskieren und vor dem Zeitpunkt der Personalisierung und Ausgabe der Karte. Zum Initialisierungszeitpunkt wird die JCRE initialisiert. Die Objekte der Struktur, die von der JCRE erstellt werden, existieren während der Lebensdauer der virtuellen Maschine. Da die Ausführungslebensdauer der virtuellen Maschine und die JCRE-Struktur CAD-Sessions der Karte überdauern, überdauert die Lebensdauer von Objekten, die von Applets erzeugt werden, auch die CAD-Sessions. (CAD bedeutet Card Acceptance Device oder Kartenleser. Karten-Sessions sind die Perioden, in denen die Karte in das CAD eingesetzt wird, mit Strom versorgt wird und Ströme von APDUs mit dem CAD austauscht. Die Karten-Session endet, wenn die Karte aus dem CAD genommen wird.) Objekte, die diese Eigenschaft haben, werden persistente Objekte genannt.
  • Der JCRE-Implementierer soll ein Objekt persistent machen, wenn:
    • • Die Methode Applet.register aufgerufen wird. Die JCRE speichert eine Referenz auf die Instanz des Applet-Objektes. Der JCRE-Implementierer soll sicherstellen, dass Instanzen der Klasse applet persistent sind.
    • • Eine Referenz auf ein Objekt in einem Feld von irgendwelchen anderen persistenten Objekten oder in einem statischen Feld einer Klasse gespeichert wird. Diese Anforderung rührt von der Notwendigkeit her, die Integrität der internen Datenstrukturen der JCRE zu bewahren.
  • 3. LEBENSDAUER VON JAVA-CARD-APPLETS
  • Für die Zwecke dieser Spezifikation beginnt die Lebensdauer eines Java-Card-Applets an dem Punkt, an dem es korrekt in den Kartenspeicher geladen, verbunden und anderweitig für die Ausführung vorbereitet wurde. (Für den Rest dieser Spezifikation bezieht sich Applet auf ein Applet, das für die Java-Card-Plattform geschrieben ist.) Applets, die mit der Methode Applet.register registriert werden, existieren für die Lebensdauer der Karte. Die JCRE interagiert mit dem Applet über die öffentlichen Methoden install, select, deselect und process des Applet. Ein Applet soll die statische install-Methode implementieren. Wenn die install-Methode nicht implementiert ist, können Objekte des Applets nicht erzeugt oder initialisiert werden. Eine JCRE-Implementierung soll die Methoden install, select, deselect und process eines Applets wie unten beschrieben aufrufen.
  • Wenn das Applet auf der Smart-Card installiert ist, wird die statische install-Methode von der JCRE einmal für jede erzeugte Applet-Instanz aufgerufen. Die JCRE soll den Konstruktor des Applets nicht direkt aufrufen.
  • 3.1 Die Methode install
  • Wenn install aufgerufen wird, existieren keine Objekte des Applets. Die Hauptaufgabe der install-Methode in dem Applet ist, eine Instanz der Klasse Applet zu erzeugen und die Instanz zu registrieren. Alle anderen Objekte, die das Applet während seiner Lebensdauer benötigt, können erzeugt werden, wie es passend ist. Irgendwelche anderen Vorbereitungen, die notwendig sind, um das Applet auszuwählen und auf das Applet von einem CAD zuzugreifen, können außerdem vorgenommen werden, wie es passend ist. Die install-Methode erhält Initialisierungsparameter aus den Inhalten des ankommenden Byte-Array-Parameters.
  • Typischerweise erzeugt ein Applet verschiedene Objekte, initialisiert sie mit vordefinierten Werten, setzt einige interne Zustandsvariablen und ruft die Methode Applet.register auf, um dem AID (Applet-IDentifier wie in ISO 7816-5 definiert) zu spezifizieren, der zu verwenden ist, um es auszuwählen. Diese Installation wird als erfolgreich betrachtet, wenn der Aufruf der Methode Applet.register ohne Ausnahmebedingung bzw. Exception abgeschlossen wird. Die Installation wird als nicht erfolgreich angenommen, wenn die install-Methode die Methode Applet.register nicht aufruft oder wenn eine Ausnahmebedingung von innerhalb der install-Methode ausgelöst wird, bevor die Methode Applet.register aufgerufen wird oder wenn die Methode Applet.register eine Ausnahmebedingung auslöst. Wenn die Installation nicht erfolgreich ist, soll die JCRE alle Aufräumarbeiten durchführen, wenn sie wieder die Kontrolle erhält. Das heißt, alle persistenten Objekte sollen in den Zustand zurückgebracht werden, in dem sie vor dem Aufruf der install-Methode waren. Wenn die Installation erfolgreich ist, kann die JCRE das Applet als zum Auswählen verfügbar markieren.
  • 3.2 Die Methode select
  • Applets bleiben in einem ausgesetzten bzw. suspendierten Zustand, bis sie explizit ausgewählt werden. Die Auswahl erfolgt, wenn die JCRE eine SELECT-APDU empfängt, in der die Namensdaten mit der AID des Applets übereinstimmen. Die Auswahl veranlasst, dass ein Applet zum aktuell ausgewählten Applet wird.
  • Vor dem Aufruf von SELECT soll die JCRE das zuvor ausgewählte Applet deselektieren. Die JCRE zeigt dies gegenüber dem Applet durch Aufruf der deselect-Methode des Applets an.
  • Die JCRE informiert das Applet über die Auswahl durch Aufrufen seiner select-Methode.
  • Das Applet kann es ablehnen, ausgewählt zu werden, indem es auf den Aufruf der select-Methode hin false zurückmeldet oder indem es eine Ausnahmebedingung auslöst. Wenn das Applet true zurückmeldet, wird das tatsächliche SELECT-APDU-Kommando dem Applet in dem anschließenden Aufruf seiner process-Methode übergeben, so dass das Applet die APDU-Inhalte überprüfen kann. Das Applet kann die SELECT-APDU genauso verarbeiten, wie es irgendein anderes APDU-Kommando verarbeitet. Es kann auf die SELECT-APDU mit Daten (siehe die process-Methode wegen Einzelheiten) antworten, oder es kann Fehler signalisieren, indem es eine ISOException mit dem geeigneten SW (zurückgeliefertes Statuswort) auslöst. Das SW und optionale Antwortdaten werden an das CAD zurückgegeben.
  • Die Methode Applet.selectingApplet soll wahr bzw. true zurückmelden, wenn sie während der select-Methode aufgerufen wird. Die Methode Applet.selectingApplet wird während der anschließenden process-Methode, die zum Verarbeiten des SELECT-APDU-Kommandos aufgerufen wird, weiterhin wahr (true) zurückmelden.
  • Wenn es das Applet ablehnt, ausgewählt zu werden, gibt die JCRE ein APDU-Antwort-Statuswort von ISO.SW_APPLET_SELECT_FAILED an das CAD zurück. Auf ein Scheitern der Auswahl hin wird der JCRE-Zustand so gesetzt, dass er anzeigt, dass kein Applet ausgewählt ist.
  • Nach erfolgreicher Auswahl werden alle nachfolgenden APDUs dem aktuell ausgewählten Applet mittels der process-Methode übergeben.
  • 3.3 Die Methode process
  • Alle APDUs werden von der JCRE empfangen, die eine Instanz der APDU-Klasse an die process-Methode des aktuell ausgewählten Applets übergibt.
  • Hinweis – Eine SELECT-APDU könnte eine Änderung des aktuell ausgewählten Applets vor dem Aufruf der process-Methode veranlassen.
  • Bei normaler Rückkehr hängt die JCRE automatisch 0x9000 als die Abschlussantwort-SW an jegliche bereits von dem Applet gesendeten Daten an.
  • Zu jeder Zeit während process kann das Applet eine ISOException mit einem geeigneten SW auslösen, wobei die JCRE in diesem Fall die Ausnahmebedingung entgegennimmt und das SW an das CAD zurückliefert.
  • Wenn irgendeine andere Ausnahmebedingung während process ausgelöst wird, nimmt die JCRE die Ausnahmebedingung entgegen und gibt das Statuswort IS07816.SW_UNKNOWN an das CAD zurück.
  • 3.4 Die Methode deselect
  • Wenn die JCRE ein SELECT-APDU-Kommando empfängt, in dem der Name mit der AID eines Applets übereinstimmt, ruft die JCRE die DESELECT-Methode des aktuell ausgewählten Applets auf. Dies ermöglicht es dem Applet, irgendwelche Aufräumoperationen durchzuführen, die notwendig sein können, um zu ermöglichen, dass ein anderes Applet ausgeführt wird.
  • Die Methode Applet.selectingApplet soll falsch zurückliefern, wenn sie während der deselect-Methode aufgerufen wird. Von der deselect-Methode ausgelöste Ausnahmebedingungen werden von der JCRE entgegengenommen, jedoch wird das Applet deselektiert.
  • 3.5 Verlust der Stromzufuhr und Rücksetzen
  • Verlust der Stromzufuhr tritt ein, wenn die Karte aus dem CAD gezogen wird oder wenn es irgendeinen anderen mechanischen oder elektrischen Ausfall gibt. Wenn der Karte wieder Strom zugeführt wird, und auf ein Kartenrücksetzen (warm oder kalt) hin, soll die JCRE sicherstellen, dass:
    • • transiente Daten auf ihren Defaultwert zurückgesetzt werden.
    • • die Transaktion, die im Gange war, als die Stromzufuhr verloren ging (oder das Rücksetzen erfolgte), falls es eine solche gibt, abgebrochen wird.
    • • das Applet, das ausgewählt war, als die Stromzufuhr verloren ging (oder das Rücksetzen erfolgte), implizit deselektiert wird. (In diesem Fall wird die deselect-Methode nicht aufgerufen.)
    • • wenn die JCRE die Default-Applet-Auswahl (siehe Absatz 5.1) implementiert, das Default-Applet als das aktuell ausgewählte Applet ausgewählt wird und dass die select-Methode des Default-Applets aufgerufen wird. Ansonsten setzt die JCRE ihren Zustand so, dass er anzeigt, dass kein Applet ausgewählt ist.
  • 4. TRANSIENTE OBJEKTE
  • Applets benötigen manchmal Objekte, die temporäre (transiente) Daten enthalten, die nicht über CAD-Sessions hinweg persistent zu sein brauchen. Java Card unterstützt nicht das Java-Schlüsselwort transient. Jedoch bietet die Java-Card-Technologie Methoden zum Anlegen transienter Arrays mit einfachen bzw. primitiven Komponenten oder Referenzen auf object.
  • Der Begriff ”transientes Objekt” ist eine falsche Bezeichnung. Er kann fälschlich so interpretiert werden, als würde er bedeuten, dass das Objekt selbst transient ist. Es sind jedoch nur die Inhalte der Felder des Objektes (außer dem Längenfeld) von transienter Natur. Wie bei jedem anderen Objekt in der Programmiersprache Java existieren transiente Objekte innerhalb der Java-Card-Plattform so lange, wie sie von:
    • • dem Stack
    • • lokalen Variablen
    • • einem statischen Feld einer Klasse
    • • einem Feld in einem anderen existierenden Objekt
    referenziert werden bzw. aufgerufen oder in Bezug genommen sind.
  • Ein transientes Objekt innerhalb der Java-Card-Plattform hat das folgende erforderliche Verhalten:
    • • Die Felder eines transienten Objektes sollen beim Eintreten bestimmter Ereignisse (siehe unten) auf den Standardwert des Feldes (Null, Falsch oder Nichts bzw. NULL) gelöscht werden.
    • • Aus Sicherheitsgründen sollen die Felder eines transienten Objektes niemals in einer ”persistenten Speichertechnologie” gespeichert werden. Unter Verwendung aktueller Smart-Card-Technologie als ein Beispiel können die Inhalte transienter Objekte in RAM, jedoch niemals in EEPROM gespeichert werden. Der Zweck dieser Anforderung ist, es möglich zu machen, dass transiente Objekte zum Speichern von Session-Schlüsseln verwendet werden.
    • • Schreibzugriffe auf die Felder eines transienten Objektes sollen keinen Durchsatznachteil haben. (Unter Verwendung aktueller Smart-Card-Technologie als ein Beispiel können die Inhalte transienter Objekte in RAM gespeichert werden, während die Inhalte nichttransienter Objekte in EEPROM gespeichert werden können. Typischerweise hat die RAM-Technologie eine viel schnellere Schreibzykluszeit als EEPROM.)
    • • Schreibzugriffe auf die Felder eines transienten Objektes sollen nicht durch ”Transaktionen” beeinflusst werden. Das heißt, eine abortTransaction wird nie veranlassen, dass ein Feld in einem transienten Objekt auf einen vorigen Wert zurückgesetzt wird.
  • Dieses Verhalten macht transiente Objekte ideal geeignet für kleine Mengen temporärer Applet-Daten, die häufig geändert werden, jedoch nicht über CAD- oder Auswahl-Sessions hinweg aufbewahrt zu werden brauchen.
  • 4.1 Ereignisse, die transiente Objekte löschen
  • Persistente Objekte werden zum Beibehalten von Zuständen verwendet, die über Rücksetzvorgänge der Karte hinweg erhalten werden sollen. Wenn ein transientes Objekt erzeugt wird, wird eines von zwei Ereignissen angegeben, das dazu führt, dass seine Felder gelöscht werden. Transiente Objekte mit CLEAR_ON_RESET werden zum Beibehalten von Zuständen verwendet, die über Applet-Auswahlen hinweg, jedoch nicht über Kartenrücksetzvorgänge hinweg erhalten werden sollen. Transiente Objekte mit CLEAR_ON_DESELECT werden zum Beibehalten von Zuständen verwendet, die erhalten werden müssen, wenn ein Applet ausgewählt wird, jedoch nicht über Applet-Auswahlen oder Kartenrücksetzvorgänge hinweg.
  • Die Einzelheiten der beiden Löschereignisse sind wie folgt:
    • • CLEAR_ON_RESET – die Felder eines Objektes werden gelöscht, wenn die Karte zurückgesetzt wird. Wenn die Stromzufuhr zu einer Karte einsetzt, verursacht das auch ein Rücksetzten der Karte.
  • Hinweis – Es ist nicht notwendig, die Felder transienter Objekte zu löschen, bevor die Stromzufuhr von der Karte weggenommen wird. Es ist jedoch notwendig, zu garantieren, dass die vorigen Inhalte solcher Felder nicht wiederhergestellt werden können, sobald die Stromzufuhr verloren gegangen ist.
    • • CLEAR_ON_DESELECT – die Felder eines Objektes werden gelöscht, wenn irgendein Applet deselektiert wird. Weil ein Rücksetzen der Karte implizit das aktuell ausgewählte Applet deselektiert, werden die Felder von CLEAR–ON–DESELECT-Objekten außerdem durch dieselben Ereignisse gelöscht, die für CLEAR_ON_RESET angegeben wurden.
  • Das aktuell ausgewählte Applet wird explizit nur dann deselektiert (seine deselect-Methode wird aufgerufen), wenn ein SELECT-Kommando verarbeitet wird. Das aktuell ausgewählte Applet wird deselektiert und danach werden die Felder aller transienten Objekte mit CLEAR–ON–DESELECT gelöscht, unabhängig davon, ob das SELECT-Kommando:
    • • dabeischeitert, ein Applet zu selektieren.
    • • ein anderes Applet auswählt.
    • • dasselbe Applet erneut auswählt.
  • 5. AUSWAHL BZW. SELEKTION
  • Karten empfangen Dienstanforderungen von dem CAD in der Form von APDUs. Die SELECT-APDU wird von der JCRE verwendet, um ein aktuell ausgewähltes Applet festzulegen. Sobald es selektiert ist, empfängt ein Applet alle nachfolgenden APDUs, bis das Applet deselektiert wird.
  • Es gibt kein aktuell ausgewähltes Applet, wenn eines der beiden Folgenden eintritt:
    • • Die Karte wird zurückgesetzt und kein Applet wurde als das Default-Applet vorab festgelegt.
    • • Ein SELECT-Kommando scheitert beim Versuch, ein Applet zu selektieren.
  • 5.1 Das Default-Applet
  • Normalerweise wird ein Applet nur mittels eines erfolgreichen SELECT-Kommandos ausgewählt. Einige Smart-Card-CAD-Anwendungen erfordern jedoch, dass es ein Default-Applet gibt, das implizit nach jedem Rücksetzen der Karte ausgewählt wird. Das Verhalten ist Folgendes:
    • 1. Nach einem Rücksetzen der Karte (oder Einschalten der Stromzufuhr, was eine Form von Rücksetzen ist) führt die JCRE ihre Initialisierungen und Überprüfungen durch, um zu sehen, ob ihr interner Zustand anzeigt, dass ein bestimmtes Applet das Default-Applet ist. Wenn dem so ist, macht die JCRE dieses Applet zum aktuell ausgewählten Applet, und die select-Methode des Applets wird aufgerufen. Wenn die select-Methode des Applets eine Ausnahmebedingung auslöst oder false zurückmeldet, dann setzt die JCRE ihren Zustand, um anzuzeigen, dass kein Applet selektiert ist. (Die process-Methode des Applets wird während der Selektion des Standard-Applet nicht aufgerufen, weil es keine SELECT-APDU gibt.) Wenn ein Standard-Applet beim Rücksetzen der Karte selektiert wird, soll es nicht erforderlich machen, dass seine process-Methode aufgerufen wird.
    • 2. Die JCRE stellt sicher, dass das ATR gesendet wurde und die Karte nun bereit ist, APDU-Kommandos anzunehmen.
  • Wenn ein Standard-Applet erfolgreich selektiert wurde, dann können APDU-Kommandos direkt an dieses Applet gesendet werden. Wenn kein Standard-Applet selektiert wurde, dann können nur SELECT-Kommandos verarbeitet werden.
  • Der Mechanismus zum Spezifizieren eines Default-Applets ist nicht in Java-Card-API 2.1 definiert. Er ist ein Detail einer JCRE-Implementierung und den individuellen JCRE-Implementierern überlassen.
  • 5.2 Verarbeitung des SELECT-Kommandos
  • Das SELECT-APDU-Kommando wird verwendet, um ein Applet auszuwählen. Sein Verhalten ist Folgendes:
    • 1. Die SELECT-APDU wird von der JCRE immer verarbeitet, unabhängig davon, welches Applet, falls überhaupt irgendeines, aktiv ist.
    • 2. Die JCRE durchsucht ihre interne Tabelle nach einer passenden AID. Die JCRE soll das Selektieren eines Applets unterstützen, wobei die vollständige AID in dem SELECT-Kommando vorhanden ist. Den JCRE-Implementierern ist es freigestellt, ihre JCRE zu verbessern, um andere Auswahlkriterien zu unterstützen. Als Beispiel dafür ist die Auswahl mittels partieller AID-Übereinstimmung wie in ISO 7816-4 spezifiziert. Die spezifischen Anforderungen sind folgendermaßen: Hinweis – Ein Stern zeigt binäre Bitnumerierung wie in ISO7816 an. Das höchstwertige Bit = b8. Das niederwertigste Bit = b1.
    • a) Das Applet-SELECT-Kommando verwendet CLA=0x00, INS=0xA4.
    • b) Das Applet-SELECT-Kommando verwendet ”Selektion durch DF-Name”. Daher ist P1=0x04.
    • c) Jeder andere Wert von P1 impliziert, dass es keine Applet-Auswahl ist. Die APDU wird durch das aktuell ausgewählte Applet verarbeitet.
    • d) Die JCRE soll genaue DF-Namen-(AID)-Auswahl unterstützen, d. h. P2=%b0000 xx00. (b4, b3* sind gleichgültig).
    • e) Alle anderen partiellen DF-Namen-SELECT-Optionen (b2, b1*) sind von der JCRE-Implementierung abhängig.
    • f) Alle Optionscodes der Dateisteuerinformation (b4, b3*) sollen von der JCRE unterstützt werden und von dem Applet interpretiert und verarbeitet werden.
    • 3. Wenn keine AID-Übereinstimmung gefunden wird:
    • a. Wenn es kein aktuell ausgewähltes Applet gibt, antwortet die JCRE auf das SELECT-Kommando mit dem Status-Code 0x6999 (SW_APPLET_SELECT_FAILED)
    • b. Ansonsten wird das SELECT-Kommando an die process-Methode des aktuell ausgewählten Applets weitergereicht. Eine Kontextumschaltung in den Kontext des Applets erfolgt zu diesem Zeitpunkt. (Der Applet-Kontext wird in Absatz 6.1.1 definiert.) Applets können das SELECT-APDU-Kommando für ihre eigene interne SELECT-Verarbeitung verwenden.
    • 4. Wenn eine passende AID gefunden wird, bereitet sich die JCRE vor, das neue Applet auszuwählen. Wenn es ein aktuell ausgewähltes Applet gibt, wird es durch einen Aufruf seiner deselect-Methode deselektiert. Eine Kontextumschaltung in den Kontext des deselektierten Applets erfolgt zu diesem Zeitpunkt. Der JCRE-Kontext wird beim Austritt aus dem deselect wieder hergestellt.
    • 5. Die JCRE setzt das neue aktuell ausgewählte Applet. Das neue Applet wird durch einen Aufruf seiner select-Methode ausgewählt, und es erfolgt eine Kontextumschaltung in den Kontext des neuen Applets.
    • a. Wenn die select-Methode des Applets eine Ausnahmebedingung auslöst oder falle zurückmeldet, dann wird der JCRE-Zustand so gesetzt, dass kein Applet ausgewählt ist. Die JCRE antwortet auf das SELECT-Kommando mit dem Status-Code 0x6999 (SW_APPLET_SELECT_FAILED).
    • b. Die process-Methode des neuen, aktuell ausgewählten Applets wird dann mit der SELECT-APDU als ein Eingabeparameter aufgerufen. Es erfolgt eine Kontextumschaltung in den Kontext des Applets.
  • Hinweise – Wenn es keine passende AID gibt, wird das SELECT-Kommando an das aktuell ausgewählte Applet (falls es eines gibt) wie ein normales Applet-APDU-Kommando zur Verarbeitung weitergereicht.
  • Wenn es eine passende AID gibt und das SELECT-Kommando scheitert, tritt die JCRE immer in den Zustand ein, in dem kein Applet selektiert ist.
  • Wenn die passende AID dieselbe wie das aktuell ausgewählte Applet ist, geht die JCRE immer noch durch den Vorgang des Deselektierens des Applets und dann des Selektierens desselben. Die erneute Auswahl könnte scheitern, was die Karte in einem Zustand lässt, in dem kein Applet selektiert ist.
  • 5.3 Verarbeitung eines Nicht-SELECT-Kommandos
  • Wenn eine Nicht-SELECT-APDU empfangen wird und es kein aktuell ausgewähltes Applet gibt, soll die JCRE auf die APDU mit dem Status-Code 0x6999 (SW_APPLET_SELECT_FAILED) antworten.
  • Wenn eine Nicht-SELECT-APDU empfangen wird und es ein aktuell ausgewähltes Applet gibt, ruft die JCRE die process-Methode des aktuell ausgewählten Applets auf und übergibt die APDU als einen Parameter. Dies verursacht eine Kontextumschaltung von dem JCRE-Kontext in den Kontext des aktuell ausgewählten Applets. Wenn die process-Methode beendet ist, schaltet die VM zurück in den JCRE-Kontext. Die JCRE sendet eine Antwort-APDU und wartet auf die nächste Kommando-APDU.
  • 6. APPLET-ISOLIERUNG UND GEMEINSAME OBJEKTVERWENDUNG
  • Jede Implementierung der JCRE soll die Isolation von Kontexten und Applets unterstützen. Isolation bedeutet, dass 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-Card-Technologie 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-Card-Applets. Die Java-Sprache stellt sicher, dass starke Typisierungs- und Schutzeigenschaften in Kraft sind.
  • Applet-Firewalls sind in der Java Card VM immer in Kraft. Sie erlauben es, dass die VM automatisch 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 getrennte 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 dass er Operationen ausführen kann, die für Applet-Kontexte abgelehnt werden.
  • Zu irgendeinem beliebigen Zeitpunkt gibt es nur einen aktiven Kontext innerhalb der VM. (Dieser wird der aktuell aktive Kontext genannt.) Alle Bytecodes, die auf Objekte zugreifen, werden während 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-Raum ab.
  • Die meisten Methodenaufrufe in der Java-Card-Technologie bewirken keine Kontextumschaltung. Kontextumschaltungen treten nur beim Aufruf von und bei der Rückkehr aus gewissen Methoden auf, ebenso wie während Ausnahme-Exits aus diesen Methoden (siehe 6.2.8).
  • Während eines Methodenaufrufs mit Kontextumschaltung wird ein zusätzlicher Teil von Daten, 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.1.1 geht von der Annahme aus, dass 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 instantiiert 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, dass auf ein Objekt von einem anderen Applet in einem anderen Kontext zugegriffen wird.
  • Im Hinblick auf die Implementierung wird jedes Mal 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 SecurityException vorgebracht.
  • Auf ein Objekt wird zugegriffen, wenn einer der folgenden Bytecodes unter Verwendung 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 umfasst 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 am häufigsten erwarteten Sicherheitsfall bereit: Entwicklungsfehler und das Übersehen von Fehlern in der Auslegung, die es möglicherweise erlauben, dass 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 die Sicherheit sicher.
  • 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, dass 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, bewusst 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, dass 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 reguläre Objekte. Sie sind im Besitz dessen, der sie erzeugt hat und es gelten die standardmäßigen Regeln des Firewallzugriffs. Wenn es notwendig ist, dass sie über mehrere Applet-Kontexte hinweg gemeinsam verwendet werden, dann müssen diese Objekte gemeinsam verwendbare Schnittstellenobjekte (SIOs) sein. (Siehe Paragraph 6.2.4 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, dass 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, wann Code grundlegende Beschränkungen der Sprache verletzt, wie z. B. Aufrufen einer privaten Methode in einer anderen Klasse und die Verletzung melden oder sonst wie angehen.
  • 6.2 Objektzugriff über Kontexte hinweg
  • Um es Applets zu ermöglichen, dass sie miteinander und mit der JCRE in Wechselwirkung treten, stehen einige wohldefinierte und dennoch sichere Mechanismen bereit, so dass 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 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, dass 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 erfasst und beschränkt Versuche, Referenzen auf diese Objekte zu speichern, als Teil der Firewall-Funktionalität, um 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 zeitweilig (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, dass auf sie von irgendeinem Applet-Kontext aus zugegriffen werden kann. Die Firewall würde normalerweise verhindern, dass diese Objekte in flexibler Weise verwendet werden. Die Java Card VM ermöglicht, dass ein Objekt als global bezeichnet wird.
  • Alle globalen Arrays sind zeitweilige 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 erfasst und beschränkt Versuche, Referenzen und Bezugnahmen auf diese Objekte zu speichern, 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, dass 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, dass 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, dass das Objekt X 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 Applet-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 immer entweder der aktuell aktive Kontext oder der unterste 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 das 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 des 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 verfü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 dass keines der Felder oder Methoden von O sichtbar ist.
    • 8. 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, dass auf die anderen Felder und Methoden von O 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 Stack aufbewahrt und der Kontext des Besitzers (A) des aktuellen Objekts (O) wird der neue aktuell 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 Felder und Methoden des Objekts O und irgendeines anderen im Besitz von A befindlichen Objektes zuzugreifen. Gleichzeitig verhindert die Firewall, dass 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üngliche 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, dass 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 die 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 getPreviousContextAID 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, auf welche 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, ob 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 muss, 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, dass 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 verwendbaren Schnittstellentyp umformt, falls erforderlich, und die Servicemethoden der Schnittstelle 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 dass 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 erreicht, wenn ein Client-Applet eine gemeinsam verwendbare Schnittstellenmethode eines SIO aufruft, welches zu einem Server-Applet gehört. Damit dies funktioniert, muss es für das Client-Applet eine Möglichkeit geben, das SIO von dem Server-Applet an erster Stelle zu erhalten. Die 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 durch einen Client 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 Null zurückliefern, was anzeigt, dass ein Applet nicht an der Kommunikation zwischen Applets teilnimmt.
  • Ein Server-Applet, welches von irgendeinem anderen Applet aufgerufen werden soll, muss diese Methode außer Kraft setzen. Diese Methode sollte die ClientAID und die Parameter untersuchen. Wenn die ClientAID nicht eine der erwarteten AIDs ist, so sollte die Methode Null liefern. In ähnlicher Weise sollte die Methode, wenn der Parameter nicht erkannt wird oder wenn er nicht für die ClientAID zugelassen wird, ebenfalls Null liefern. Ansonsten sollte das Applet ein SIO des gemeinsam verwendbaren Schnittstellentyps liefern, welchen der Client angefordert hat.
  • Das Server-Applet muss nicht auf alle Clients mit demselben SIO reagieren. Der Server kann mehrere Typen von gemeinsam verwendbaren Schnittstellen für unterschiedliche Zwecke unterstützen 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 einem Server-Applet zu kommunizieren.
  • Die JCRE soll diese Methode so implementieren, dass sie sich folgendermaßen verhält:
    • 1. Die JCRE durchsucht ihre interne Applet-Tabelle nach einem mit ServerAID. Falls sie ein solches nicht findet, so wird Null zurückgegeben.
    • 2. Die JCRE ruft die Methode getShareableInterfaceObject dieses Applets auf und leitet die ClientAID des Anrufers und den Parameter weiter.
    • 3. Eine Kontextumschaltung erfolgt zu dem Server-Applet und seine Implementierung von getShareableInterfaceObject läuft weiter, wie es in dem vorherigen Abschnitt beschrieben wurde. Das Server-Applet liefert ein SIO zurück (oder Null).
    • 4. getAppletShareableInterfaceObject liefert dasselbe SIO oder Null an ihren Anrufer.
  • Für eine verbesserte Sicherheit sollte die Implementierung es unmöglich machen, dass 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 die ClientAID oder den Parameter.
    • • Das Server-Applet kommuniziert nicht mit diesem Client.
    • • Das Server-Applet kommuniziert nicht mit diesem Client, wie es durch den 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 ausgeführt 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 umfasst 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 des referenzierten Objekts, 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 Feld, das gespeichert wird, 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 Referenz, die gespeichert wird, 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 Referenz, die gespeichert wird, 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 die 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 Einwerfen 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 wird (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 SecurityException 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 umfasst 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.
  • 7. Transaktionen und Atomizität
  • Eine Transaktion ist ein logischer Satz von Aktualisierungen persistenter Daten. Zum Beispiel ist das Überweisen eines Geldbetrages von einem Konto zu einem anderen eine Banktransaktion. Es ist wichtig, dass Transaktionen atomar (unteilbar) sind: entweder werden alle Datenfelder aktualisiert oder keines. Die JCRE bietet eine robuste Unterstützung für atomare Transaktionen, so dass Kartendaten in ihren ursprünglichen Zustand vor einer Transaktion zurückversetzt werden, wenn die Transaktion nicht normal zu Ende geht. Dieser Mechanismus schützt vor Ereignissen wie Stromausfall in der Mitte einer Transaktion und vor Programmfehlern, die Datenzerstörung verursachen könnten, sollten nicht alle Schritte einer Transaktion normal beendet werden.
  • 7.1 Atomizität
  • Atomizität definiert, wie die Karte die Inhalte des persistenten Speichers nach einem Anhalten, Ausfall oder einer schwerwiegenden Ausnahmebedingung während einer Aktualisierung eines einzelnen Objektes oder Klassenfeldes oder einer Arraykomponente behandelt. Wenn die Stromzufuhr während der Aktualisierung verloren geht, soll der Appletentwickler darauf vertrauen können, was das Feld oder die Arraykomponente enthält, wenn die Stromzufuhr wieder hergestellt wird.
  • Die Java-Card-Plattform garantiert, dass irgendeine Aktualisierung eines einzelnen, persistenten Objektes oder Klassenfeldes atomar ist. Darüber hinaus bietet die Java-Card-Plattform Atomizität auf der Stufe einzelner Komponenten für persistente Arrays. Das heißt, dass in dem Fall, dass die Smart-Card während der Aktualisierung eines Datenelementes (Feldes in einem Objekt/einer Klasse oder Komponente in einem Array), das über CAD-Sessions hinweg erhalten werden soll, die Stromzufuhr verliert, das Datenelement auf seinen vorigen Wert zurückgesetzt wird.
  • Einige Methoden garantieren auch Atomizität (Unteilbarkeit) für Blockaktualisierungen mehrerer Datenelemente. Zum Beispiel garantiert die Atomizität der Methode Uti.arrayCopy, dass entweder alle Bytes korrekt kopiert werden oder ansonsten das Zielarray auf seine vorigen Bytewerte zurückgesetzt wird.
  • Es könnte sein, dass ein Applet die Atomizität für Arrayaktualisierungen nicht bräuchte. Die Methode Util.arrayCopyNonAtomic ist für diesen Zweck vorgesehen. Sie verwendet nicht den Transaktions-Commit-Puffer, auch dann nicht, wenn sie aufgerufen wird, wenn eine Transaktion im Gange ist.
  • 7.2 Transaktionen
  • Für ein Applet könnte es nötig sein, einige unterschiedliche Felder oder Arraykomponenten in einigen unterschiedlichen Objekten atomar zu aktualisieren. Entweder finden alle Aktualisierungen korrekt und konsistent statt, oder alle Felder/Komponenten werden ansonsten auf ihre vorigen Werte zurückgesetzt.
  • Die Java-Card-Plattform unterstützt ein Transaktionsmodell, bei dem ein Applet den Beginn eines atomaren Satzes von Aktualisierungen mit dem Aufruf der Methode JCSystem.beginTransaction festlegen kann. Jede Aktualisierung eines Objektes nach diesem Zeitpunkt wird bedingt aktualisiert. Das Feld oder die Arraykomponente erscheint als aktualisiert – erneutes Lesen des Feldes/der Arraykomponente liefert seinen/ihren letzten, bedingten Wert – aber die Aktualisierung ist noch nicht mit Commit bestätigt.
  • Wenn das Applet JCSystem.commitTransaction aufruft, werden alle bedingten Aktualisierungen per Commit in persistente Speicherung übergeführt. Wenn die Stromzufuhr verloren geht oder irgendein anderer Systemfehler vor dem Abschluss von JCSystem.commitTransaction auftritt, werden alle bedingt aktualisierten Felder oder Arraykomponenten auf ihre vorherigen Werte zurückgesetzt. Wenn ein Applet auf ein internes Problem stößt oder sich entscheidet, die Transaktion zu widerrufen, kann es durch einen Aufruf von JCSystem.abortTransaction bedingte Aktualisierungen programmtechnisch rückgängig machen.
  • 7.3 Transaktionsdauer
  • Eine Transaktion endet immer dann, wenn die JCRE bei der Rückkehr von den select-, deselect-, process- oder install-Methoden eines Applets die programmtechnische Kontrolle zurückerhält. Dies gilt unabhängig davon, ob eine Transaktion normal, mit einem Aufruf von commitTransaction durch das Applet oder mit einem Abbruch der Transaktion (entweder programmtechnisch durch das Applet oder per Default durch die JCRE) beendet wird. Wegen weiterer Einzelheiten zum Transaktionsabbruch siehe Absatz 7.6.
  • Die Transaktionsdauer ist die Lebensdauer einer Transaktion zwischen dem Aufruf von JCSystem.beginTransaction und entweder einem Aufruf von commitTransaction oder einem Abbruch der Transaktion.
  • 7.4 Verschachtelte Transaktionen
  • Das Modell geht derzeit davon aus, dass verschachtelte Transaktionen nicht möglich sind. Es kann zu einem Zeitpunkt nur eine Transaktion im Gange sein. Wenn JCSystem.beginTransaction aufgerufen wird, während eine Transaktion bereits im Gange ist, dann wird eine TransactionException ausgelöst.
  • Die Methode JCSystem.transactionDepth ist vorgesehen, um zu ermöglichen festzustellen, ob eine Transaktion im Gange ist.
  • 7.5 Scheitern einer Transaktion wegen Herausziehen oder Rücksetzen
  • Wenn die Stromzufuhr verloren geht (Herausziehen) oder die Karte zurückgesetzt wird oder ein anderer Systemfehler auftritt, während eine Transaktion im Gange ist, dann soll die JCRE alle Felder und Arraykomponenten, die seit dem letzten Aufruf von JCSystem.beginTransaction bedingt aktualisiert wurden, auf ihre vorherigen Werte zurücksetzen.
  • Diese Aktion wird von der JCRE automatisch durchgeführt, wenn die Karte nach der Wiederherstellung nach dem Verlust der Stromzufuhr, nach einem Rücksetzen oder einem Fehler erneut initialisiert wird. Die JCRE stellt fest, welche dieser Objekte (falls überhaupt irgendeines) bedingt aktualisiert wurden und setzt sie zurück.
  • Hinweis – Objektraum, der von Instanzen verwendet wird, die während einer Transaktion erzeugt wurden, die wegen Verlust der Stromzufuhr oder eines Rücksetzens der Karte scheiterte, kann durch die JCRE wieder hergestellt werden.
  • 7.6 Abbrechen einer Transaktion
  • Transaktionen können entweder durch ein Applet oder durch die JCRE abgebrochen werden.
  • 7.6.1 Programmtechnischer Abbruch
  • Wenn ein Applet auf ein internes Problem stößt oder entscheidet, die Transaktion zu widerrufen bzw. zu streichen, kann es bedingte Aktualisierungen durch Aufruf von JCSystem.abortTransaction programmtechnisch rückgängig machen. Wenn diese Methode aufgerufen wird, werden alle seit dem vorangegangenen Aufruf von JCSystem.beginTransaction bedingt aktualisierten Felder und Arraykomponenten auf ihre vorherigen Werte zurückgesetzt und der Wert von JCSystem.transactionDepth wird auf 0 zurückgesetzt.
  • 7.6.2 Abbruch durch die JCRE
  • Wenn ein Applet von den select-, deselect-, process- oder install-Methoden zurückkehrt, wenn eine Transaktion im Gange ist, bricht die JCRE die Transaktion automatisch ab. Wenn eine Rückkehr von irgendeiner der select-, deselect-, process- oder install-Methoden auftritt, wenn eine Transaktion im Gange ist, verhält sich die JCRE so, als ob eine Ausnahmebedingung ausgelöst worden wäre.
  • 7.6.3 Aufräum-Verantwortlichkeiten der JCRE
  • Objektinstanzen, die während der Transaktion, die abgebrochen wird, erstellt wurden, können nur gelöscht werden, wenn alle Referenzen auf diese Objekte lokalisiert werden und zu null umgewandelt werden können. Die JCRE soll sicherstellen, dass Referenzen auf Objekte, die während der abgebrochenen Transaktion erzeugt wurden, äquivalent zu einer null-Referenz sind.
  • 7.7 Transiente Objekte
  • Nur Aktualisierungen persistenter Objekte nehmen an der Transaktion teil. Aktualisierungen transienter Objekte werden niemals zurückgenommen, unabhängig davon, ob sie ”innerhalb einer Transaktion” stattfanden oder nicht.
  • 7.8 Commit-Kapazität
  • Da die Ressourcen der Plattform begrenzt sind, ist die Anzahl von Bytes von bedingt aktualisierten Daten begrenzt, die während einer Transaktion gesammelt werden können. Die Java-Card-Technologie sieht Methoden vor, um festzustellen, wie viel Commit-Kapazität in der Implementierung verfügbar ist. Die Commit-Kapazität stellt eine obere Schranke der verfügbaren Anzahl von bedingten Byteaktualisierungen dar. Die tatsächliche Anzahl von verfügbaren, bedingten Byteaktualisierungen kann aufgrund von Verwaltungs-Overhead kleiner sein.
  • Es wird eine Ausnahmebedingung ausgelöst, wenn die Commit-Kapazität während einer Transaktion überschritten wird.
  • 8. API-Themen
  • Die Themen in diesem Kapitel ergänzen die in Java Card 2.1 API Draft 2 Specification spezifizierten Anforderungen. Das erste Thema ist die Java-Card-I/O-Funktionalität, die vollständig in der APDU-Klasse implementiert ist. Das zweite Thema ist die API, das Java-Card-Sicherheit und -Verschlüsselung unterstützt. Die Klasse JCSystem umfasst die Stufe der API-Version.
  • Transaktionen innerhalb der API
  • Außer wenn in der Java Card 2.1 API Specification speziell darauf hingewiesen wurde, soll die Implementierung der API-Klassen keine Transaktion einleiten oder anderweitig den Zustand einer Transaktion ändern, wenn eine im Gange ist.
  • Ressourcenverwendung innerhalb der API
  • Außer wenn in der Java Card 2.1 API Specification speziell darauf hingewiesen wurde, soll die Implementierung den Aufruf von API-Instanzmethoden unterstützen, auch dann, wenn der Besitzer der Objektinstanz nicht das aktuell selektierte Applet ist. Mit anderen Worten soll die Implementierung, außer wenn speziell darauf hingewiesen wurde, keine Ressourcen wie transiente Objekte von Typ CLEAR_ON_DESELECT verwenden.
  • Von API-Klassen ausgelöste Ausnahmebedingungen
  • Alle von der API-Implementierung ausgelösten Ausnahmebedingungsobjekte sollen temporäre JCRE-Eintrittspunkt- bzw. -Entry-Point-Objekte sein. Temporäre JCRE-Entry-Point-Objekte können nicht in Klassenvariablen, Instanzvariablen oder Arraykomponenten gespeichert werden. (Siehe 6.2.1)
  • 8.1 Die APDU-Klasse
  • Die APDU-Klasse umfasst den Zugriff auf die ISO 7816-4 basierte I/O über die serielle Leitung der Karte. Die APDU-Klasse ist dafür ausgelegt, unabhängig von dem darunterliegenden I/O-Transportprotokoll zu sein.
  • Die JCRE kann Transportprotokolle mit T = 0 oder T = 1 unterstützen oder beide.
  • 8.1.1 T = 0-Spezifika für ausgehende Datenübertragung
  • Zur Kompatibilität mit herkömmlichen CAD/Terminals, die keinen blockverketteten Mechanismus unterstützen, ermöglicht die APDU-Klasse eine Auswahl der Betriebsart mittels der setOutgoingNoChaining-Methode.
  • 8.1.1.1 Eingeschränkte Übertragungen ohne Verkettung
  • Wenn die Betriebsart der Ausgabeübertragung ohne Verkettung durch Aufruf der setOutgoingNoChaining-Methode vom Applet angefordert wird, soll die folgende Protokollsequenz befolgt werden.
  • Hinweis – wenn die Betriebsart ohne Verkettung verwendet wird, sollen Aufrufe der waitExtension-Methode eine APDUException mit Ursachencode ILLEGAL_USE auslösen.
  • Schreibweise
    • Le
      = vom CAD erwartete Länge.
      Lr
      = Antwortlänge des Applets, die über die setOutgoingLength-Methode eingestellt wird.
      <INS>
      = das Protokollbyte ist gleich dem INS-Byte des eintreffenden Headers, was anzeigt, dass alle Datenbytes als nächstes übertragen werden.
      <~INS>
      = das Protokollbyte, das das Komplement des INS-Byte des eintreffenden Headers ist, was anzeigt, dass ungefähr 1 Datenbyte als nächstes übertragen wird.
      <SW1, SW2>
      = die Antwort-Statusbytes wie in ISO 7816-4.
  • ISO 7816-4 Fall 2
  • Le = = Lr
    • 1. Die Karte sendet Lr Bytes ”von Ausgabedaten mittels des Bytemechanismus der Standardprozedur T = 0 mit <INS> oder <~INS>.
    • 2. Die Karte sendet <SW1, SW2> als Abschlussstatus beim Abschluss der Applet.process-Methode.
  • Lr < Le
    • 1. Die Karte sendet <0x61, Lr> Abschlussstatus-Bytes
    • 2. Das CAD sendet das Kommando GET RESPONSE mit Le = Lr.
    • 3. Die Karte sendet Lr Bytes an Ausgabedaten mittels des Bytemechanismus der Standardprozedur T = 0 mit <INS> oder <~INS>.
    • 4. Die Karte sendet <SW1, SW2> als Abschlussstatus beim Abschluss der Applet.process-Methode.
  • Lr > Le
    • 1. Die Karte sendet Le Bytes an Ausgabedaten mittels des Bytemechanismus der Standardprozedur T = 0 mit <INS> oder
    • 2. Die Karte sendet <0x61, (Lr-Le)> Abschlussstatus-Bytes
    • 3. Das CAD sendet das Kommando GET RESPONSE mit neuer Le <= Lr.
    • 4. Die Karte sendet (neue) Le Bytes an Ausgabedaten mittels des Bytemechanismus der Standardprozedur T = 0 mit <INS> oder <~INS>.
    • 5. Wiederhole Schritte 2–4 soweit notwendig, um die restlichen Ausgabedatenbytes (Lr) wie benötigt zu senden.
    • 6. Die Karte sendet <SW1, SW2> als Abschlussstatus beim Abschluss der Applet.process-Methode.
  • ISO 7816-4 Fall 4
  • Im Fall 4 wird Le nach dem folgenden anfänglichen Austausch festgelegt:
    • 1. Die Karte sendet <0x61, Lr Status-Bytes>
    • 2. Das CAD sendet das Kommando GET RESPONSE mit Le <= Lr.
  • Der Rest der Protokollsequenz ist identisch mit dem oben beschriebenen Fall 2.
  • Wenn das Applet früh abbricht und weniger als Le Bytes sendet, können stattdessen Nullen gesendet werden, um die Länge der von dem CAD erwarteten Übertragung aufzufüllen.
  • 8.1.1.2 Reguläre Ausgabeübertragungen
  • Wenn die Betriebsart der Ausgabeübertragung ohne Verkettung von dem Applet nicht angefordert wird (das heißt, die setOutgoing-Methode wird verwendet), soll die folgende Protokollsequenz befolgt werden:
    Jede beliebige ISO-7816-3/4 entsprechende Protokoll-Übertragungssequenz mit T = 0 kann verwendet werden.
  • Hinweis – Die waitExtension-Methode kann von dem Applet zwischen aufeinander folgenden Aufrufen der sendBytes- oder sendBytesLong-Methoden aufgerufen werden. Die waitExtension-Methode soll eine zusätzliche Arbeitswartezeit (ISO 7816-3) mittels des 0x60-Prozedurbyte anfordern.
  • 8.1.1.3 Zusätzliche Anforderungen bei T = 0
  • Zu jedem beliebigen Zeitpunkt sollen die sendBytes- oder sendBytesLong-Methoden eine APDUException mit dem Ursachencode NO_TO_GETRESPONSE auslösen, falls das CAD ein anderes Kommando hereinsendet, wenn das Ausgabeübertragungsprotokoll mit T = 0 in Verwendung ist und die APDU-Klasse als Reaktion auf einen Antwortstatus <0x61, xx> von der Karte auf ein Kommando GET RESPONSE von dem CAD wartet.
  • Aufrufe der sendBytes- oder sendBytesLong-Methoden von diesem Zeitpunkt an sollen zu einer APDUException mit dem Ursachencode ILLEGAL_USE führen. Wenn eine ISOException von dem Applet ausgelöst wird, nachdem die NO_TO_GETRESPONSE-Ausnahmebedingung ausgelöst wurde, soll die JCRE den Antwortstatus in ihrem Ursachencode verwerfen. Die JCRE soll die APDU-Verarbeitung mit dem zuletzt empfangenen Kommando neu starten und APDU-Abfertigung wieder aufnehmen.
  • 8.1.2 T = 1-Spezifika für ausgehende Datenübertragungen
  • 8.1.2.1 Eingeschränkte Übertragungen ohne Verkettung
  • Wenn die Betriebsart der Ausgabeübertragung ohne Verkettung durch Aufruf der setOutgoingNoChaining-Methode vom Applet angefordert wird, soll die folgende Protokollsequenz befolgt werden:
  • Schreibweise
    • Le
      = vom CAD erwartete Länge.
      Lr
      = Antwortlänge des Applets, die über die setOutgoingLength-Methode eingestellt wird.
  • Die Transportprotokollsequenz soll keine Blockverkettung verwenden. Speziell soll während der Übertragungen das M-Bit (More Data Bit) in dem PCB der 1-Blöcke nicht gesetzt werden (ISO 7816-3). Mit anderen Worten sollen die gesamten Ausgangsdaten (Lr Bytes) in einem einzigen 1-Block übertragen werden.
  • (Wenn das Applet früh abbricht und weniger als Lr Bytes sendet, sollen stattdessen Nullen gesendet werden, um die verbleibende Länge des Blocks aufzufüllen.)
  • Hinweis – Wenn die Betriebsart ohne Verkettung verwendet wird, sollen Aufrufe der waitExtension-Methode eine APDUException mit dem Ursachencode ILLEGAL_USE auslösen.
  • 8.1.2.2 Reguläre Ausgabeübertragungen
  • Wenn die Betriebsart der Ausgabeübertragung ohne Verkettung vom Applet nicht angefordert wird, d. h. die setOutgoing-Methode verwendet wird, soll die folgende Protokollsequenz befolgt werden:
    Jede beliebige ISO-7816-3/4 entsprechende Protokoll-Übertragungssequenz mit T = 1 kann verwendet werden.
  • Hinweis – Die waitExtension-Methode kann von dem Applet zwischen aufeinander folgenden Aufrufen der sendBytes- oder sendBytesLong-Methoden aufgerufen werden. Die waitExtension-Methode soll ein S-Block-Kommando mit WTX-Anforderung von INF Einheiten senden, das äquivalent zu einer Anforderung von 1 zusätzlichen Arbeitswartezeit im Modus T = 0 ist (Siehe ISO 7816-3).
  • 8.2 Die Sicherheits- und Verschlüsselungspakete
  • Die getInstance-Methode in den folgenden Klassen gibt eine Implementierungsinstanz des angeforderten Algorithmus in dem Kontext des aufrufenden Applet zurück:
    javacard.security.MessageDigest
    javacard.security.Signature
    javacard.security.RandomData
    javacardx.crypto.Cipher.
  • Eine Implementierung der JCRE kann 0 oder mehr der in der API aufgelisteten Algorithmen implementieren. Wenn ein Algorithmus angefordert wird, der nicht implementiert ist, soll diese Methode eine CryptoException mit Ursachencode NO_SUCH_ALGORITHM auslösen.
  • Implementierungen der oben genannten Klassen sollen die entsprechende Basisklasse erweitern und alle abstrakten Methoden implementieren. Sämtliche Datenzuordnungen, die mit der Implementierungsinstanz verbunden sind, sollen zum Zeitpunkt des Einrichtens der Instanz durchgeführt werden, um sicherzustellen, dass jedes Fehlen benötigter Ressourcen frühzeitig während der Installation des Applets signalisiert werden kann.
  • In ähnlicher Weise gibt die buildKey-Methode der Klasse javacard.security.keyBuilder eine Implementierungsinstanz der angeforderten Schlüsselart zurück. Die JCRE kann 0 oder mehr Arten von Schlüsseln implementieren. Wenn eine Schlüsselart, die nicht implementiert ist, angefordert wird, soll die Methode eine CryptoException mit Ursachencode NO_SUCH_ALGORITHM auslösen.
  • Implementierungen von Schlüsselarten sollen die zugehörige Schnittstelle implementieren. Sämtliche Datenzuordnungen, die mit der Implementierungsinstanz eines Schlüssels verbunden sind, sollen zum Zeitpunkt des Einrichtens der Instanz durchgeführt werden, um sicherzustellen, dass jedes Fehlen benötigter Ressourcen frühzeitig während der Installation des Applets signalisiert werden kann.
  • 8.3 Die JCSystem-Klasse
  • Bei Java Card 2.1 soll die getVersion-Methode (kurz bzw. short) 0x0201 zurückmelden.
  • 9. THEMEN DER VIRTUELLEN MASCHINE
  • Die Themen in diesem Kapitel liefern Einzelheiten zu Spezifika der virtuellen Maschine.
  • 9.1 Ressourcen-Fehler
  • Eine Ressourcenmangelbedingung (wie Heap-Space), für die eine Wiederherstellung möglich ist, soll zu einer SystemException mit Ursachencode NO_RESOURCE führen. Die Factory-Methoden in JCSystem, die zum Erzeugen transienter Arrays verwendet werden, lösen eine SystemException mit Ursachencode NO_TRANSIENT_SPACE aus, um Mangel an transientem Speicherplatz anzuzeigen.
  • Alle anderen Fehler der virtuellen Maschine (für die keine Wiederherstellung möglich ist) wie ein Überlauf des Stack bzw. Kellerspeichers sollen zu einem Fehler der virtuellen Maschine führen. Diese Bedingungen sollen veranlassen, dass die virtuelle Maschine angehalten wird. Wenn ein solcher Fehler der virtuellen Maschine auftritt, für den keine Wiederherstellung möglich ist, kann eine Implementierung optional anfordern, dass die Karte stumm geschaltet oder für eine weitere Verwendung blockiert wird.
  • 10. APPLET-INSTALLIERER
  • Applet-Installation auf Smart-Cards mittels der Java-Card-Technologie ist eine komplexe Angelegenheit. Die Java-Card-API 2.1 ist dazu gedacht, JCRE-Implementierern so viel Freiheit wie möglich bei ihren Implementierungen zu geben. Es sind jedoch einige grundlegende, gemeinsame Spezifikationen nötig, um zu ermöglichen, dass Java-Card-Applets ohne Kenntnis der Implementierungsdetails eines bestimmten Installierers installiert werden.
  • Diese Spezifikation definiert das Konzept eines Installierers und spezifiziert minimale Installationsanforderungen, um Interoperabilität über einen weiten Bereich möglicher Installierer-Implementierungen zu erreichen.
  • Der Applet-Installierer ist ein optionaler Teil der JCRE-2.1-Spezifikation. Das heißt, eine Implementierung von JCRE braucht nicht notwendigerweise einen Nach-Ausgabe-Installierer zu beinhalten. Wenn er jedoch implementiert ist, wird von dem Installierer gefordert, dass er das in Abschnitt 9.1 spezifizierte Verhalten unterstützt.
  • 10.1 Der Installierer
  • Die Mechanismen, die notwendig sind, um ein Applet auf Smart-Cards mittels Java-Card-Technologie zu installieren, sind in einer Komponente auf der Karte enthalten, die der Installierer genannt wird.
  • Dem CAD erscheint der Installierer als ein Applet. Er hat eine AID und er wird zum aktuell gewählten Applet, wenn diese AID erfolgreich von einem SELECT-Kommando verarbeitet wird. Sobald er ausgewählt ist, verhält sich der Installierer in weitgehend derselben Weise wie jedes andere Applet.
    • • Er empfängt alle APDUs genau wie jedes andere ausgewählte Applet.
    • • Seine Entwurfsspezifikation schreibt die verschiedenen Arten und Formate von APDUs, die er zu empfangen erwartet, zusammen mit der Semantik dieser Kommandos unter verschiedenen Vorbedingungen vor.
    • • Er verarbeitet und antwortet auf alle APDUs, die er empfängt. Inkorrekte APDUs werden mit einem Fehlerzustand einer bestimmten Art beantwortet.
    • • Wenn ein anderes Applet ausgewählt wird (oder wenn die Karte zurückgesetzt oder die Stromzufuhr von der Karte entfernt wird), wird der Installierer deselektiert und bleibt suspendiert, bis er das nächste Mal SE-LECTiert wird.
  • 10.1.1 Installierer-Implementierung
  • Der Installierer braucht nicht als ein Applet auf der Karte implementiert zu werden. Die Anforderung ist nur, dass die Funktionalität des Installierers SELECTierbar sein soll. Die logische Folge dieser Anforderung ist, dass es weder möglich sein soll, dass die Installierer-Komponente aufgerufen wird, wenn ein Nicht-Installierer-Applet selektiert ist, noch dann, wenn kein Applet selektiert ist.
  • Offensichtlich könnte sich ein JCRE-Implementierer entscheiden, den Installierer als Applet zu implementieren. Wenn dies erfolgt, dann könnte der Installierer so kodiert werden, dass er die Klasse Applet erweitert und auf Aufrufe der select-, process- und deselect-Methoden antwortet.
  • Ein JCRE-Implementierer könnte aber auch den Installierer auf andere Weise implementieren, solange er das SELECTierbare Verhalten gegenüber der äußeren Welt zur Verfügung stellt. In diesem Fall hat der JCRE-Implementierer die Freiheit, einen bestimmten anderen Mechanismus vorzusehen, durch den APDUs an das Codemodul des Installierers geliefert werden.
  • 10.1.2 Installierer-AID
  • Weil der Installierer SELECTierbar ist, soll er eine AID haben. JCRE-Implementierern ist es freigestellt, ihre eigene AID auszuwählen, durch die ihr Installierer ausgewählt wird. Mehrere Installierer können implementiert werden.
  • 10.1.3 Installierer-APDUs
  • Die Java-Card-API 2.1 spezifiziert keine APDUs für den Installierer. JCRE-Implementierern ist es vollkommen freigestellt, ihre eigenen APDU-Kommandos zu wählen, um ihren Installierer bei seiner Arbeit anzuweisen.
  • Das Modell besteht darin, dass der Installierer auf der Karte von einem Installationsprogramm getrieben wird, das auf dem CAD abläuft. Damit die Installation erfolgreich ist, soll dieses CAD-Installationsprogramm in der Lage sein:
    • • die Karte zu erkennen.
    • • den Installierer auf der Karte auszuwählen (SELECT).
    • • den Installationsprozess durch Senden der geeigneten APDUs an den Installierer auf der Karte zu treiben. Diese APDUs werden enthalten:
    • – Information zur Authentifizierung, um sicherzustellen, dass die Installation autorisiert ist.
    • – den in den Speicher der Karte zu ladenden Applet-Code.
    • – Verknüpfungsinformation, um den Applet-Code mit dem bereits auf der Karte vorhandenen Code zu verknüpfen (link).
    • – Parameterdaten zur Initialisierung einer Instanz, die an die install-Methode eines Applet zu senden sind.
  • Die Java-Card-API 2.1 spezifiziert weder die Einzelheiten des CAD-Installationsprogramms noch die zwischen ihr und dem Installierer übergebenen APDUs.
  • 10.1.4 Installierer-Verhalten
  • JCRE-Implementierer sollen außerdem andere Verhaltensweisen ihres Installierers definieren, einschließlich:
    • • ob die Installation abgebrochen werden kann oder nicht und wie dies geschieht.
    • • was passiert, wenn eine Ausnahmebedingung, ein Rücksetzen oder ein Stromausfall während der Installation eintritt.
    • • was passiert, wenn ein anderes Applet ausgewählt wird, bevor der Installierer mit seiner Arbeit fertig ist.
  • Die JCRE soll sicherstellen, dass ein Applet nicht als erfolgreich installiert angesehen wird, wenn
    • • die install-Methode des Applets vor der erfolgreichen Rückkehr aus der Methode Applet.register eine Ausnahmebedingung auslöst. (Siehe Absatz 9.2)
  • 10.1.5 Installierer-Privilegien
  • Obwohl ein Installierer als ein Applet implementiert werden kann, braucht der Installierer typischerweise Zugang zu Merkmalen bzw. Funktionen, die ”anderen Applets” nicht zur Verfügung stehen. Zum Beispiel muss der Installierer abhängig von der Implementierung des JCRE-Implementierers:
    • • unter Umgehung des Objektsystems und/oder der standardmäßigen Sicherheitsvorkehrung direkt aus dem oder in den Speicher lesen und schreiben können.
    • • auf Objekte zugreifen können, die anderen Applets oder der JCRE gehören.
    • • non-Entry-Point-Methoden der JCRE aufrufen können.
    • • in der Lage sein, die install-Methode eines neu installierten Applets aufzurufen.
  • Es ist wiederum Sache jedes JCRE-Implementierers, die Implementierung des Installierers festzulegen und solche Merkmale in ihrer JCRE-Implementierung vorzusehen, die zur Unterstützung ihres Installierers notwendig sind. Die JCRE-Implementierer sind außerdem für die Sicherheit solcher Merkmale verantwortlich, so dass sie normalen Applets nicht zur Verfügung stehen.
  • 10.2 Das neu installierte Applet
  • Es gibt eine einzige Schnittstelle zwischen dem Installierer und dem Applet, das installiert wird. Nachdem der Installierer das Applet korrekt zur Ausführung vorbereitet hat (Schritte wie Laden und Verknüpfen durchgeführt hat), soll der Installierer die install-Methode des Applets aufrufen. Diese Methode ist in der Klasse Applet definiert.
  • Der genaue Mechanismus, durch den die install-Methode eines Applet von dem Installierer aufgerufen wird, ist ein vom JCRE-Implementierer definiertes Implementierungsdetail. Es soll jedoch eine Kontextumschaltung geben, so dass irgendwelche kontextbezogenen Operationen, die von der install-Methode durchgeführt werden (wie das Anlegen bzw. Erzeugen neuer Objekte) in dem Kontext des neuen Applets und nicht im Kontext des Installierer vorgenommen werden. Der Installierer soll auch sicherstellen, dass während der Initialisierungsmethoden der Applet-Klasse (<clinit>) angelegte Arrayobjekte auch dem Kontext des neuen Applets gehören.
  • Die Installation eines Applets wird als abgeschlossen angesehen, wenn alle Schritte ohne Fehler oder ohne dass eine Ausnahmebedingung ausgelöst wird abgeschlossen sind bis zu und einschließlich der erfolgreichen Rückkehr aus der Ausführung der Methode Applet.register. Zu diesem Zeitpunkt ist das Applet selektierbar.
  • Die maximale Größe der Parameterdaten ist 32 Bytes. Und aus Sicherheitsgründen wird der Parameter bArray nach der Rückkehr mit Nullen gefüllt (genau wie der APDU-Puffer bei der Rückkehr von der process-Methode eines Applets mit Nullen gefüllt wird.)
  • 10.2.1 Installationsparameter
  • Außer der maximalen Größe von 32 Bytes spezifiziert die Java-Card-API 2.1 nichts über die Inhalte des Bytearray-Segmentes der Installationsparameter. Dies wird vollständig von dem Designer des Applets definiert und kann in jedem gewünschten Format sein. Darüber hinaus sollen diese Installationsparameter für den Installierer undurchsichtig sein.
  • JCRE-Implementierer sollten ihre Installierer so entwerfen, dass es möglich ist, dass ein in einem CAD ablaufendes Installationsprogramm ein beliebiges Bytearray spezifiziert, das an den Installierer geliefert wird. Der Installierer gibt dieses Bytearray einfach an die install-Methode des Ziel-Applets in dem Parameter bArray weiter. Eine typische Implementierung könnte ein JCRE-Implementierer-eigenes APDU-Kommando definieren, das die Semantik hat ”rufe die install-Methode des Applets und übergib die Inhalte des beigefügten Bytearray.”
  • 11. API-KONSTANTEN
  • Für einige der API-Klassen sind keine Werte für ihre Konstanten in der Java Card API 2.1 Reference spezifiziert. Wenn konstante Werte nicht konsistent von den Implementierern dieser JCRE-2.1-Spezifikation spezifiziert werden, ist eine industrieweite Interoperabilität unmöglich. Dieses Kapitel liefert die erforderlichen Werte für Konstanten, die in der Java Card API 2.1 Reference nicht spezifiziert sind.
  • Klasse javacard.framework.APDU
    • public static final byte PROTOCOL_T0 = 0;
    • public static final byte PROTOCOL_T1 = 1;
  • Klasse javacard.framework.APDUException
    • public static final short ILLEGAL_USE = 1;
    • public static final short BUFFER_BOUNDS = 2;
    • public static final short BAD_LENGTH = 3;
    • public static final short IO_ERROR = 4;
    • public static final short NO_TO_GETRESPONSE = OxAA;
  • Schnittstelle javacard.framework.IS07816
    • public final static short SW_NO_ERROR = (short)0x9000;
    • public final static short SW_BYTES_REMAINING_00 = 0x6100;
    • public final static short SW_WRONG_LENGTH = 0x6700;
    • public static final short SW_SECURITY_STATUS NOT SATISFIED = 0x6982;
    • public final static short SW_FILE_INVALID = 0x6983;
    • public final static short SW_DATA_INVALID = 0x6984;
    • public final static short SW_CONDITIONS_NOT_SATISFIED = 0x6985;
    • public final static short SW_COMMAND_NOT_ALLOWED = 0x6986;
    • public final static short SW_APPLET_SELECT_FAILED = 0x6999;
    • public final static short SW_WRONG_DATA = 0x6A80;
    • public final static short SW_FUNC_NOT_SUPPORTED = 0x6A81;
    • public final static short SW_FILE_NOT_FOUND = 0x6A82;
    • public final static short SW_RECORD_NOT_FOUND = 0x6A83;
    • public final static short SW_INCORRECT_P1P2 = 0x6A86;
    • public final static short SW_WRONG_P1P2 = 0x6B00;
    • public final static short SW_CORRECT_LENGTH_00 = 0x6C00;
    • public final static short SW_INS_NOT_SUPPORTED = 0x6DOO;
    • public final static short SW_CLA_NOT_SUPPORTED = 0x6E00;
    • public final static short SW_UNKNOWN = Ox6F00;
    • public static final short SW_FILE_FULL = 0x6A84;
    • public final static byte OFFSET_CLA = 0;
    • public final static byte OFFSET_INS = 1;
    • public final static byte OFFSET_P1 = 2;
    • public final static byte OFFSET_P2 = 3;
    • public final static byte OFFSET_LC = 4;
    • public final static byte OFFSET_CDATA = 5;
    • public final static byte CLA_ISO7816 = 0x00;
    • public final static byte INS_SELECT = (byte) 0xA4;
    • public final static byte INS_EXTERNAL_AUTHENTICATE = (byte) 0x82;
  • Klasse javacard.framework.JCSystem
    • public static final byte NOT_A_TRANSIENTOBJECT = 0;
    • public static final byte CLEAR_ON_RESET = 1;
    • public static final byte CLEAR_ON_DESELECT = 2;
  • Klasse javacard.framework.PINException
    • public static final short ILLEGAL_VALUE = 1;
  • Klasse javacard.framework.SystemException
    • public static final short ILLEGAL_VALUE = 1;
    • public static final short NO_TRANSIENT_SPACE = 2;
    • public static final short ILLEGAL_TRANSIENT = 3;
    • public static final short ILLEGAL_AID = 4;
    • public static final short NO_RESOURCE = 5;
  • Klasse javacard.security.CryptoException
    • public static final short ILLEGAL_VALUE = 1;
    • public static final short UNINITIALIZED_KEY = 2;
    • public static final short NO_SUCH_ALGORITHM = 3;
    • public static final short INVALID_INIT = 4;
    • public static final short ILLEGAL_USE = 5;
  • Klasse javacard.security.KeyBuilder
    • public static final byte TYPE_DES_TRANSIENT_RESET = 1;
    • public static final byte TYPE_DES_TRANSIENT_DESELECT = 2;
    • public static final byte TYPE_DES = 3;
    • public static final byte TYPE_RSA_PUBLIC = 4;
    • public static final byte TYPE_RSA_PRIVATE = 5;
    • public static final byte TYPE-RSA_CRT_PRIVATE = 6;
    • public static final byte TYPE_DSA_PUBLIC = 7;
    • public static final byte TYPE_DSA_PRIVATE = 8;
    • public static final short LENGTH_DES = 64;
    • public static final short LENGTH_DES3_2KEY = 128;
    • public static final short LENGTH_DES3_3KEY = 192;
    • public static final short LENGTH_RSA_512 = 512;
    • public static final short LENGTH_RSA_768 = 768;
    • public static final short LENGTH_RSA_1024 = 1024;
    • public static final short LENGTH_RSA_2048 = 2048
    • public static final short LENGTH_DSA_512 = 512;
    • public static final short LENGTH_DSA_768 = 768;
    • public static final short LENGTH_DSA_1024 = 1024;
  • Klasse javacard.security.MessageDigest
    • public static final byte ALG_SHA = 1;
    • public static final byte ALG_MD5 = 2;
    • public static final byte ALG_RIPEMD160 = 3;
  • Klasse javacard.security.RandomData
    • public static final byte ALG_PSEUDO_RANDOM = 1;
    • public static final byte ALG_SECURE_RANDOM = 2;
  • Klasse javacard.security.Signature
    • public static final byte ALG_DES_MAC4_NOPAD = 1;
    • public static final byte ALG_DES_MAC8_NOPAD = 2;
    • public static final byte ALG_DES_MAC4_ISO9797_M1 = 3;
    • public static final byte ALG_DES_MAC8_ISO9797_M1 = 4;
    • public static final byte ALG_DES_MAC4_ISO9797_M2 = 5;
    • public static final byte ALG_DES_MAC8_ISO9797_M2 = 6;
    • public static final byte ALG_DES_MAC4_PKCSS = 7;
    • public static final byte ALG_DES_MAC8_PKCS5 = 8;
    • public static final byte ALG_RSA_SHA_ISO9796 = 9;
    • public static final byte ALG_RSA_SHA_PKCS1 = 10;
    • public static final byte ALG_RSA_MDS_PKCS1 = 11;
    • public static final byte ALG_RSA_RIPEMD160_ISO9796 = 12;
    • public static final byte ALG_RSA_RIPEMD160 PKCS1 = 13;
    • public static final byte ALG_DSA_SHA = 14;
    • public static final byte MODE_SIGN = 1;
    • public static final byte MODE_VERIFY = 2;
  • Klasse javacardx.crypto.Cipher
    • public static final byte ALG_DES_CBC_NOPAD = 1;
    • public static final byte ALG_DES_CBC_ISO9797_M1 = 2;
    • public static final byte ALG_DES_CBC_ISO9797_M2 = 3;
    • public static final byte ALG_DES_CBC_PKCS5 = 4;
    • public static final byte ALG_DES_ECB_NOPAD = 5;
    • public static final byte ALG_DES_ECB_ISO9797 M1 = 6;
    • public static final byte ALG_DES_ECB_ISO9797 M2 = 7;
    • public static final byte ALG_DES_ECB_PKCS5 = 8;
    • public static final byte ALG_RSA_ISO14888 = 9;
    • public static final byte ALG_RSA_PKCS1 = 10;
    • public static final byte MODE_DECRYPT = 1;
    • public static final byte MODE_ENCRYPT = 2;
  • 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-Card-Technologie ist.
  • Applet Developer (Applet-Entwickler) bezieht sich auf eine Person, die unter Verwendung von Spezifikationen der Java-Card-Technologie ein Java-Card-Applet erzeugt.
  • Applet-Firewall ist der Mechanismus in der Java-Card-Technologie, durch welchen die VM verhindert, dass 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.
  • Atomare Operation (unteilbare Operation) ist eine Operation, die entweder als Ganzes abgeschlossen wird (wenn die Operation erfolgreich ist) oder bei der überhaupt kein Teil der Operation abgeschlossen wird (wenn die Operation fehlschlägt).
  • Atomizität (Unteilbarkeit) bezieht sich darauf, ob eine bestimmte Operation atomar (unteilbar) ist oder nicht, und ist für saubere Datenwiederherstellung in Fällen notwendig, in denen die Stromzufuhr verloren geht oder die Karte unerwartet aus dem CAD entfernt wird.
  • ATR ist ein Akronym für Antwort auf Rücksetzen bzw. Answer to Reset. Eine ATR ist eine Kette von Bytes, die von der Java-Card nach einer Rücksetzbedingung gesendet wird.
  • 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.
  • cJCK ist die Testsuite zum Überprüfen der Einhaltung der Spezifikationen der Java-Card-Technologie bei der Implementierung. Die cJCK verwendet das Java-Test-Tool, um die Testsuite ablaufen zu lassen.
  • 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 gemeinsames Verhalten 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-Card-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, dass 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 Einfluss 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 AUSWAHL-Befehls mit der AID dieses Applets macht die JCRE dieses Applet zu dem aktuell ausgewählten Applet. Die JCRE sendet alle APDU-Befehle an das aktuell ausgewählte Applet.
  • EEPROM ist ein Akronym für einen elektrisch löschbaren, programmierbaren Nur-Lese-Speicher (Electrically Erasable, Programmable Read-Only Memory).
  • Firewall (siehe Applet-Firewall).
  • Framework (Rahmen) ist der Satz von Klassen, welche die API implementieren. Dies umfasst Kern- und Erweiterungspakete. Verantwortlichkeiten umfassen das Verarbeiten von APDUs, die Appletauswahl, das Verwalten von Unteilbarkeit und das Installieren von Applets.
  • Garbage collection (Zusammenfassung von Ausschlussdaten) ist der Vorgang, durch welchen dynamisch zugeordneter Speicher während der Ausführung eines Programms automatisch wieder beansprucht wird.
  • 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.
  • JAR ist ein Akronym für Java-Archiv. JAR ist ein plattformunabhängiges Dateiformat, welches viele Dateien zu einer einzigen verbindet.
  • Java Card Runtime Environment (JCRE – Java-Kartenumgebung während der Laufzeit) besteht aus der virtuellen Java-Card-Maschine, dem Rahmen und den zugehörigen inhärenten (natürlichen) Methoden.
  • JC21RI ist ein Akronym für die Referenzimplementierung von 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-Card-Maschine. 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 in Kraft (Firewalls) 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.
  • Persistent object (dauerhaftes Objekt). Dauerhafte Objekte und ihre Werte bleiben von einer CAD-Sitzung bis zur nächsten unbegrenzt erhalten. Objekte sind standardmäßig dauerhaft (persistent). Dauerhafte Objektwerte werden unter Verwendung von Transaktionen automatisch aktualisiert. Der Begriff dauerhaft bzw. persistent bedeutet nicht, dass auf der Karte eine objektorientierte Datenbank vorhanden ist oder dass Objekte der seriellen Reihenfolge erstellt werden oder die Reihenfolge aufgehoben wird, sondern nur, dass die Objekte nicht verloren gehen, wenn die Karte ihre Stromversorgung verliert.
  • 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 interface object (gemeinsam verwendbares Interfaceobjekt – SIO). Ein Objekt, welches die gemeinsam verwendbare Schnittstelle implementiert.
  • Transaktion ist eine atomare Operation, bei welcher der Entwickler das Ausmaß der Operation definiert durch Anzeigen des Anfangs und des Endes der Transaktion im Programmcode.
  • Transientes Objekt (Übergangsobjekt). Die Werte von transienten Objekten bleiben nicht von einer CAD-Sitzung bis zu der nächsten erhalten und sie werden in spezifizierten Intervallen auf einen Standardzustand zurückgesetzt. Aktualisierungen der Werte transienter Objekte sind nicht unteilbar und werden nicht durch Transaktionen beeinflusst.

    Datum: 16. Dezember 1998

    Sehr geehrter Lizenznehmer von Java Card,

    JCRE21-DF2-14DEC98.zip enthält einen zweiten Entwurf der Spezifikation der Laufzeitumgebung von Java Card 2.1 vom 14. Dezember 1998 für die Durchsicht und Kommentierung durch den Lizenznehmer. Wir haben die Rückmeldungen, die wir bisher erhalten haben, eingearbeitet und auf dieser Basis das Dokument klarer formuliert.
  • Der vollständige Inhalt der zip-Dateien ist der folgende:
    READ-ME-JCRE21-DF2.txt – Die vorliegende READ ME-
    JCRE21-DF2.pdf Textdatei
    – ”Java Card Runtime
    JCRE21-DF2 Environment (JCRE) 2.1
    changebar.pdf Specification” im PDF-Format
  • Zusammenfassung der Änderungen:
    • 1. Dies ist nunmehr eine Freigabe des Entwurfs 2 und wird in Kürze auf der öffentlichen Webseite veröffentlicht.
    • 2. Eine neue Beschreibung temporärer JCRE-Eintragspunktobjekte ist zur Einschränkung nicht autorisierter Zugriffe eingefügt worden. Firewall Kapitel 6.2.1.
    • 3. Globale Arrays haben nun zusätzliche Einschränkungen aus Gründen der Sicherheit ähnlich wie temporäre JCRE-Eintragspunktobjekte. Firewall Kapitel 6.2.2.
    • 4. Genaue Beschreibungen der Bytecodes bezüglich der Speicherbeschränkungen für temporäre JCRE-Eintragspunktobjekte und globale Arrays wurden hinzugefügt. Kapitel 6.2.8.
    • 5. Allgemeine Feststellung zu Ausnahmebedingungsobjekten im Besitz der JCRE wurden in Kapitel 8 hinzugefügt.
    • 6. Korrigierte Beschreibung des iner Virtuellen Maschinen-Ressourcen bei vorübergehenden Fabrikverfahren. Kapitel 9.1.
  • Die ”Spezifikation der Java Card-Laufzeitumgebung 2.1” beschreibt das Minimalverhalten und die Laufzeitumgebung für eine komplette Implementierung von Java Card 2.1, wie sie durch die Spezifikationsdokumente von Java Card APT 2.1 und die Java Card 2.1-virtuelle Maschine in Bezug genommen wird. Diese Spezifikation muss eine kompatible Arbeitsweise von Java Card-Applets sicherstellen. Der Zweck dieses Spezifikationsdokuments besteht darin, alle JCRE-Elemente gemeinsam in klarer Weise als Teil der Spezifikationssuite von Java Card 2.1 zusammenzubringen.
  • Bitte senden Sie Ihre Kommentare an <javaoemjavacard@sun.com> oder an meine unten angegebene Adresse. Im Namen des Java Card-Teams freue ich mich darauf, von Ihnen zu hören.

    Mit besten Grüßen

    Godfrey DiGiorgi

    Godfrey DiGiorgi – godfrey.digiorgi@eng.sun.com
    OEM Licensee Engineering
    Sun Microsystems/Java Software
    + 1 408 343-1506 FAX +1 408 517 5460

Claims (8)

  1. Verfahren zum Betreiben einer kleinformatigen Einrichtung (400), welche eine Verarbeitungsmaschine (410) aufweist, wobei die kleinformatige Einrichtung eine Smartcard oder ein Mobiltelefon ist, wobei Programmodule auf der Verarbeitungsmaschine ausgeführt werden, und wobei die Verarbeitungsmaschine (410) eine virtuelle Maschine (720) aufweist, die auf einem Prozessor (300) läuft, und ein Objektsystem zum Verwalten der Objekte einer objektorientierten Implementierunung enthält, gekennzeichnet durch: Ausführen von Gruppen aus einem oder mehreren Programmodulen in getrennten Kontexten (420, 620; 760, 770, 780; 1000, 1010, 1020), die auf einer virtuellen Maschine laufen, Bereitstellen einer Kontextbarriere (600; 600'), um die Kontexte voneinander zu trennen und zu isolieren und um den Zugriff eines Programmoduls, das in einem Kontext abläuft, auf Information und/oder auf ein Programmodul, welches in einem anderen Kontext abläuft, zu kontrollieren, wobei jedes der Objekte einem zugeordneten Kontext zugehörig ist, und Bereitstellen einer globalen Datenstruktur, wobei jedes Programmodul jedes Kontexts Daten von der globalen Datenstruktur lesen und in diese schreiben darf und wobei die globale Datenstruktur zum Leiten von Referenzen zu Objekten zwischen Kontexten verwendet wird.
  2. Verfahren nach Anspruch 1, wobei die globale Datenstruktur zeitweise bereitgestellt wird.
  3. Verfahren nach Anspruch 1 oder 2, wobei nur einer der Kontexte die globale Datenstruktur erzeugen darf.
  4. Verfahren nach einem der vorstehenden Ansprüche 1 bis 3, wobei das Verfahren weiterhin das Zuordnen getrennter entsprechender Namensräume für jeden Kontext aufweist.
  5. Verfahren nach einem der vorstehenden Ansprüche 1 bis 3, wobei das Verfahren weiterhin das Zuordnen entsprechender Speicherräume für jeden Kontext aufweist.
  6. Verfahren nach einem der vorstehenden Ansprüche 1 bis 5, wobei das Kontrollieren des Zugriffs eines Programmoduls, welches in einem Kontext abläuft, auf Information und/oder auf ein Programmodul, welches in einem anderen Kontext abläuft, mit Hilfe der Kontextbarriere (600; 600') weiterhin das Verhindern des Zugriffs aufweist, wenn der Zugriff nicht autorisiert ist, und das Freigeben des Zugriffs aufweist, wenn der Zugriff autorisiert ist.
  7. Verfahren nach Anspruch 6, wobei die Autorisierung des Zugriffs zumindest eine Sicherheitsüberprüfung umfasst.
  8. Computerprogrammprodukt, welches ein Programm aus Befehlen verwirklicht, um eine kleinformatige Einrichtung (400) nach einem der Verfahrensansprüche 1 bis 7 zu betreiben.
DE60011615.8T 1999-01-22 2000-01-20 Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen Expired - Lifetime DE60011615T3 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/235,156 US6907608B1 (en) 1999-01-22 1999-01-22 Techniques for permitting access across a context barrier in a small footprint device using global data structures
US235156 1999-01-22
EP00921312.5A EP1190316B2 (de) 1999-01-22 2000-01-20 Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen
PCT/US2000/001234 WO2000045262A2 (en) 1999-01-22 2000-01-20 Techniques for permitting access across a context barrier in a small footprint device using global data structures

Publications (3)

Publication Number Publication Date
DE60011615D1 DE60011615D1 (de) 2004-07-22
DE60011615T2 DE60011615T2 (de) 2005-07-07
DE60011615T3 true DE60011615T3 (de) 2015-12-31

Family

ID=22884324

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60011615.8T Expired - Lifetime DE60011615T3 (de) 1999-01-22 2000-01-20 Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen
DE1190316T Pending DE1190316T1 (de) 1999-01-22 2000-01-20 Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE1190316T Pending DE1190316T1 (de) 1999-01-22 2000-01-20 Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen

Country Status (10)

Country Link
US (2) US6907608B1 (de)
EP (2) EP1190316B2 (de)
JP (1) JP4716573B2 (de)
KR (1) KR100687668B1 (de)
CN (1) CN1290009C (de)
AT (1) ATE269558T2 (de)
AU (1) AU763958B2 (de)
DE (2) DE60011615T3 (de)
HK (1) HK1041333A1 (de)
WO (1) WO2000045262A2 (de)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6633984B2 (en) * 1999-01-22 2003-10-14 Sun Microsystems, Inc. Techniques for permitting access across a context barrier on a small footprint device using an entry point object
JP4074057B2 (ja) * 2000-12-28 2008-04-09 株式会社東芝 耐タンパプロセッサにおける暗号化データ領域のプロセス間共有方法
FR2819602B1 (fr) * 2001-01-12 2003-02-21 Gemplus Card Int Procede de gestion d'applications informatiques par le systeme d'exploitation d'un systeme informatique multi-applications
US6588674B2 (en) 2001-07-27 2003-07-08 Motorola, Inc. Memory management method and smartcard employing same
US7065760B2 (en) 2002-02-28 2006-06-20 Sun Microsystems, Inc. Reducing the memory footprint of applications executed in a virtual machine
US20040122774A1 (en) * 2002-08-02 2004-06-24 Martin Studd Method and system for executing applications on a mobile device
US20080313282A1 (en) 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
US7337445B1 (en) 2003-05-09 2008-02-26 Sun Microsystems, Inc. Virtual system console for virtual application environment
US8892878B2 (en) 2003-05-09 2014-11-18 Oracle America, Inc. Fine-grained privileges in operating system partitions
US7437556B2 (en) 2003-05-09 2008-10-14 Sun Microsystems, Inc. Global visibility controls for operating system partitions
US7389512B2 (en) 2003-05-09 2008-06-17 Sun Microsystems, Inc. Interprocess communication within operating system partitions
US7461080B1 (en) * 2003-05-09 2008-12-02 Sun Microsystems, Inc. System logging within operating system partitions using log device nodes that are access points to a log driver
JP2005050286A (ja) 2003-07-31 2005-02-24 Fujitsu Ltd ネットワークノードマシンおよび情報ネットワークシステム
FR2864658B1 (fr) * 2003-12-30 2006-02-24 Trusted Logic Controle d'acces aux donnees par verification dynamique des references licites
US7165727B2 (en) 2004-02-24 2007-01-23 Sun Microsystems, Inc. Method and apparatus for installing an application onto a smart card
US7374099B2 (en) 2004-02-24 2008-05-20 Sun Microsystems, Inc. Method and apparatus for processing an application identifier from a smart card
US7191288B2 (en) 2004-02-24 2007-03-13 Sun Microsystems, Inc. Method and apparatus for providing an application on a smart card
US7140549B2 (en) 2004-02-24 2006-11-28 Sun Microsystems, Inc. Method and apparatus for selecting a desired application on a smart card
WO2005086000A2 (en) * 2004-03-04 2005-09-15 Axalto Sa A secure sharing of resources between applications in independent execution environments in a retrievable token (e.g smart card)
US7337976B2 (en) 2004-04-08 2008-03-04 Matsushita Electric Industrial Co., Ltd. Semiconductor memory
US8214799B2 (en) * 2004-07-08 2012-07-03 Microsoft Corporation Providing information to an isolated hosted object via system-created variable objects
US20060010423A1 (en) * 2004-07-08 2006-01-12 Microsoft Corporation Variable namespaces and scoping for variables in an object model
EP1794679A1 (de) * 2004-09-30 2007-06-13 Citrix Systems, Inc. Verfahren und vorrichtung zum verlagern von prozessen zwischen isolationsumgebungen
US7458072B2 (en) * 2004-10-06 2008-11-25 Microsoft Corporation Execution context infrastructure
US8181182B1 (en) 2004-11-16 2012-05-15 Oracle America, Inc. Resource allocation brokering in nested containers
US8719840B2 (en) * 2005-02-17 2014-05-06 Koninklijke Philips N.V. Device for secure interprocess communication
US8087031B2 (en) * 2006-01-09 2011-12-27 Oracle America, Inc. Method and apparatus for data transfer between isolated execution contexts
JP4627266B2 (ja) * 2006-02-16 2011-02-09 株式会社日立ソリューションズ 未知のマルウェアによる情報漏洩防止システム
US7882227B2 (en) 2006-02-23 2011-02-01 Oracle America, Inc. Mechanism for implementing file access control across a network using labeled containers
US7885975B2 (en) 2006-02-23 2011-02-08 Oracle America, Inc. Mechanism for implementing file access control using labeled containers
US8938473B2 (en) 2006-02-23 2015-01-20 Oracle America, Inc. Secure windowing for labeled containers
US8938554B2 (en) 2006-03-02 2015-01-20 Oracle America, Inc. Mechanism for enabling a network address to be shared by multiple labeled containers
US20080309665A1 (en) * 2007-06-13 2008-12-18 3D Systems, Inc., A California Corporation Distributed rapid prototyping
US8171483B2 (en) 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
EP2169900A1 (de) * 2008-09-30 2010-03-31 Gemplus Regler von Befehlen, die zur sensiblen Anwendung geschickt werden
US8244870B2 (en) * 2008-11-18 2012-08-14 Raytheon Company Distributing traffic to multiple GNS devices
US8219676B2 (en) 2009-06-22 2012-07-10 Citrix Systems, Inc. Systems and methods for web logging of trace data in a multi-core system
US8850573B1 (en) * 2010-04-14 2014-09-30 Google Inc. Computing device with untrusted user execution mode
US8335921B2 (en) 2010-12-17 2012-12-18 Google, Inc. Writing application data to a secure element
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US8255687B1 (en) 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8313036B1 (en) 2011-09-16 2012-11-20 Google Inc. Secure application directory
US8385553B1 (en) 2012-02-28 2013-02-26 Google Inc. Portable secure element
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
CN103093142B (zh) * 2012-12-26 2015-07-22 飞天诚信科技股份有限公司 一种Java卡对象访问的控制方法
DE102016007189A1 (de) * 2016-06-14 2017-12-14 Giesecke+Devrient Mobile Security Gmbh Ressourcenbeschränktes Java Card Device
DE102018115758A1 (de) * 2018-06-29 2020-01-02 Infineon Technologies Ag Sicherheit von Java-Card-Schlüsselobjekten
DE102022002247A1 (de) * 2022-06-21 2023-12-21 Giesecke+Devrient ePayments GmbH Geteilte Kontexte bei auf einen Datenträger geladenen Applets

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61177585A (ja) 1985-02-04 1986-08-09 Toshiba Corp 携帯用電子装置密封体
US4816654A (en) 1986-05-16 1989-03-28 American Telephone And Telegraph Company Improved security system for a portable data carrier
JP2514954B2 (ja) * 1987-03-13 1996-07-10 三菱電機株式会社 Ｉｃカ−ド
JPH01277993A (ja) 1988-04-28 1989-11-08 Toshiba Corp 携帯可能電子装置
JPH02156357A (ja) 1988-12-08 1990-06-15 Fujitsu Ltd プログラム破壊防止方法
US5057997A (en) * 1989-02-13 1991-10-15 International Business Machines Corp. Interruption systems for externally changing a context of program execution of a programmed processor
US5204663A (en) 1990-05-21 1993-04-20 Applied Systems Institute, Inc. Smart card access control system
ATE100229T1 (de) 1990-07-20 1994-01-15 Siemens Nixdorf Inf Syst Verfahren zur verhinderung unzulaessiger abweichungen vom ablaufprotokoll einer anwendung bei einem datenaustauschsystem.
JP3007425B2 (ja) 1991-02-14 2000-02-07 凸版印刷 株式会社 Ｉｃカード
US5204897A (en) 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
DE4126213C2 (de) 1991-08-08 2000-06-15 Deutsche Telekom Ag Chipkarte für mehrere Diensteanbieter
FR2683357A1 (fr) 1991-10-30 1993-05-07 Philips Composants Microcircuit pour carte a puce a memoire programmable protegee.
US5682027A (en) 1992-10-26 1997-10-28 Intellect Australia Pty Ltd. System and method for performing transactions and a portable intelligent device therefore
US5649118A (en) 1993-08-27 1997-07-15 Lucent Technologies Inc. Smart card with multiple charge accounts and product item tables designating the account to debit
US5544246A (en) 1993-09-17 1996-08-06 At&T Corp. Smartcard adapted for a plurality of service providers and for remote installation of same
GB9320982D0 (en) * 1993-10-12 1993-12-01 Ibm A data processing system
US5481715A (en) * 1993-12-15 1996-01-02 Sun Microsystems, Inc. Method and apparatus for delegated communications in a computer system using trusted deputies
EP0757336B1 (de) 1995-08-04 2000-11-22 Belle Gate Investment B.V. Datenaustauschlsysteme mit tragbaren Datenverarbeitungseinheiten
EP0666550B1 (de) 1994-02-08 1997-05-02 Belle Gate Investment B.V. Datenauswechselsystem mit tragbaren Datenverarbeitungseinheiten
US5594227A (en) 1995-03-28 1997-01-14 Microsoft Corporation System and method for protecting unauthorized access to data contents
WO1996031823A1 (en) * 1995-04-07 1996-10-10 Sofmap Future Design Co., Ltd. Data processing system and method, and computer program architecture
US5768385A (en) 1995-08-29 1998-06-16 Microsoft Corporation Untraceable electronic cash
US5721781A (en) 1995-09-13 1998-02-24 Microsoft Corporation Authentication system and method for smart card transactions
DE19536169A1 (de) * 1995-09-29 1997-04-03 Ibm Multifunktionale Chipkarte
FR2743910B1 (fr) * 1996-01-19 1998-02-27 Solaic Sa Procede de mise en oeuvre d'un programme securise dans une carte a microprocesseur et carte a microprocesseur comportant un programme securise
US5742756A (en) 1996-02-12 1998-04-21 Microsoft Corporation System and method of using smart cards to perform security-critical operations requiring user authorization
US5845129A (en) * 1996-03-22 1998-12-01 Philips Electronics North America Corporation Protection domains in a single address space
US5781723A (en) 1996-06-03 1998-07-14 Microsoft Corporation System and method for self-identifying a portable information device to a computing unit
JP2000514584A (ja) 1996-10-25 2000-10-31 シュルンベルジェ システーム 高級プログラミング言語を用いたマイクロコントローラ
DE69827405T2 (de) 1997-03-24 2005-05-19 Visa International Service Association, Foster City System und verfahren für eine mehrzweckchipkarte die eine nachträgliche speicherung einer anwendung auf dieser karte ermöglicht
US6220510B1 (en) * 1997-05-15 2001-04-24 Mondex International Limited Multi-application IC card with delegation feature
US6349336B1 (en) * 1999-04-26 2002-02-19 Hewlett-Packard Company Agent/proxy connection control across a firewall
US6292874B1 (en) * 1999-10-19 2001-09-18 Advanced Technology Materials, Inc. Memory management method and apparatus for partitioning homogeneous memory and restricting access of installed applications to predetermined memory ranges

Also Published As

Publication number Publication date
JP2003518279A (ja) 2003-06-03
EP1190316B1 (de) 2004-06-16
HK1041333A1 (zh) 2002-07-05
CN1290009C (zh) 2006-12-13
EP1445699A3 (de) 2006-11-15
WO2000045262A2 (en) 2000-08-03
US6907608B1 (en) 2005-06-14
DE60011615D1 (de) 2004-07-22
CN1338071A (zh) 2002-02-27
AU4165700A (en) 2000-08-18
KR20010103747A (ko) 2001-11-23
DE60011615T2 (de) 2005-07-07
ATE269558T2 (de) 2004-07-15
EP1190316A2 (de) 2002-03-27
EP1190316B2 (de) 2015-08-05
JP4716573B2 (ja) 2011-07-06
WO2000045262A3 (en) 2001-01-25
US20050102679A1 (en) 2005-05-12
US7395535B2 (en) 2008-07-01
AU763958B2 (en) 2003-08-07
KR100687668B1 (ko) 2007-02-28
DE1190316T1 (de) 2003-03-06
EP1445699A2 (de) 2004-08-11

Similar Documents

Publication Publication Date Title
DE60011615T3 (de) Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen
DE60006217T3 (de) Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von einem eingangspunktobjekt
DE60010433T2 (de) Verfahren zur durchführung von sicherheitvorgaben in einem kleingerät unter verwendung von einer kontextsperre
DE60002687T2 (de) Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von laufzeitumgebungsprivilegien
DE69731714T2 (de) Dynamische Dienstklassen für eine internationale kryptographische Struktur
DE60018505T2 (de) Vertraute Überprüfung von Rechnerprogrammodulen
AU773772B2 (en) Techniques for permitting access across a context barrier in a small footprint device using shared object interfaces
AU2004200537A1 (en) Techniques for implementing security on a small footprint device using a context barrier
AU2004200637A1 (en) Techniques for permitting access across a context barrier on a small footprint device using run time environment privileges

Legal Events

Date Code Title Description
8363 Opposition against the patent