PatentDe  


Dokumentenidentifikation DE69714752T2 15.05.2003
EP-Veröffentlichungsnummer 0932865
Titel VERWENDUNG EINER HOHEN PROGRAMMIERSPRACHE IN EINEM MIKROKONTROLLER
Anmelder Schlumberger Systèmes, Montrouge, FR
Erfinder WILKINSON, J., Timothy, London M20 9JU, GB;
GUTHERY, B., Scott, Belmont, US;
KRISHNA, Ksheerabdhi, Cedar Park, US;
MONTGOMERY, A., Michael, Cedar Park, US
Vertreter Sparing . Röhl . Henseler, 40237 Düsseldorf
DE-Aktenzeichen 69714752
Vertragsstaaten CH, DE, ES, FR, GB, IT, LI, NL, PT
Sprache des Dokument EN
EP-Anmeldetag 22.10.1997
EP-Aktenzeichen 979118338
WO-Anmeldetag 22.10.1997
PCT-Aktenzeichen PCT/US97/18999
WO-Veröffentlichungsnummer 0009819237
WO-Veröffentlichungsdatum 07.05.1998
EP-Offenlegungsdatum 04.08.1999
EP date of grant 14.08.2002
Veröffentlichungstag im Patentblatt 15.05.2003
IPC-Hauptklasse G06F 9/46
IPC-Nebenklasse G07F 7/10   

Beschreibung[de]

Ein Teil der Erfindung dieses Patents enthält Material mit Urheberrechtschutz. Der Inhaber des Urheberrechts hat nichts dagegen einzuwenden, dass jedermann Faksimile-Reproduktionen des Patentdokuments oder der Darstellung des Patents, so wie es in den Patent- und Warenzeichenbüro-Patentdatei- oder Aufzeichnungen erscheint, vornehmen kann, behält sich aber andererseits alle sonstigen Urheberrechte vor.

Hinterrund der Erfindung

Diese Erfindung bezieht sich generell auf das Gebiet der Programmierung und insbesondere auf den Einsatz einer höheren Programmiersprache mit einer Chipkarte oder einem Mikrocontroller.

In der höheren Programmiersprache Java sind geschriebene Software- Anwendungen so konzipiert, dass eine in Java geschriebene Anwendung ohne Änderung auf zahlreichen verschiedenen Computer-Marken oder Computer-Plattformen lauffähig ist. Dies wird durch folgendes Verfahren ermöglicht. Nachdem eine Java-Anwendung geschrieben ist, wird sie in Byte- Codes enthaltende Klassendateien, bei welchen es sich um Anweisungen für einen hypothetischen Computer, die sogenannte Java Virtual Machine (JVM), handelt, kompiliert. Eine Implementierung dieser virtuellen Maschine wird für jede unterstützte Plattform geschrieben. Wenn ein Benutzer eine besondere Java-Anwendung auf einer bestimmten Plattform ablaufen lassen möchte, werden die kompilierten Klassendateien der gewünschten Anwendung auf die gewählte Plattform geladen. Die Java Virtual Machine für die gewählte Plattform läuft ab und übersetzt die Byte-Codes in der Klassendatei, wodurch die Java-Applikation effektiv abläuft.

Java ist in folgenden Referenzdokumenten beschrieben, welche hier mit ihrer Bezugsnummer eingebunden sind: (1) Arnold, Ken und James Gosling, "The Java programming Language", Addison-Weslay, 1996; (2) James Gosling, Bill Joy und Guy Steele, "The Java Language Specification, "Sun Microsystems, 1966 (Website:

http://java.sun.com/doc/language specification); (3) James Gosling und Henry McGilton.,, The Java Language Environment: A White Paper", Sun Microsystems, 1995 (Website:

http://java.sun.com/doc/language-environment/) und (4) Tim Lindholm und Frank Yellin, "The Java Virtual Machine Specification", Addison-Wesley, 1997. Diese aus vielen weiteren Literaturquellen gewählten Texte beschreiben, wie die Programmierung mit Java auszuführen ist.

Damit eine Java-Applikation auf einer spezifischen Plattform ablauffähig ist, muss eine Java Virtual Machine-Implementierung geschrieben werden, welche innerhalb der Plattform-Vorgaben funktioniert, und zum Laden der gewünschten Java-Applikation auf die Plattform ein Mechanismus geliefert werden, welcher ebenfalls den Vorgaben dieser Plattform Rechnung trägt.

Typische herkömmliche Plattformen, welche Java unterstützen, sind mikroprozessorbasierte Computer mit Zugriff auf relativ hohe Mengen an Speicher und Festplatten-Speicherplatz. Solche Mikroprozessor- Implementierungen kommen häufig bei Desktop-Computern und PCs zum Einsatz. Es gibt aber keine herkömmlichen Java-Implementierungen für Mikrocontroller, die typischerweise in einer Chipkarte angewandt würden.

Mikrocontroller unterscheiden sich in vielem von Mikroprozessoren. Typisch für einen Mikroprozessor ist beispielsweise eine Zentraleinheit (CPU), welche bestimmte externe Komponenten benötigt (Speicher, Eingabe- Kontrollen und Ausgabe-Kontrollen), um einwandfrei lauffähig zu sein. Ein typischer Mikroprozessor kann auf Speicher von 1 Megabyte bis 1 Gigabyte zugreifen und ist in der Lage 16, 32 oder 64 Datenbits oder mehr mit einer einzigen Instruktion zu verarbeiten. Im Gegensatz zum Mikroprozessor beinhaltet ein Mikrocontroller eine CPU, Speichereinheit und sonstige Funktionselemente auf einem einzigen Haltleitersubstrat oder einem einzigen integrierten Schaltkreis (d. h. einem "Chip"). Im Vergleich zur relativ großen externen Speichereinheit, auf die der Mikroprozessor zugreift, haben typische Mikrocontroller auf einen viel kleineren Speicher Zugriff. Ein typischer Mikrocontroller kann auf eine eingebaute Speichereinheit von einem bis vierundsechzig Kilobyte zugreifen, wobei sechzehn Kilobyte sehr üblich sind.

Im allgemeinen kommen drei verschiedene Speicherarten zum Einsatz: Schreib-Lese-Speicher mit wahlfreiem Zugriff (RAM), Festwertspeicher (ROM) und elektrisch löschbare programmierbare Festwertspeicher (EEPROM). In einem Mikrocontroller wird die Menge jeder verfügbaren Speicherart von der Platzmenge auf dem für jede Speicherart verwendeten integrierten Schaltkreis (integrated circuit) vorgegeben. RAM benötigt typischerweise den meisten Platz und ist nicht reichlich vorhanden. ROM benötigt den geringsten Platz und ist reichlich vorhanden. EEPROM ist reichlicher vorhanden als RAM, aber nicht so viel wie ROM.

Jede Speicherart eignet sich für verschiedene Zwecke. ROM ist zwar der billigste Speicher, kann jedoch nur für Daten verwendet werden, die nicht mehr geändert werden sollen, beispielsweise als Betriebssystemcode. EEPROM ist zur Speicherung von Daten, welche erhalten bleiben müssen, wenn die Versorgungsspannung unterbrochen wird, nützlich, aber äußerst langsam zu beschreiben. RAM kann bei hoher Geschwindigkeit beschrieben und gelesen werden, ist aber teuer, und die RAM-Daten gehen verloren, wenn die Versorgungsspannung unterbrochen wird.

Ein typisches Mikroprozessorsystem hat relativ wenig ROM und EEPROM sowie 1 bis 128 Megabyte RAM, da es keinen Vorgaben durch das, was auf eine einzige integrierte Schaltkreisvorrichtung passt, unterliegt und oft Zugriff auf ein externes Plattenspeichersystem hat, welches - kostengünstiger als ein EEPROM - als großer, beschreibbarer, nichtflüchtiger Speicherbereich dient. Ein Mikrocontroller hat jedoch typischerweise nur 0,1 bis 2,0 K RAM, 2 K bis 9 K EEPROM und 8 K bis 56 K ROM.

Wegen der geringen Anzahl benötigter externer Komponenten und ihrer kleinen Größe werden Mikrocontroller häufig in Integrated Circuit Cards, wie Chipkarten, verwendet. Solche Chipkarten gibt es in vielfältigen Formen und umfassen kontaktbasierte Karten, die in einen zu verwendenden Leser eingesteckt werden müssen, und kontaktlose Karten, die nicht eingesteckt zu werden brauchen. Mikrokontroller mit kontaktloser Kommunikation sind in der Tat oft in spezialisierte Formen - wie Uhren und Ringe - eingebettet, welche die Funktionalität einer Chipkarte effektiv auf ergonomische attraktive Weise integrieren.

Wegen der vorgegebenen Umgebung werden Applikationen für Chipkarten typischerweise in einer niedrigen Programmiersprache (z. B. Assembler-Sprache) beschrieben, um Speicher zu bewahren.

Eine Möglichkeit zur Programmierung von Chipkarten anhand einer höheren Programmiersprache wird in der französischen Patentanwendung Nr. 90 118 18 mit dem Titel "Portables Support-Medium für einen leicht programmierbaren Mikroschaltkreis und ein Programmierverfahren für besagten Mikroschaltkreis", Publikation Nr. 2.667,171, beschrieben. Diese Patentanwendung spricht jedoch keine Datensicherheitsthemen an, beschreibt nicht, wie man einen nicht berechtigten Zugriff auf die Daten und Information der Chipkarte verhindert oder wie eine Programmierungsumgebung beigestellt werden kann, die einen Programmierer befähigt, ein Programm für eine Chipkarte in einer Programmiersprache wie JAVA zu erstellen und das Programm trotz allem mittels einem Interpreter auf der Chipkarte, welcher innerhalb der Ausführungsvorgaben der Chipkarte arbeitet, ausführen kann.

Die Integrated Circuit Card ist eine sichere, robuste, verfälschungssichere und portable Vorrichtung zur Speicherung von Daten. Wegen ihrer kleinen Größe und ihren einmaligen Hardware- und Software- Datensicherheitsmerkmalen ist die Integrated Circuit Card der persönlichste PC.

Die Integrated Circuit Card und der Mikrocontroller auf der Karte haben als erste Aufgabe, die der auf der Karte gespeicherten Daten zu schützen. Somit hält sich die Integrated Circuit Card-Technologie seit ihrer Erfindung im Jahr 1974 immer noch genau an diese gleichen Sicherheitsgrundlagen. Solche Karten wurden anfangs von den französischen Banken als Debet-Karten verwendet. Bei dieser Anwendung wird eine finanzielle Transaktion anhand der Karte erst genehmigt, nachdem der Kartenbenutzer zusätzlich zur Tatsache, dass er die Karte besitzt, die Kenntnis einer in der Karte gespeicherten 4-stelligen persönlichen Identifikationsnummer (PIN) demonstriert hat. Jede Information, welche zur Entdeckung der PIN-Nummer auf einer verlorenen oder gestohlenen Karte beitrug, wurde für die öffentlichen Verteilung gesperrt. Da in Wirklichkeit niemand sagen konnte, welche Information in dieser Hinsicht hilfreich sein könnte, wurde praktisch jede Information zu Integrated Circuit Cards vorenthalten.

Wegen den Sicherheitsbelangen haben für Integrated Circuit Cards beschriebene Anwendungen einmalige Eigenschaften. Zum Beispiel ist jede Anwendung typischerweise mit einem besonderen Inhaber oder einer besonderen Identität gekennzeichnet. Da für Anwendungen typischerweise eine niedrige Programmiersprache - wie Assembler - verwendet wird, sind die Applikationen für einen besonderen Mikrocontrollertyp beschrieben. Niedrige Programmiersprachen sind so beschaffen, dass sie unberechtigten Applikationen den Zugriff auf Daten auf der Integrated Circuit Card ermöglichen können. Programme, welche für eine Integrated Circuit Card geschrieben sind, werden mit einer besonderen Identität identifiziert, so dass, wenn zwei Identitäten die gleiche Programmierungsfunktion durchführen möchten, zwei Kopien mancher Teile der Applikation auf dem Mikrocontroller der Integrated Circuit Card sein müssen.

Historisch waren Integrated Circuit Cards geschlossene Systeme. Eine Integrated Circuit Card enthielt eine dedizierte Applikation, welche zur Arbeit mit einer spezifischen Terminal-Applikation angefertigt war. Sicherheitsprüfungen in Verbindung mit einer Integrated Circuit Card bestanden im wesentlichen darin, sicherzustellen, dass die Karten- Applikation und die Terminal-Appilkation ein aufeinander abgestimmtes Paar bildeten und dass die Daten auf der Karte gültig waren.

Mit der zunehmenden Popularität der Integrated Circuit Cards wurde klar, dass Benutzer von Integrated Circuit Cards nur ungern für jede Integrated Circuit Card-Anwendung eine andere Integrated Circuit Card für tragen würden. Aus diesem Grunde hat man damit begonnen, multiple Kooperationsapplikationen auf einfachen Provider-Integrated Circuit Cards zu liefern. Eine Zugriffskarte für ein Geldausgabegerät (ATM) und eine Debet-Karte konnten dann beispielsweise auf einer einzigen Integrated Circuit Cards-Plattform nebeneinander bestehen. Nichtsdestoweniger handelte es sich weiterhin um ein geschlossenes System, da alle Applikationen im Terminal und der Karte von einem Provider, welcher explizite Kenntnis von den übrigen Providern hatte, erstellt wurden.

Der Mangel an Information zu Integrated Circuit Cards - insbesondere Information darüber, wie man mit ihnen kommunizieren und wie man sie programmieren konnte - hat die allgemeine Anwendung der Integrated Circuit Card erschwert. Doch die Einführung öffentlicher Digitalnetzwerke (wie das Internet und Word Wide Web) hat Integrated Circuit Cards neue Anwendungsgebiete eröffnet. Dies hat insbesondere zu einem Ladebedarf neuer Anwendungen - welche explizit nichts von den sonstigen Providern wussten - auf die Karte geführt, jedoch ohne, dass die Kartensicherheit kompromittiert werden konnte. Allerdings können hierzu typischerweise kein herkömmlichen Karten, die in niedrigen Sprachen programmiert sind, verwendet werden.

Zusammenfassung der Erfindung

Generell ist die Erfindung in bezug auf einen Aspekt durch eine Integrated Circuit Card zur Verwendung mit einem Terminal charakterisiert. Zur Integrated Circuit Card gehört ein Speicher zur Speicherung eines Interpreters und eine Applikation in einem höheren Programmiersprachenformat. Ein Prozessor der Karte ist so konfiguriert, dass der Interpreter zur Übersetzung der Applikation für die Ausführung und ein Übertragungsgerät der Karte zur Kommunikation mit dem Terminal verwendet wird.

Zu den Vorteilen der Erfindung gehören unter anderem einer oder mehrere der folgenden Vorteile. Neue Applikationen lassen sich, ohne die Sicherheit der Chipkarte zu kompromittieren, auf eine Chipkarte herunterladen. Solche Applikationen können von verschiedenen Firmen zu verschiedenen Zeiten und durch Nutzung verschiedener Terminals beigestellt werden. Die Sicherheit wird nicht kompromittiert, denn alle Codes oder Daten der Applikationen sind durch die von der Java Virtual Machine gebotenen Sicherheits-Features gegen nicht berechtigten Zugriff geschützt. Chipkartenapplikationen können in höheren Programmiersprachen wie Java und Eiffel erstellt werden mit Hilfe von leistungsstarken, etablierten Programmentwicklungs-Tools. Die Prototypen neuer Applikationen können schnell erstellt und in ein paar Stunden auf eine Chipkarte heruntergeladen werden, ohne Soft-Masken anzuwenden. Eingebettete Systeme mit Mikrocontroller können ebenfalls zahlreiche dieser Vorteile im Rahmen dieser Erfindung zum Download neuer Applikationen, Entwicklung von Hochsprachenprogrammen und zur schnellen Erstellung von Prototypen nutzen.

Implementierungen der Erfindung können einen oder mehrere der folgenden Punkte einbinden. Das höhere Programmiersprachenformat der Anwendung kann ein Klassendateiformat, aber auch ein Programmiersprachenformat in Java haben. Der Prozessor kann ein Mikrocontroller sein. Mindestens ein Speicherteil kann sich im Prozessor befinden.

Die Applikation kann von einer zweiten Applikation aus einer Zeichenkette (String) verarbeitet worden sein, und die Zeichenkette kann in der ersten Anwendung durch einen Bezeichner (z. B. eine Ganzzahl) dargestellt worden sein.

Der Prozessor kann außerdem so konfiguriert sein, dass er eine Anforderung von einem Anforderer (z. B. einem Prozessor oder einem Terminal) empfängt, um auf ein Element (z. B. eine im Speicher gespeicherte Applikation, im Speicher gespeicherte Daten oder der Communicator) der Karte zuzugreifen, nach dem Empfang der Anforderung mit dem Anforderer zur Authentifizierung einer Identität des Anforderders interaktiv zu arbeiten und auf der Basis der Identität, den Zugriff auf das Element selektiv zu gewähren.

Der Speicher kann ferner für das Element eine Zugriffsprüfungsliste speichern. Die Zugriffsprüfungsliste liefert eine Angabe zu den der Identität zu gewährenden Zugriffstypen, und der Prozessor gewährt dem Anforderer spezifische Zugriffsarten (z. B. Daten auslesen, Daten einschreiben, Daten hinzufügen, Daten erstellen, Daten löschen oder eine Applikation ausführen) auf selektive Weise anhand der Zugriffsprüfungsliste.

Die Applikation kann eine von mehreren im Speicher gespeicherten Applikationen sein. Der Prozessor kann ferner so konfiguriert werden, dass er eine Anforderung von einem Anforderer für den Zugriff auf eine der vielfältigen Applikationen empfängt; nach dem Empfang der Anforderung ermittelt, ob besagte Applikation aus der Vielzahl von Applikationen mit einem vorbestimmten Satz Regeln übereinstimmt und auf der Basis der Vorbestimmung dem Anforderer einen selektiven Zugriff auf eine der Vielzahl von Applikationen gewährt. Die vorbestimmten Regeln dienen als Anleitung zur Bestimmung, ob besagte Applikation aus der Vielzahl von Applikationen auf einen vorbestimmen Speicherbereich zugreift. Der Prozessor kann des weiteren zur Authentifizierung einer Identität des Anforderers konfiguriert sein und den Zugriff auf besagte Applikation aus der Vielzahl von Applikationen auf Basis der Identität gewähren.

Der Prozessor kann auch zur Interaktion mit dem Terminal über den Communicator konfiguriert sein, um eine Identität zu authentifizieren, zu ermitteln, ob die Identität authentifiziert wurde, und die selektive Kommunikation zwischen dem Terminal und der Integrated Circuit Card auf der Basis der Ermittlung erlauben.

Der Communicator und das Terminal können über die Kommunikationskanäle kommunizieren. Der Prozessor kann ferner so konfiguriert sein, dass er der Identität eine der Kommunikationskanäle zuweist, sobald der Prozessor die Kommunikation zwischen dem Terminal und der Integrated Circuit Card erlaubt. Der Prozessor kann auch so konfiguriert sein, dass er dem zugewiesenen Kommunikationskanal einen Sitzungsschlüssel zuordnet, wenn der Prozessor und das Terminal über den zugewiesenen Kommunikationskanal kommunizieren.

Das Terminal kann einen Kartenleser haben und der Communicator einen Kontakt zur Kommunikation mit dem Kartenleser. Das Terminal kann eine drahtlose Kommunikationsvorrichtung haben und der Communicator einen drahtlosen Transceiver zur Kommunikation mit der drahtlosen Kommunikationsvorrichtung. Das Terminal kann eine drahtlose Kommunikationsvorrichtung haben und der Communicator einen drahtlosen Transmitter zur Kommunikation mit der drahtlosen Kommunikationsvorrichtung.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Methode, die mit einer Integrated Circuit Card und einem Terminal verwendet werden kann. Die Methode beinhaltet die Speicherung eines Interpreters und mindestens eine Applikation mit einem höheren Programmiersprachenformat in einem Speicher der Integrated Circuit Card. Ein Prozessor der Integrated Circuit Card verwendet den Interpreter, um mindestens eine auszuführende Applikation zu übersetzen, und der Prozessor verwendet einen Communicator der Karte für die Kommunikation zwischen dem Prozessor und dem Terminal.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Chipkarte. Die Chipkarte beinhaltet einen Speicher zur Speicherung eines Java-Interpreters und eines Prozessors, welcher zur Verwendung des Interpreters für die Übersetzung einer auszuführenden Java-Applikation konfiguriert ist.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für einen Mikrocontroller, welcher ein Halbleitersubstrat und einen im Substrat implantierten Speicher hat. Ein Programmiersprachen-Interpreter ist im Speicher gespeichert und zur Implementierung von Sicherheitsprüfungen konfiguriert. Eine Zentraleinheit ist im Substrat implantiert und an den Speicher gekoppelt.

Die Erfindung kann eine oder mehrere der folgenden Implementierungen beinhalten. Der Interpreter kann ein Interpreter von Byte-Code in Java sein. Die Sicherheitsprüfungen können den Aufbau von Firewalls beinhalten sowie die Durchsetzung eines Sandbox- Sicherheitsmodells.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Chipkarte, welche einen in einem Speicher der Karte gespeicherten Programmiersprachen-Interpreter hat. Der Interpreter ist zur Implementierung von Sicherheitsprüfungen konfiguriert. Eine Zentraleinheit der Karte ist an den Speicher gekoppelt.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Integrated Circuit Card, welche mit einem Terminal verwendet wird. Die Karte beinhaltet einen Communicator und einen Speicher, welcher einen Interpreter und eine erste Anweisung einer ersten Applikation speichert. Die ersten Anweisungen wurden aus zweiten Anweisungen einer zweiten Applikation umgesetzt. Die Integrated Circuit Card beinhaltet einen Prozessor, welcher an den Speicher gekoppelt ist und zur Verwendung des Interpreters für die Ausführung der ersten Anweisungen sowie zur Kommunikation mit dem Terminal über den Communicator konfiguriert ist.

Die Erfindung kann eine oder mehrere der folgenden Implementierungen beinhalten. Die ersten und/oder zweiten Applikationen können (ein) Klassendateiformat(e) haben. Die ersten und/oder zweiten Applikationen können Byte-Codes - wie Byte-Codes in Java - beinhalten. Die ersten Anweisungen können verallgemeinerte oder neubezifferte Versionen der zweiten Anweisungen sein. Die zweiten Anweisungen können konstante Referenzen beinhalten, und die ersten Anweisungen können Konstanten beinhalten, welche die konstanten Referenzen der zweiten Anweisungen ersetzen. Die zweiten Anweisungen können Referenzen beinhalten, und die Stelle der Referenzen kann während der Konvertierung der zweiten Anweisungen in die ersten Anweisungen verschoben werden. Die ersten Anweisungen können nach der Verschiebung wieder mit den Referenzen verknüpft werden. Die ersten Anweisungen können Byte-Codes für einen ersten virtuellen Maschinentyp beinhalten, und die zweiten Anweisungen können Byte-Codes für einen zweiten virtuellen Maschinentyp beinhalten. Der erste Typ unterscheidet sich vom zweiten Typ.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Methode zur Verwendung mit einer Integrated Circuit Card. Die Methode beinhaltet die Konvertierung von zweiten Anweisungen einer zweiten Applikation in erste Anweisungen einer ersten Applikation, die Speicherung der ersten Anweisungen in einem Speicher der Integrated Circuit Card und die Verwendung eines Interpreters der Integrated Circuit Card zur Ausführung der ersten Anweisungen.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für einen integrierten Schaltkreis zur Verwendung mit einem Terminal. Die Integrated Circuit Card hat einen Communicator, welcher zur Kommunikation mit dem Terminal und einem Speicher, der eine aus einer zweiten Applikation mit einer Zeichenkette verarbeitete erste Applikation speichert, konfiguriert ist. Die Zeichenkette wird durch einen Bezeichen in der ersten Applikation dargestellt. Die Integrated Circuit Card beinhaltet einen Prozessor, welche an den Speicher gekoppelt ist. Der Prozessor ist zur Verwendung des Interpreters für die Übersetzung der ersten auszuführenden Applikation und zur Verwendung des Communicators zur Kommunikation mit dem Terminal konfiguriert.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Methode zur Verwendung mit einer Integrated Circuit Card und einem Terminal. Die Methode beinhaltet die Verarbeitung einer zweiten Applikation zur Erstellung einer ersten Applikation. Die zweite Applikation hat eine Zeichenkette. Die Zeichenkette wird durch einen Bezeichner in der zweiten Applikation dargestellt. Ein Interpreter und die erste Applikation sind in einem Speicher der Integrated Circuit Card gespeichert. Ein Prozessor verwendet einen Interpreter zur Übersetzung der ersten auszuführenden Applikation.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für einen Mikrocontroller, welcher einen Speicher, der eine Applikation und einen Interpreter speichert, beinhaltet. Die Applikation hat ein Dateiklassenformat. Ein Prozessor des Mikrocontrollers ist an den Speicher gekoppelt und zur Verwendung des Interpreters für die Übersetzung der auszuführenden Applikation konfiguriert.

In Implementierungen der Erfindung kann der Mikrocontroller auch einen Communicator beinhalten, welcher zur Kommunikation mit einem Terminal konfiguriert ist.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Methode zur Verwendung mit einer Integrated Circuit Card. Die Methode beinhaltet die Speicherung einer ersten Applikation in einem Speicher der Integrated Circuit Card, die Speicherung einer zweiten Applikation im Speicher der Integrated Circuit Card und die Erstellung einer Firewall, welche die erste und zweite Applikation trennt, so dass die zweite Applikation weder auf die erste Applikation noch auf die zur ersten Applikation gehörenden Daten zugreifen kann.

Generell ist die Erfindung in anderer Hinsicht kennzeichnend für eine Integrated Circuit Card zur Verwendung mit einem Terminal. Die Integrated Circuit Card beinhaltet einen Communicator, welcher zur Kommunikation mit dem Terminal konfiguriert ist, einen Speicher und einen Prozessor. Der Speicher speichert Applikationen, und jede Applikation hat ein höheres Programmiersprachenformat. Der Speicher speichert ferner einen Interpreter. Der Prozessor ist an den Speicher gekoppelt und konfiguriert zur: a) Verwendung des Interpreters für die Übersetzung der auszuführenden Applikationen, b) Verwendung des Interpreters zur Erstellung einer Firewall, um die Applikationen voneinander zu trennen und zur c) Verwendung des Communicators zur Kommunikation mit dem Terminal.

Weitere Vorteile und Features werden anhand der folgenden Beschreibung und aus den Patentansprüchen ersichtlich.

Kurzbeschreibung der Zeichnung

Abb. 1 ist ein Blockdiagramm eines integrierten Kartensystems.

Abb. 2 ist ein Flussbild, welches die Vorbereitung von Java- Applikationen, die auf eine Integrated Circuit Card heruntergeladen werden sollen, veranschaulicht.

Abb. 3 ist ein Blockdiagramm der verwendeten Dateien und welche vom Klassendatei-Konverter der Karte erzeugt werden.

Abb. 4 ist ein Blockdiagramm, welches die Umwandlung einer (von) Klassendatei(en) der Applikation in eine Karten-Klassendatei veranschaulicht.

Abb. 5 ist ein Flussbild, welches das Funktionieren des Klassendatei- Konverters veranschaulicht.

Abb. 6 ist ein Flussbild, welches die Änderung der Byte-Codes veranschaulicht.

Abb. 7 ist ein Blockdiagramm, welches die Umwandlung spezifischer Byte-Codes in allgemeine Byte-Codes veranschaulicht.

Abb. 8 ist ein Blockdiagramm, welches den Austausch konstanter Referenzen mit Konstanten veranschaulicht.

Abb. 9 ist ein Blockdiagramm, welches den Austausch von Referenzen mit ihren aktualisierten Werten veranschaulicht.

Abb. 10 ist ein Blockdiagramm, welches die Neubezifferung von Original-Byte-Codes veranschaulicht.

Abb. 11 ist ein Blockdiagramm, welches die Übersetzung von Original- Byte-Codes für eine verschiedene virtuelle Maschinenarchitektur veranschaulicht.

Abb. 12 ist ein Blockdiagramm, welches das Laden von Applikationen in eine Integrated Circuit Card veranschaulicht.

Abb. 13 ist ein Blockdiagramm, welches die Ausführung von Applikationen in einer Integrated Circuit Card veranschaulicht

Abb. 14 ist eine schematische Darstellung, welche die Speicherorganisation für ROM, RAM und EEPROM veranschaulicht.

Abb. 15 ist ein Flussbild, welches die Gesamtarchitektur der Card Java Virtual Machine veranschaulicht.

Abb. 16 ist ein Flussbild, welches die Ausführungsmethode in der Karte Java Virtual Machine mit den Sicherheitsprüfungen veranschaulicht.

Abb. 17 ist ein Flussbild, welches die Byte-Code-Ausführung in der Card Java Virtual Machine veranschaulicht.

Abb. 18 ist ein Flussbild, welches die Ausführungsmethode in der Card Java Virtual Machine ohne Sicherheitsprüfungen veranschaulicht.

Abb. 19 ist ein Blockdiagramm, welches die Verknüpfung zwischen Kartenapplikationen und Identitäten veranschaulicht.

Abb. 20 ist ein Blockdiagramm, welches die Zugriffsrechte einer spezifischen Laufapplikation veranschaulicht.

Abb. 21 ist eine perspektivische Darstellung eines Mikrocontrollers auf einer Chipkarte.

Abb. 22 ist eine perspektivische Darstellung eines Mikrocontrollers auf einem Telefon.

Abb. 23 ist eine perspektivische Darstellung eines Mikrocontrollers auf einem Schlüsselring.

Abb. 24 ist eine perspektivische Darstellung eines Mikrocontrollers auf einem Ring.

Abb. 25 ist eine perspektivische Darstellung eines Mikrocontrollers auf einer Schaltkreiskarte eines Automobils.

Detaillierte Beschreibung der bevorzugten Realisierungen

Bei Abb. 1 ist eine Integrated Circuit Card 10 (z. B. eine Chipkarte) zur Lieferung einer multiplen, Java-basierten, High-Level- Applikationsprogrammier- und Ausführungsumgebung aufgebaut. Die Integrated Circuit Card 10 hat einen Communicator 12a, welcher zur Kommunikation mit einem Terminal-Communicator 12b eines Terminals 14 konfiguriert ist. Bei manchen Realisierungen ist die Integrated Circuit Card 10 eine Chipkarte mit einem 8-Bit-Microcontroller, 512 Byte RAM, 4KByte EEPROM und 20 K ROM; der Terminal-Communicator 12b ist ein herkömmlicher kontaktbehafteter Chipkartenleser, und das Terminal 14 ist ein herkömmlicher PC, welcher mit dem Betriebssystem Windows NT, das den Standard der PC-Chipkarte (PC/SC) unterstützt und den Java- Entwicklungssupport liefert.

Bei manchen Realisierungen sind der Mikrocontroller, Speicher und Communicator in eine Kunststoffkarte implantiert, welche größtenteils die gleichen Abmessungen wie eine typische Kreditkarte aufweist. Bei anderen Realisierungen sind der Mikrocontroller, Speicher und Communicator innerhalb anderer Basisträger als Kunststoffkarten montiert, wie bei Juwelierarbeiten (z. B. Uhren, Ringe oder Armbänder), Autoausrüstungen, Telekommunikationsausrüstungen (z. B. Teilnehmer-Identitätsmodul-Karten, Sicherheitsvorrichtungen (z. B. Chiffriermodule) und Geräten.

Das Terminal 14 dient zur Vorbereitung und zum Download von Java- Applikationen auf die Integrated Circuit Card 10 mit Hilfe des Terminal- Communicators 12b. Der Terminal-Communicator 12b ist eine Kommunikationsvorrichtung, welche Kommunikationskanäle zwischen der Integrated Circuit Card 10 und dem Terminal 14 aufbauen kann. Manche Kommunikationsoptionen beinhalten kontaktbehaftete Kartenleser, drahtlose Kommunikationen über Funkfrequenz oder Infrarot-Techniken, serielle Kommunikationsprotokolle, Paket-Kommunikationsprotokolle, das ISO 7817-Kommunikationsprotoll, um nur ein paar zu nennen.

Das Terminal 14 kann auch mit den auf der Integrated Circuit Card 10 laufenden Applikationen im Dialogbetrieb stehen. In bestimmten Fällen kommen zu diesem Zweck andere Terminals zum Einsatz. Man kann beispielsweise eine Art Terminal zur Vorbereitung von Applikationen, andere Terminals zum Download der Applikationen und noch andere Terminals für den Betrieb der verschiedenen Applikationen verwenden. Die Terminals können Geldausgabegeräte (ATM), Verkaufsstellen-Terminals, Türsicherheitssysteme, Gebührenzahlungssysteme, Zugriffskontrollsysteme oder jegliche sonstige Systeme, welche mit einer Integrated Circuit Card oder einem Mikrocontroller kommunizieren, sein.

Die Integrated Circuit Card 10 enthält eine Card Java Virtual Machine 16(Card JVM), welche zur Übersetzung von auf der Karte 10 enthaltenen Applikationen verwendet wird.

Bei Abb. 2 beinhaltet die Java-Applikation 20 drei Java- Quellcodedateien: A.java 20a, B.java 20b und C.java 20c. Diese Quellcodedateien werden in einer Java-Entwicklungsumgebung 22 vorbereitet und kompiliert. Nachdem die Java-Applikation 20 durch die Entwicklungsumgebung 22 kompiliert ist, werden Klassendateien 24 der Applikation mit diesen Klassendateien A.class 24a, B.clas 24b und C.class 24c, welche ihrem jeweiligen Klasses-Java-Quellcode 20a, 20b und 20c entsprechen. Die Klassendateien 24 der Applikation beachten das standardmäßige Klassendateiformat, so wie in Kapitel 4 der Spezifikation zur Java Virtual Machine von Tim Lindholm und Frank Yellin "The Java Virtual Machine Specification", Addison-Weslay, 1996 dokumentiert. Diese Klassendateien 24 der Applikation werden in den Klassendatei-Konverter 26 der Karte eingeführt, welcher die Dateien konsolidiert und komprimiert, wodurch eine einzige Kartenklassendatei erzeugt wird. Die Kartenklassendatei 27 wird in die Integrated Circuit Card 10 mit Hilfe eines herkömmlichen Kartenladers 28 geladen.

Bei Abb. 3 ist der Dateiklassen-Konverter 26 ein Dateiklassenpostprozessor, welcher ein Set von Klassendateien 24 verarbeitet, die im standardmäßigen Java-Klassendateiformat codiert sind, das optional eine Zeichenkette zur ID Input Map-Datei 30 verwendet, um eine Klassendatei 27 der Java-Karte in einem Karten-Klassendateiformat zu erzeugen. Ein solches Karten-Klassendateiformat ist im Anhang A beschrieben. Darüber hinaus erzeugt der Karten-Klassendatei-Konverter 26 eine Zeichenkette zur ID Output-Map-Datei 32, welches als Input für eine weitere Ausführung des Karten-Klassendatei-Konverters dient.

Damit die Zeichenkette zur ID-Aufgliederung mit einer zuvor generierten Karten-Klassendatei (falls sich multiple Klassendateien auf dieselben Zeichenketten beziehen) konsistent ist, kann bei manchen Realisierungen der Karten-Klassendatei-Konverter 26 eine zuvor definierte Zeichenkette zu ID-Aufgliederungen von einer Zeichenkette zur ID Input Map-Datei 30 akzeptieren. Fehlt eine solche Datei, werden die IDs über den Karten-Klassendatei-Konverter 26 generiert. Anhang B beschreibt eine mögliche Weise zur Implementierung und Erzeugung der Zeichenkette zur ID Input Map-Datei 30 sowie der Zeichenkette zur ID Output Map-Datei 32 und veranschaulicht diese Aufgliederung anhand eines Beispiels.

Bei Abb. 4 beinhaltet eine typische Applikations-Klassendatei 24a Klassendatei-Information 41, einen Konstantenpool 42 der Klasse, Klassen, erstellte Felder, referenzierte Schnittstellen sowie Methodeninformation 43 und unterschiedliche Attributinformation 44 gemäss den Details der zuvor erwähnten Java Virtual Machine Specification. Es wird darauf hingewiesen, dass ein großer Teil der Attributinformation 44 nicht für diese Realisierung benötigt und über den Karten-Klassendatei-Konverter 26 entfernt 45 wird. Entfernte Attribute beinhalten SourceFile, ConstantValue, Exceptions, LineNumberTable, LocalVariableTable und alle beliebigen Vendor-Attribute. Die typische Karten-Klassendatei 27 gemäss der Beschreibung von Anhang A ist von den Appllkations-Klassendateien 24 auf folgende Weise abgeleitet. Die Karten-Klassendatei-Information 46 ist vom Datenverbund Klassendatei- Information 41 aller Applikations-Klassendateien 24a, 24b und 24c abgeleitet. Der Karten-Klassendatei-Konstantenpool 47 ist vom Datenverbund Klassen-Konstantenpool 42 aller Applikations-Klassendateien 24a, 24b und 24c abgeleitet. Die Kartenklassen, erstellten Felder, referenzierten Schnittstellen und Informationsmethode 48 sind vom Datenverbund Klasse, erstellte Felder, referenzierte Schnittstellen und Methodeninformation 43 aller Appilkations-Klassendateien 24a, 24b und 24c abgeleitet. Die Karten-Attributinformation 49 in dieser Realisierung ist nur vom Attributcode des Datenverbunds Attributinformation 44 aller Applikationsklassendateien 24a, 24b und 24c abgeleitet.

Um dynamische Verknüpfungen in der Karte zu vermeiden, ist die über verschiedene Java-Klassendateien 24a, 24b und 24c, welche die Applikation 24 bilden, verteilte Information, durch den Prozess im Flussbild von Abb. 5 zu einer Karten-Klassendatei 27 zusammengefasst. Die erste zu verarbeitende Klassendatei ist ausgewähltet 51a. Der Konstantenpool 42 wird auf folgende Weise komprimiert 51b. Alle Objekte, Klassen, Felder, referenzierten Methoden in einer Java-Klassendatei 24a werden durch Verwendung von Zeichenketten im Konstantenpool 42 der Klassendatei 24a identifiziert. Der Karten-Klassendatei-Konverter 26 komprimiert den in der Java-Klassendatei 24a vorgefundenen Konstantenpool 42 in eine optimierte Version. Diese Komprimierung wird durch Aufgliederung aller im Konstantenpool 42 der Klassendatei vorgefundenen Zeichenketten in Ganzzahlen (deren Größe von der Mikrocontroller-Architektur abhängt) erreicht. Solche Ganzzahlen werden auch als IDs bezeichnet. Jede ID identifiziert ausschließlich ein besonderes Objekt, eine besondere Klasse, ein besonderes Feld oder eine besondere Methode in der Applikation 20. Aus diesem Grunde ersetzt der Karten-Klassendatei-Konverter 26 die Zeichenketten im Konstantenpool 42 mit seiner entsprechenden einzigen ID in der Java-Klassendatei. Anhang B zeigt ein Anwendungsbeispiel der HelloSmartCard.java mit einer darunter stehenden Tabelle, welche die IDs, die den im Konstantenpool der Klassendatei für diese Applikation vorgefunden Zeichenketten entsprechen, veranschaulicht. Die IDs in diesem Beispiel sind 15-Bit-Ganzzahlen ohne Vorzeichen.

Anschließend prüft der Karten-Klassendatei-Konverter 26 den Attribut-Code der Klassendatei 24a des Java-Inputs auf nicht unterstützte Features 51c. Die Card JVM 16 unterstützt nur ein Subset der vollständigen Byte-Codes in Java in Übereinstimmung mit der Beschreibung von Anhang C. Der Karten-Klassendatei-Konverter 26 prüft folglich den Attribut-Code der Java-Klassendatei 24a auf nicht unterstützte Byte-Codes. Falls irgendwelche nicht unterstützten Byte-Codes 52 gefunden werden, zeigt die Karten- Klassendatei einen Fehler an und stoppt die Konvertierung 53. Das mit "A" markierte Programmcode-Fragment von Anhang D zeigt, wie diese falschen Byte-Codes erfasst werden. Ein weiterer Prüfschritt kann durch Inanspruchnahme der standardmäßigen Java-Enwicklungsumgebung 22 zur Kompilierung der Applikation 20 mit einer '-g'-Flagge ausgeführt werden. Bei dieser Option muss der Java-Compiler auf der Basis der zuvor erwähnten Java Virtual Machine Specification Information zu den in der Java-Applikation 20 im LocalVariableTable-Attribut der Klassendatei 24a verwendeten Variablen setzen. Der Karten-Klassendatei-Konverter 26 verwendet diese Information zur Überprüfung auf Nichtunterstützung der Datentypen-Referenzen der Java-Klassendateien 24a durch die Java-Karte.

Anschließend verwirft der Karten-Klassendatei-Konverter 26 alle unnötigen Teile 51c der Java-Quelldatei 24a, die nicht für die Übersetzung benötigt werden. Eine Java-Klassendatei 24a speichert Information zu den Byte-Codes in der Klassendatei im Attribut-Abschnitt 44 der Java- Klassendatei. Attribute, welche für die Übersetzung durch die Card JVM 16 nicht benötigt werden - wie SourceFile, ConstantValue, Exceptions, LineNumberTable und LocalVariableTable - können ungefährdet verworfen 45 werden. Das einzige zurückbehaltene Attribut ist das Code-Attribut. Das Code-Attribut enthält die Byte-Codes, welche den Methoden in der Java- Klassendatei 24a entsprechen.

Eine Änderung der Byte-Codes 54 bedingt eine Prüfung der Code- Attributinformation 44 für jede Methode in der Klassendatei und eine Änderung der Operanden von Byte-Codes, welche sich auf die Einsprünge im Konstantenpool 42 der Java-Klassendatei beziehen, um die Eingaben im Konstantenpool 47 der Karten-Klassendatei auszudrücken. Bei manchen Realisierungen werden die Byte-Codes auch gemäss nachstehender Beschreibung geändert.

Eine Änderung der Byte-Codes 54 bedingt fünf Durchläufe (mit zwei optionalen Durchläufen) in Übereinstimmung mit der Beschreibung des Flussbilds von Abb. 6. Die Original-Byte-Codes 60 werden im Code-Attribut 44 der tatsächlich verarbeiteten Java-Klassendatei 24a gefunden. Der erste Durchlauf 61 zeichnet alle Sprünge und ihre Ziele in den Original-Byte- Codes auf. Während der späteren Byte-Code-Übersetzung können manche einfache Byte-Codes in doppelte oder dreifache-Bytes übersetzt werden. Abb. 7 veranschaulicht ein Beispiel, bei welchem Byte-Code ILOAD_0 durch zwei Bytes - Byte-Code ILOAD und Argument 0 - ersetzt wird. Nachdem dies getan ist, ändert sich die Code-Größe, was eine Anpassung aller beliebigen Sprungziele, die zugeordnet sind, erfordert. Aus diesem Grunde müssen die Original-Byte-Codes 60 in bezug auf jeglichen Sprung-Byte-Codes analysiert und ihre Stellung und ihr aktuelles Ziel notiert werden, bevor diese Umwandlungen erfolgen. Das "B"-markierte Programmcode-Fragment im Anhang D zeigt, wie diese Sprünge aufgezeichnet werden.

Sobald alle Sprünge aufgezeichnet sind, kann der Karten- Klassendatei-Konverter 26 auf den dritten Durchlauf 64 übergehen, sofern die optionale Byte-Code-Übersetzung nicht bei 62 ausgeführt wird.

Andernfalls konvertiert der Karten-Klassendatei-Konverter spezifische Byte-Codes in generische Byte-Codes. Die übersetzten Byte-Codes werden typischerweise nicht in der Card JVM 16 interpretiert, sondern durch Konvertierung der Byte-Codes in äquivalente Byte-Codes, welche durch die Card JVM 16 (siehe Abb. 7) übersetzbar sind, unterstützt. Die Byte-Codes 70 können mit anderen semantisch gleichen aber verschiedenen Byte-Codes 72 ersetzt werden. Dies führt im allgemeinen zur Übersetzung von kurzen, einzelnen, spezifischen Byte-Codes - wie ILOAD_0- in ihre mehr allgemeinen Versionen. ILOAD_0 kann beispielsweise durch Byte-Code ILOAD mit einem Argument 0 ersetzt werden. Die Übersetzung wird ausgeführt, um die Anzahl der durch die Card JVM 16 übersetzten Byte-Codes zu mindern und dadurch die Komplexität und Codeplatzanforderungen für die Card JVM 16 zu reduzieren. Das mit "C" markierte Programmcode-Fragment im Anhang D zeigt, wie diese Übersetzungen erfolgen. Es wird darauf hingewiesen, dass solche Übersetzungen die Größe des resultierenden Byte-Codes erhöhen und die Neuberechnung aller zugeordneten Sprünge erzwingen.

Beim dritten Durchlauf 64, baut der Karten-Klassendatei-Konverter wieder neue konstante Referenzen durch Beseitigung der Zeichenkette, welche zur Bezeichnung dieser Konstanten verwendet wurden, auf. Abb. 8 zeigt ein Beispiel, bei welchem der sich auf die Konstante "18" beziehende Byte-Code LDC 80, welcher über einen Index im Konstantenpool 42 der Java-Klassendatei 24a gefunden wurde, in BIPUSH-Byte-Code 82 übersetzt werden kann. Bei diesem Durchlauf ändert der Klassendatei-Konverter 26 der Karte die Operanden zu allen Byte-Codes, die sich auf die Einsprünge in den Java-Dateiklassen-Konstantenpool 42 beziehen, um ihren neuen Platz im Konstantenpool 47 der Karten-Klassendatei wiederzuspiegeln. Abb. 9 zeigt ein Beispiel, bei welchem das Argument zu einem Byte-Code, INVOKESTATIC 90, sich auf den Einsprung in den Java-Dateiklassen- Konstantenpool 42 bezieht, der geändert ist, um seinen neuen Platz im Konstantenpool 147 der Karten-Klassendatei wiederzuspiegeln. Der geänderte Operand 94 zeigt diese Umwandlung. Das mit "D" markierte Programmcode- Fragment im Anhang D zeigt, wie diese Änderungen erfolgen.

Sobald die Konstantenreferenzen wieder verknüpft sind, kann der Karten-Klassendatei-Konverter zum fünften und letzten Durchlauf 67 übergehen, wenn die optionale Byte-Code Umwandlung nicht angewandt wird.

Andernfalls ändert der Karten-Klassendatei-Konverter die Original- Byte-Codes in ein anderes Set von Byte-Codes, welche durch die zum Einsatz kommende besondere Card JVM 16 unterstützt werden. Eine potentielle Änderung sorgt für die Neubezifferung der Original Byte-Codes 60 in Byte-Codes der Card JVM 16 (siehe Abb. 10). Diese Neubezifferung führt dazu, dass die Byte-Codes 100 in den Original-Byte-Codes 60 in neubezifferte Byte-Codes 102 geändert werden. Byte-Code ILOAD, welcher durch den Wert 21 erkannt wird, kann so neubeziffert werden, dass er von Wert 50 erkannt wird. Diese Änderung kann ausgeführt werden, um die Prüfungen von Typen (die gemäss dem Stand der Technik auch als Prüfungen von Durchlauf 3 bekannt sind) in der Card JVM 16 zu optimieren. Das mit "E" markierte Programmcode-Fragment im Anhang D zeigt eine Implementierung dieser Realisierung. Besagte Änderung kann vorgenommen werden, um den von der Card JVM 16 benötigten Programmplatz zur Übersetzung des Byte-Codes zu reduzieren. Im wesentlichen gruppiert diese Änderung die Byte-Codes in den Byte-Codes der Card JVM 16, damit Byte-Codes mit ähnlichen Operanden, Ergebnisse zusammenfasst werden und keine Lücken zwischen Byte-Codes der Card JVM 16 bestehen. Auf diese Weise kann die Card JVM 16 die Byte-Codes der Card JVM 16 effizient prüfen und Typen in dem Masse, wie die Ausführung abläuft, freigeben.

Bei manchen Realisierungen verwandelt der Karten-Klassendatei- Konverter die Original-Byte-Codes 60 in ein anderes Set von Byte-Codes, welche - wie von Abb. 11 veranschaulicht - für eine andere virtuelle Maschinenarchitektur bestimmt sind. Der Java-Byte-Code ILOAD 112, der für den Einsatz auf einem Wort-Stack 114 bestimmt ist, kann durch den auf einem Byte-Stack 118 zu verwendenden Byte-Code ILOAD_B 116 der Card JVM 16 ersetzt werden. Ein Element in einem Wort-Stack 114 erfordert die Zuordnung eines Stack-Platzes von 4 Byte, während ein Element im Byte- Stack 118 nur einen Stack-Platz von 1 Byte benötigt. Obgleich diese Option eine erhöhte Ausführungsgeschwindigkeit bietet, besteht die Gefahr eines Verlusts der in den Original-Byte-Codes verfügbaren Sicherheits-Features.

Da die vorhergehenden Schritte 63, 64 oder 66 die Größe der Byte- Codes 60 geändert haben können, muss der Karten-Klassendatei-Konverter 26 alle davon betroffenen Sprünge wieder verknüpfen 67. Da die Sprünge im ersten Schritt 61 des Karten-Klassendatei-Konverters 26 aufgezeichnet wurden, wird diese Anpassung durch Setzen der Sprungziele auf ihre geeigneten Werte ausgeführt. Das mit "F" markierte Progammcode-Fragment im Anhang D zeigt, wie diese Sprünge gesetzt werden.

Der Karten-Klassendatei-Konverter hat nun alle Byte-Codes 68, welche mit dem ladebereiten Original-Byte-Code gleichwertig sind, geändert. Die Übersetzung von der Java-Klassendatei 24a in die Karten-Klassendatei 27 ist damit beendet.

Um nochmals auf Ab. 5 zurückzukommen, falls mehr Klassendateien 24 zu verarbeiten bleiben 55, werden die vorausgehenden Schritte 51a, 51b, 51c, 52 und 54 für jede verbleibende Klassendatei wiederholt. Der Karten- Klassendatei-Konverter 26 erfasst 56 die Maps und modifizierten Byte-Codes für die Klassen 24, die verarbeitet wurden, setzt sie als einen Datenverbund und erzeugt 57 eine Karten-Klassendatei 27. Der Karten-Klassendatei- Konverter 26 generiert nötigenfalls eine Zeichenkette zur ID Output Map- Datei 32, welche eine Liste aller neuen IDs enthält, die für die im Konstantenpool 42 der Java-Klassendateien 24 während der Übersetzung angetroffenen Zeichenketten zugewiesen wurden.

Bei Abb. 12 sendet der Kartenlader 28 innerhalb des Terminals 14 eine Karten-Klassendatei zur Lade- und Ausführungskontrolle 120 in der Integrated Circuit Card mit Hilfe der standardmäßigen ISO 7816-Befehle. Die Lade- und Ausführungskontrolle 120 hat ein Kartenbetriebssystem 122, welches die erforderlichen Systemressourcen liefert, einschließlich den Support für ein Kartendateisystem 124, welches zur Speicherung verschiedener Kartenapplikationen 126 verwendet werden kann. Zahlreiche herkömmliche Kartenleser sind in niedrigen Sprachen geschrieben, welche von dem Kartenbetriebssystem 122 unterstützt werden. Bei der bevorzugten Realisierung ist der Bootstrap-Lader in Java geschrieben, und die Integrated Circuit Card 10 beinhaltet eine Java Virtual Machine, dank welcher diese Applikation lauffähig ist. Eine Java-Implementierung der Lade- und Ausführungskontrolle 120 ist im Anhang E gezeigt. Die Java- Implementierung der Lade- und Ausführungskontrolle 120 empfängt die Karten-Klassendatei 26 und erzeugt eine Java Card-Applikation 126x, welche im Kartendateisystem 126 im EEPROM der Integrated Circuit Card 10 gespeichert ist. Multiple Java Card-Applikationen 126x, 126y und 126z können auf diese Weise in einer Einzelkarte gespeichert werden. Die Lade- und Ausführungskontrolle 120 unterstützt Befehle, wobei das Terminal 14 wählen kann, welche Java-Karte-Applikation sofort oder nach dem nächsten Karten-Reset lauffähig ist.

Bei Abb. 13 beginnt die Card Java Virtual Machine (Card JVM) 16 die Ausführung bei einer vorbestimmten Methode (beispielsweise main) der selektierten Klassen in der gewählten Java Card-Applikation 126z beim Empfang eines Reset- oder Ausführungsbefehls von der Lade- und Ausführungskontrolle 120. Die Card JVM 16 liefert den Zugriff der Java Card-Applikation 126z auf das darunter liegende Kartenbetriebssystem 122, welches Möglichkeiten wie I/O, EEPROM-Support, Dateisysteme, Zugriffskontrolle und sonstige Systemfunktionen, die an die im Anhang F veranschaulichten maschinenabhängigen Java-Methoden appellieren, bietet.

Die selektierte Java Card-Applikation 126z kommuniziert mit einer geeigneten Applikation im Terminal 14 mit Hilfe des Communicators 12a, um einen Kommunikationskanal zum Terminal 14 aufzubauen. Daten vom Communicator 12a zum Terminal 14 laufen durch einen Communicator- Driver 132 im Terminal, welcher spezifisch zur Bearbeitung des vom Communicator 12a verwendeten Kommunikationsprotokolls geschrieben ist. Die Daten gelangen daraufhin in einen Integrated Circuit Card-Driver 134, welcher spezifisch zur Adressierung der Möglichkeiten der zum Einsatz kommenden besonderen Integrated Circuit Cards 10 geschrieben ist und der Terminalapplikation 136 High-Level-Software-Services liefert. Bei der bevorzugten Realisierung würde dieser Driver eine geeignete Software der Art PC/SC SmartCard Service Provider (SSP) sein. Die Daten gelangen dann in die Terminalapplikation 136, welche die von der lauffähigen besonderen Kartenapplikation 126z gelieferten Möglichkeiten bearbeiten muss. Auf diese Weise laufen die Befehle und Antworten zwischen der Terminalapplikation 136 und der selektierten Kartenapplikation 126z hin und her. Die Terminalapplikation dialogiert mit dem Benutzer, empfangt Befehle vom Benutzer, von welchen manche zur gewählten Java Card-Applikation 126z geleitet werden, und empfangen Antworten von der Java Card-Applikation 126z, welche verarbeitet und zum Benutzer zurückbeliefert werden.

Bei Abb. 14 ist die Card JVM 16 ein Interpreter, welche eine Kartenapplikation 126x übersetzt. Die Speicher-Ressourcen im Mikrocontroller, welche die Karten JVM 16 beeinflussen, sind die Karte ROM 140, die Karte RAM 141 und die Karte EEPROM 142. Die Karte ROM 140 dient zur Speicherung der Card JVM 16 und des Kartenbetriebssystems 122. Die Karte ROM 140 kann auch zur Speicherung fester Kartenapplikationen 140a und Klassenbibliotheken 140b verwendet werden. Ladbare Applikationen 141a, 141b und Bibliotheken 141c können auch in der Karte RAM 141 gespeichert werden. Die Card JVM 16 übersetzt eine Kartenapplikation 141a, 141b oder 140a. Die Card JVM 16 verwendet die Karte RAM zur Speicherung des VM Stack 144a und der Systemstatusvariablen 144b. Die Card JVM 16 verwahrt Spuren der über VM Stack 144a ausgeführten Vorgänge. Die durch die Card JVM 16 erstellten Objekte sind entweder auf dem freien RAM 144c, dem freien EEPROM 146a oder im Dateisystem 147.

Alle von der Card JVM 16 manipulierten Freispeicher können in der Karte RAM 141 als RAM-Freispeicher 144c gespeichert oder über die Karte EEPROM 142 als EEPROM-Freispeicher 146a verteilt werden. Die Karte RAM 141 wird auch zur Statusaufzeichnung des System-Stack 148, welcher von im Native-Code des Mikrocontrollers geschriebenen Routinen verwendet wird. Die Card JVM 16 verwendet die Karte EEPROM 142, um Applikationsdaten entweder im freien EEPROM 146a oder im Dateisystem 147 zu speichern. Die in einer Datei gespeicherten Applikationsdaten können über eine Schnittstelle mit dem Kartenbetriebssystem 122 manipuliert werden. Diese Schnittstelle wird von einer Klassenbibliothek 140b, welche in der Karte ROM 140 gespeichert ist, über eine ladbare Klassenbibliothek 141c, welche in der Karte EEPROMP 142 gespeichert ist, beigestellt. Eine dieser Schnittstellen ist im Anhang F beschrieben. Applikationen und Daten in der Karte sind über einen Firewall- Mechanismus 149 getrennt.

Um den verfügbaren begrenzten Microcontroller-Ressourcen Rechnung zu tragen, implementiert die Card JVM 16 ein striktes Subset der Java- Programmiersprache. Eine Java-Applikation 20 kompiliert folglich in eine Klassendatei, welches ein striktes Subset von Java-Byte-Codes enthält. Dies versetzt Applikationsprogrammierer in die Lage, in diesem strikten Subset von Java zu programmieren und die Kompatibilität mit bestehenden Java Virtual Machines zu wahren. Die Semantik der von der Card JVM 16 übersetzten Java-Byte-Codes sind in der zuvor erwähnten Java Virtual Machine Specification beschrieben. Das Subset von Byte-Codes, die von der Card JVM 16 übersetzt werden, findet man im Anhang C. Der Karten- Klassendatei-Konverter 26 prüft die Java-Applikation 20, um sicherzustellen, dass nur die in diesem Subset verfügbaren Features verwendet werden und sorgt für die Umsetzung in eine Form, welche von der Card JVM 16 verstanden und übersetzt werden kann.

Bei anderen Realisierungen ist die Card JVM 16 zur Übersetzung eines anderen Sets oder erhöhten Sets von Byte-Codes 116 bestimmt. Obgleich ein anderer Byte-Code zu Leistungsverbesserungen führen könnte, wäre es in bezug auf die in den Original-Byte-Codes von Java vorhandenen Sicherheit oder der Kompatibilität mit den etablierten Entwicklungstools von Java nicht wünschenswert, ein striktes Java-Subset aufzugeben.

Alle Applikationen 126 der Card JVM 16 haben eine definierte Einsprungstelle, welche durch eine Klasse und eine Methode innerhalb der Klasse bezeichnet wird. Die Einsprungstelle ist in der Zeichenkette zum ID Input Map 30 aufgegliedert und wird durch den Karten-Klassendatei- Konverter 26 zugewiesen. Klassen, Methoden und Felder innerhalb einer Java-Applikation 20 werden über den Karten-Klassendatei-Konverter 26 IDs zugewiesen. Die ID, welche beispielsweise der Appllkationsklasse main entspricht, kann als FOO1 und die ID, welche ihrer Methode main entspricht - wie "main ()V" - könnte als F002 definiert werden.

Die Gesamtausführungsarchitektur der Card JVM wird über das Flussbild in Abb. 15 beschrieben. Die Ausführung der Card JVM 16 beginnt an der Ausführungskontrolle 120, welche eine auszuführende Kartenapplikation 126z wählt. Sie veranlasst die Suche und Zuweisung einer Einsprungstelle 152 (eine Methode) in dieser Kartenapplikation für die zu übersetzende Card JVM 16. Die Card JVM 16 übersetzt die Methode 153. Wenn die Übersetzung 154 erfolgreich fortschreitet, reicht die Card JVM 16 den Erfolg 155 weiter, und zwar durch Rücklieferung der Kontrolle zur Ausführungskontrolle 120. Falls im Laufe der Übersetzung 153 die Card JVM 16 auf einen unbehandelten Fehler oder eine Ausnahme (Exception) stößt (typischerweise eine Ressourcenbegrenzung oder Sicherheitsverletzung), wird 156 durch die Card JVM 16 gestoppt, welche den geeigneten Fehler zum Terminal 14 überträgt.

Ein wesentlicher Teil der Card JVM 16 ist eine Subroutine, welche die Ausführung von Byte-Codes bearbeitet. Diese Subroutine wird durch das Flussbild in Abb. 16 veranschaulicht. Mit einer gegebenen Methode 160 führt sie die Byte-Codes in dieser Methode aus. Die Subroutine startet, indem sie sich für die Parameter dieser Methode 161 vorbereitet. Dies bedingt das Setzen des Zeigers von VM Stack 144a, der Frame-Grenzen von Stack 144a sowie das Setzen des Programmzählers auf den ersten Byte-Code der Methode.

Dann werden die Methoden flags überprüft 162. Wenn die Methode mit dem Flag native gekennzeichnet ist, dann ist die Methode tatsächlich ein Aufruf des Native Methode Code (im Native Prozessor Code des Mikrokontrollers geschriebene Subroutine). In diesem Fall bereitet sich die Card JVM 16 auf einen effizienten Aufruf 163 und eine Zurücklieferung zur Native-Code-Subroutine vor. Die Parameter zur Native Methode können auf den VM Stack 144a oder über den System-Stack 148 passieren. Die geeigneten Sicherheitsprüfungen werden ausgeführt, und die Subroutine der Methode native wird aufgerufen. Bei der Zurücklieferung wird das Ergebnis (sofern vorhanden) der Subroutine der Native Methode auf dem VM Stack 144a platziert, so dass sie für den nächsten auszuführenden Byte-Code zugriffiger ist.

Daraufhin wird die Dispatch-Schleife 164 der Card JVM 16 eingegeben. Die Dispatch-Schleife des Byte-Codes ist für die Vorbereitung, Ausführung und Ausscheidung jedes Byte-Codes verantwortlich. Die Schleife ist beendet, wenn sie die Byte-Codes in die Methode 160 übersetzt hat oder wenn die Card JVM 16 einer Ressourcenbegrenzung oder Sicherheitsverletzung begegnet.

Falls ein vorausgehender Byte-Code das Beschreiten einer Verzweigung 165 verursacht, bereitet sich die Card JVM für die Verzweigung 165a vor. Der nächste Byte-Code wird abgerufen 165b. Um die Kosten zur Verarbeitung jedes Byte-Codes niedrig zu halten, werden genauso viele gemeinsame Elemente wie die Byte-Code-Argumente, Länge, Typ - extrahiert und gespeichert.

Um die vom Sicherheitsmodell der Programmiersprache gebotene Sicherheit zu liefern, müssen die Byte-Codes in der Klassendatei überprüft und als mit diesem Modell übereinstimmend festgelegt werden. Diese Prüfungen erfolgen typischerweise gemäss dem Stand der Technik über ein als Byte-Code-Verifier bezeichnetes Programm, welches gemäss der Beschreibung in der Java Virtual Machine Specification in vier Durchläufen arbeitet. Um die durch den Byte-Code-Verifier garantierte Laufzeitsicherheit zu offerieren, muss die Card JVM 16 die Prüfungen ausführen, welche sich auf den Durchlauf 3 und Durchlauf 4 des Verifiers beziehen. Diese Prüfung lässt sich anhand der Card JVM 16 umgehen, sofern gewährleistet werden kann (was beinahe unmöglich ist), dass die von der Card JVM 16 übersetzten Byte-Codes 60 sicher sind. Die Codesicherheit kann mindestens so lange aufrecht erhalten werden, wie Objekt-Referenzen nicht imitierbar sind und der VM Stack 144a und die lokalen Variablengrenzen beachtet werden. Zu diesem Zweck muss der Status des VM Stack 144a in bezug auf den ausgeführten Byte-Code geprüft werden.

Um das Sicherheitsmodell der Programmiersprache zu verstärken, wird eine 256-Byte-Tabelle gemäss Anhang G angelegt, welche mit der Byte- Codenummer indexiert ist. Diese Tabelle enthält den Typ und die Länge der dem indexierten Byte-Code zugeordneten Information. Sie ist mit den ersten 5 Bits, welche den Typ darstellen, und den letzten 3 Bits, welche die Länge darstellen, codiert. Der Typ und die Länge des Byte-Codes ist direkt ab der Tabelle durch die Byte-Codenummer indexiert. Beide werden anschließend für die Prüfung gemäss Anhang H verwendet. Im Anhang H beginnt der Prüfprozess durch Decodierung der Länge und des Typs aus der Tabelle im Anhang G. Die Länge dient zum Inkrementieren des Programmzählers. Der rlyp wird zunächst zur Prüfung vor der Ausführung verwendet, um sicherzustellen, dass die Datentypen auf dem VM Stack 144a korrekt für den gerade im Ausführungsprozess befindlichen Byte-Code ist. Die 256 Bytes ROM zur Speicherung der Tabelle erlauben den Ablauf der Original- Byte-Codes in Java in der Card JVM 16 und minimiert die für die in die Karte zu ladende Java-Klassendatei benötigten Änderungen. Java-Byte- Codes können des weiteren leicht unterstützt werden, da sich die geeigneten Tabelleneingaben relativ leicht aktualisieren lassen.

Bei anderen Realisierungen, so wie in Abb. 10 veranschaulicht, sind die Java-Byte-Codes in der Methode in einer solchen Weise neubeziffert, dass die in der Tabelle im Anhang H gespeicherte Information zum Byte- Code-Typ und zur -länge implizit umgeordnet ist. Die zum Status des VM Stack 144a und zu verarbeitenden Byte-Codes auszuführenden Prüfungen ziehen aus diesem Grund kein Tabellenlesen mit sich. Die Prüfungen können durch einfache Vergleiche, so wie im Anhang I veranschaulicht, erfolgen. Diese Realisierung ist dann zu bevorzugen, wenn der ROM-Platz zu teuer ist, da sie eine 256-Byte-Tabelle beseitigt. Doch das Hinzufügen neuer Byte-Codes zum Set unterstützter Byte-Codes muss sorgfältig durchdacht werden, da die neuen Byte-Codes in das implizite Bezifferungsschema der unterstützten Byte-Codes passen müssen.

Bei einer weiteren Realisierung wählt die Card JVM 16, dass sie keine Sicherheitsprüfungen zugunsten der Ausführungsgeschwindigkeit der Card JVM 16 vornehmen möchte. Dies wird im Flussbild der Abb. 18 veranschaulicht. Das Flussbild von Abb. 18 ist das gleiche wie das von Abb. 16, aber ohne die Sicherheitsprüfungen. Diese Option ist in sicherheitstechnischer Hinsicht nicht wünschenswert, es sei denn, dass die Sicherheit der Byte-Codes garantiert werden kann.

Die Card JVM 16 kann auch weitere Sicherheitsprüfungen verstärken. Wenn der Byte-Code die Referenz auf eine lokale Variable ist, prüft die Card JVM 16 diese Referenz auf Gültigkeit und wirft einen Fehler, falls sie es nicht ist. Wenn ja, speichert die Card JVM 16 den Typ der lokalen Variable für künftige Prüfvorgänge. Der Zeiger des VM Stack 144a wird geprüft, um festzustellen, oh er sich immer noch in einem gültigen Bereich befindet. Wenn nein, wird eine Ausnahme (Exception) geworfen. Die Byte- Codenummer wird auf Unterstützung überprüft. Wenn sie nicht unterstützt wird, wird eine Exception geworfen.

Schließlich wird der Byte-Code selbst zugeteilt 165d. Die von der Card JVM 16 übersetzten Byte-Codes sind im Anhang C aufgelistet. Die Semantik der Byte-Codes ist in der zuvor erwähnten Java Virtual Machine Specification in bezug auf den Status des VM Stack 144 vor und nach der Zuteilung des Byte-Codes beschrieben. Es ist ferner zu berücksichtigen, dass manche Byte-Codes (die Byte-Codes INVOKESTATIC, INVOKESPECIAL, INVOKENONVIRTUAL und INVOKEVIRTUAL) einen neuen Einsprung in die Card JVM 16 verursachen können und eine Verarbeitung ab dem Einsprung von Subroutine 161 benötigen. Abb. 17 zeigt das Flussbild der Byte-Code- Ausführungsroutine. Der Routine wird ein Byte-Code 171 zur Ausführung gegeben. Die Card JVM 16 besorgt die Ausführung 172 der für den Byte- Code benötigten Instruktionen. Stößt die Card JVM 16 während der auf eine Ressourcenbegrenzung 173, liefert sie einen Fehler 156 zurück. Dieser Fehler wird über die Card JVM 16 zum Terminal 14 zurückgeliefert. Wenn der Byte-Code die Ausführung erfolgreich abschließt, liefert er einen Erfolg 175 zurück.

Nach der Ausführung wird der Typ des Ergebnisses dazu verwendet, um den Status des VM Stack 144a korrekt zu setzen 165e, indem die Datentypen auf dem VM Stack 144a mit einem Flag gekennzeichnet werden. Die aus der Byte-Code-Info-Tabelle zuvor erfasste 165b Byte- Codeinformation wird dazu verwendet, um den Status des VM Stack 144a in Übereinstimmung mit dem gerade ausgeführten Byte-Code zu setzen.

Bei anderen Realisierungen wird das Setzen des Output-Status von VM Stack 144a in bezug auf den ausgeführten Byte-Codes vereinfacht, wenn der Byte-Code neubeziffert wird. Dies wird im Anhang I veranschaulicht, welcher hier zur Bezugnahme eingebunden ist.

Bei noch anderen Realisierungen kann die Card JVM 16 das Setzen des Output-Status von VM Stack 144a zugunsten der Ausführungsgeschwindigkeit von Card JVM 16 umgehen. Diese Option ist in sicherheitstechnischer Hinsicht nicht wünschenswert, es sei denn, dass die Sicherheit der Byte-Codes gewährleistet werden kann.

Nachdem die Byte-Codes ausgeführt sind, wird der Byte-Code zurückgezogen 165f. Dies bedingt das Abspringen von Argumenten aus dem VM Stack 144a. Sobald die Byte-Codeverarbeitung abgeschlossen ist, wird die Schleife 164 für den nächsten Byte-Code der Methode wiederholt.

Wenn die Dispatch-Schleife 164 beendet ist, wird der VM Stack 144a geleert 166. Dies verhindert, dass irgendwelche Objekt-Referenzen auf andere Aufrufe der Card JVM 16 herunterfiltert werden können und die Sicherheit der Card JVM unterbrechen. Die Beendigung 167 der Dispatch- Schleife 164 bedeutet, dass die Card JVM 16 die Ausführung der angeforderten Methode abgeschlossen hat.

Um die Daten und Applikationen in der Integrated Circuit Card 10 voneinander zu trennen, verlässt sich die Integrated Circuit Card 10 auf den von der Card JVM 16 gelieferten Firewall-Mechanismus 149. Da die Card JVM die Prüfungen durch den Verifier des Standarddurchlaufs 3 und Durchlaufs 4 implementiert, erfasst sie jeglichen Versuch, Daten oder Codeplatz, die von einer anderen Applikation genutzt werden, zu referenzieren und einen Sicherheitsfehler 156 mit einer Flagge zu kennzeichnen. Herkömmliche Low-Level-Applikationen können beispielsweise referenzlose Datentypen in Referenzen summieren, dadurch den Zugriff auf nicht autorisierten Speicherplatz ermöglichen und gegen die Sicherheit verstoßen. Mit dieser Erfindung führt der Versuch einer Kartenapplikation 126z, einen referenzlosen Datentyp als Referenz zu verwenden, zur Auslösung einer Sicherheitsverletzung 156. Bei herkömmlichen Java-Programmen wird diese geschützte Anwendungsumgebung mit Sandbox- Applikationsübersetzungsumgebung bezeichnet.

Diese Firewall-Einrichtungen arbeiten jedoch nicht unabhängig. In Wirklichkeit überlappen und verstärken sie sich gegenseitig mit den in folgender Tabelle veranschaulichten herkömmlichen Zugriffskonkontrolllisten und Verschlüsselungsmechanismen.

Zusammen genommen trennen diese Einrichtungen sowohl die Daten als auch die Applikationen auf den Integrated Circuit Cards 10 und gewährleisten, dass jede Kartenapplikation 126 nur auf die auf der Integrated Circuit Card 10 autorisierten Ressourcen zugreifen kann.

Bei Abb. 19 können die Kartenapplikationen 126x, 126y, 126z bei Ausführung der Kartenappilkationen 126 mit spezifischen Privilegien ausgestattet werden. Solche Privilegien bestimmen beispielsweise, auf welche Datendateien die Kartenapplikationen 126 zugreifen können und welche Operationen die Kartenapplikationen 126 auf dem Dateisystem 147 ausführen können. Die der Applikationskarte 126 gewährten Privilegien werden normalerweise zu dem Zeitpunkt gesetzt, wenn eine besondere Kartenapplikation 126z durch den Benutzer - typischerweise vom Terminal 14 aus - gestartet wird.

Die Integrated Circuit Card 10 verwendet verschlüsselte Methoden zur Identifikationsüberprüfung, um eine Identität 190 zuzuweisen (z. B. Identitäten 190a, 190b und 190c) und folglich ein Set von Privilegen zur Ausführung der Kartenapplikation 126. Die Zuweisung der spezifischen Identität 190c zur Kartenapplikation 126z erfolgt, wenn die Kartenapplikation 126z die Ausführung beginnt, wodurch die durch Abb. 20 gezeigte spezifische Laufapplikation 200 erstellt wird. Die Identität 190 ist eine einheitliche leicht lesbare Textzeichenkette, welche auf zuverlässige Weise einer Identitätseinheit zugewiesen sind. Die Identitätseinheit (z. B. eine persönliche Indentifikationsnummer (PIN) oder ein RSA-Privatschlüssel) ist ein Chiffrierschlüssel.

Bei Abb. 20 muss die Identität 190c der Applikationskarte 126z authentifiziert werden, damit eine spezifische Kartenapplikation 126z ablaufen kann. Die Identität 190c wird durch Demonstration der Kenntnis des der Identität 190c zugewiesenen Identity-Token authentifiziert. Um die Applikationskarte 126z laufen zu lassen, muss folglich ein Agent (z. B. eine Karteninhaber oder andere Applikation, welche die Applikation zum Laufen bringen möchte) zeigen, dass er den identitätsdefinierenden Chiffrierschlüssel der Applikation besitzt oder kennt.

Ein Verfahren, den Besitz eines Chiffrierschlüssels zu beweisen, besteht ganz einfach darin, ihn preiszugeben. Die PIN-Überprüfung ist ein Beispiel dieser Authentifizierungsform. Ein weiteres Verfahren, mit welchem der Besitz eines Chiffrierschlüssels bewiesen werden kann, ohne den Schlüssel tatsächlich selber preiszugeben, besteht darin, die Fähigkeit zur Volltextverschlüsselung oder -entschlüsselung mit dem Schlüssel zu zeigen.

Somit beinhaltet eine spezifische Laufapplikation 200 auf der Integrated Circuit Card 10 eine Kartenapplikation 126z plus eine authentifizierte Identität 190c. Es kann keine Kartenapplikation 126, ohne das jedes dieser beiden Elemente einsetzt ist, laufen. Die Kartenapplikation 126z definiert auszuführende Datenverarbeitungsoperationen, und die authentifizierte Identität 190c bestimmt auf welchen rechnerischen Objekten diese Operationen ausgeführt werden können. Eine spezifische Applikation 126z kann beispielsweise nur auf die Identity C's Files 202 im der spezifischen Identität zugewiesenen Dateisystem 147 zugreifen, welches der spezifischen Identität 190c zugewiesen ist, und die spezifische Kartenapplikation 126z kann auf keine anderen Dateien 204 zugreifen, welche anderen Identitäten als die spezifische Identität 190c zugewiesen sind.

Die Integrated Circuit Card 10 kann zusätzliche Schritte durchführen, um die Trennung der Applikation und Daten sicherzustellen. Die Integrated Circuit Card 10 bietet drei Software-Feature-Sets: jeweils authentifizierte Identitätszugriffskontrolllisten, eine Java-basierte virtuelle Maschine und einmalige Sitzungschiffrierschlüssel zum jeweiligen Schutz der Datendateien, Applikationsausführung und Kommunikationskanäle. Diese Feature-Sets liefern gemeinsam die Applikationsdaten-Firewalls 149 für eine Realisierung. Nachstehend wird jedes Software-Feature-Set erläutert und anschließend veranschaulicht, wie diese drei Sets zusammenarbeiten, um die Trennung der Applikation und Daten auf der Integrated Circuit Card 10 zu gewährleisten.

Eine Zugriffskontrollliste (access control list = ACL) wird jedem rechnerischen Objekt (z. B. einer Datendatei oder einem Kommunikationskanal) auf der zu schützenden Integrated Circuit Card 10 - d. h. deren Zugriff zu kontrollieren ist - zugewiesen. Ein Einsprung auf einer ACL (für ein besonderes rechnerische Objekt) wird innerhalb eines Datenformats mit e-tuple bezeichnet:

Type: identity: permissions

Das Feld type gibt den Typ der folgenden Identität an (im Feld identity), z. B. ein Benutzer (z. B. "John Smith") oder eine Gruppe. Die Felder permissions geben eine Liste von Operationen an (z. B. read, append und update), welche von der Identität auf dem rechnerischen Objekt verrichtet werden können.

Bei einer Datendatei mit dem ACL-Einsprung:

USER: AcmeAirlines: RAU,

kann beispielsweise jede Applikation mit der Identität "AcmeAirlines" lesen ("R"), anhängen ("A") und ihren Update ("U") vornehmen. Zusätzlich kann die ACL selektiv zum Anlegen und Löschen von Datendateien verwendet werden. Darüber hinaus kann die ACL selektiv zur Ausführung einer Applikation verwendet werden.

Bei jedem Zugriff auf ein rechnerisches Objekt durch eine Laufapplikation 200 wird der Zugriff durch die Card JVM 16 erfasst und zum Kartenbetriebssystem 122 geleitet, welches ermittelt, ob dem Objekt eine ACL zugewiesen ist. Falls ja, wird die Identität 190c, welche der Laufapplikation 200 zugewiesen ist, an die ACL angepasst. Wenn die Identität nicht gefunden wird, oder wenn die Identität nicht für den angeforderten Zugrifftyp genehmigt ist, wird der Zugriff negiert. Andernfalls wird der Ablauf das Zugriffsverfahren genehmigt.

Bei Abb. 13 muss zur Verhinderung möglicher Probleme infolge des Einzeldatenpfads zwischen der Integrated Circuit Card 10 und dem Terminal 14 die Trennung des Kommunikationskanals durch Einbindung des Austauschs eines einmaligen Sitzungsschlüssels 209 zwischen einer Kartenapplikation 126z und der Terminalapplikation 136 in den Identitäts- Authentifizierungsprozess erfolgen. Der Schlüssel 209 wird dann zur Verschlüsselung des späteren Verkehrs zwischen der authentifizierenden Terminalapplikation 136 und der authentifizierten Kartenapplikation 126z verwendet. Wegen des einmaligen Sitzungsschlüssels 209 kann eine minderwertige Terminalapplikation weder eine authentifizierte Kommunikation' zwischen dem Terminal 14 und der Integrated Circuit Card 10 "mithören" noch kann eine minderwertige Terminalapplikation die Kartenapplikation so "hereinlegent dass sie nicht autorisierte Operationen in ihrem Interesse durchführt.

Die Verschlüsselung und Entschlüsselung von Karten- /Terminalverkehr kann entweder durch das Kartenbetriebssystem 122 oder die Kartenapplikation selber 126z behandelt werden. Im ersterwähnten Fall wird die Kommunikation mit dem Terminal 14 für die Applikation transparent verschlüsselt, und der Meldungsverkehr kommt im Datenplatz der Applikation entschlüsselt an. Im letzterwähnten Fall wählt die Kartenapplikation 126z die Durchführung eine Verschlüsselung und Entschlüsselung, um eine zusätzliche Sicherheitsschicht zu liefern, da die Applikation in der Lage wäre, Daten zu verschlüsseln, sobald sie erstellt sind, und Daten nur zu entschlüsseln, wenn sie verwendet werden sollen. Andernfalls würden die Daten mit dem Sitzungsschlüssel 209 verschlüsselt bleiben.

Somit beinhaltet die Firewall-Applikation drei sich gegenseitig verstärkende Software-Sets. Datendateien sind durch identitätsauthentifizierte Zugriffskontrolllisten geschützt. Applikationsausführungsplätze werden durch die Card JVM 16 geschützt. Kommunikationskanäle sind mit einmaligen Sitzungschiffrierschlüsseln 209 geschützt.

Bei andere Realisierungen kommen die zuvor beschriebenen Techniken mit einem Mikrocontroller (wie der Prozessor 12) zum Einsatz, können andere Vorrichtungen (z. B. in einem Automobilmotor) als eine Integrated Circuit Card kontrolliert werden. In diesen Applikationen liefert der Mikrocontroller eine kleinere Plattform (d. h. eine CPU und einen Speicher, welche beide auf einem Halbleitersubstrat implantiert sind) zur Speicherung und Ausführung von höheren Programmiersprachen. Die meisten existierenden Vorrichtungen und neuen Designs, die an einen Mikrocontroller appellieren, können die Erfindung dazu nutzen, um die Möglichkeit zu bieten, den Mikrocontroller anhand einer Hochsprache zu programmieren, und die Applikation dieser Erfindung auf solchen Vorrichtungen ist spezifisch eingebunden.

Der Begriff Applikation beinhaltet jedes Programm wie Java applications, Java applets, Java aglets, Java servlets, Java commlets, Java components und andere Nicht-Java-Programme, welche zu Klassendateien gemäss nachstehender Beschreibung führen.

Klassendateien können eine andere Quelle als Java-Programmdateien haben. Mehrere andere Programmiersprachen als Java haben Compiler oder Assembler zur Erzeugung von Klassendateien aus ihren jeweiligen Quelldateien. Zum Beispiel kann die Programmiersprache Eifel zur Erzeugung von Klassendateien verwendet werden, welche an Pirmin Kalberers "J-Eiffel", ein Eiffel-Compiler mit JVM-Byte-Codeerzeugung appellieren (Website: http://www.spin.ch/~kalberer/jive/index.htm). Ein Übersetzer von Ada 95 in Java-Byte-Code ist in der folgenden Bezugsliteratur beschrieben: Taft, S. Tucker, "Programming the Internet in Ada 95", Vorgehensweise von Ada Europe '96, 1996. Jasmin ist ein Java- Byte-Code-Assemblerprogramm, welches zur Generierung von Klassendateien, 50 wie sie in der folgenden Bezugsliteratur beschrieben sind, verwendet werden kann: Meyer, Jon und Troy Downing, "Java Virtual Machine", O' Reilly, 1997. Die obige Beschreibung wird ohne Berücksichtigung der Quelle der Klassendateien für anderen Sprachen als Java angewandt, um zu interpretierende Codes zu generieren.

Abb. 21 zeigt eine Integrated Circuit Card oder Chipkarte, welche einen Mikrocontroller 210 beinhaltet, der auf eine Kunststoffkarte 212 montiert ist. Die Kunststoffkarte 212 hat in etwa den gleichen Formfaktor wie eine typische Kreditkarte. Der Communicator 12a kann einen Kontakt- Pad 214 zum Aufbau eines Kommunikationskanals verwenden, oder der Communicator 12a kann ein drahtloses Kommunikationssystem verwenden.

Bei anderen Realisierungen ist ein Mikrocontroller 210 in ein mobiles oder festes Telefon 220 montiert, um dem Telefon - so wie in Abb. 22 veranschaulicht - wirkungsvolle Chipkartenmöglichkeiten hinzufügen. Bei diesen Realisierungen ist der Mikrocontroller 210 auf ein Modul (wie ein Subscriber Identity Module (SIM)) montiert, welches ins Telefon 220 eingesetzt und aus ihm entnommen werden kann.

Bei anderen Realisierungen wird ein Mikrocontroller 210 einem Schlüsselring 230 - so wie in Abb. 23 veranschaulicht - hinzugefügt. Dies kann zur Absicherung des Zugriffs auf ein Automobil, welches zur Erkennung der dem Mikrocontroller 210 auf dem Schlüsselring 230 zugewiesenen Identität ausgerüstet ist, verwendet werden.

Juwelierarbeit wie eine Uhr oder ein Ring 240 können auch einen Mikrocontroller 210 in ergonomischer Weise unterbringen, so wie es auf Abb. 24 veranschaulicht wird. Solche Realisierungen verwenden typischerweise drahtlose Kommunikationssysteme zum Aufbau eines Kommunikationskanals und sind eine bequeme Lösung zur Implementierung einer Zugriffskontrolle mit minimaler Plackerei für den Benutzer.

Abb. 25 veranschaulicht einen Mikrocontroller 210, welche in ein elektrisches Subsystem 252 eines Automobils 254 eingebaut ist. Bei dieser Realisierung wird der Mikrocontroller für eine Vielzahl von Zwecken verwendet, wie Zugriffskontrolle zum Automobil (d. h. Prüfung der Identität oder Nüchternheit, bevor das Zündsystem des Automobils freigegeben wird), Zahlung von Gebühren per drahtloser Kommunikation oder Schnittstelle zu einem globalen Positioniersystem (GPS), um den Ort, an dem sich das Automobil befindet, zu verfolgen, um nur ein paar zu nennen.

Für die hiermit beschriebenen spezifischen Realisierungen dieser Erfindung sind für jemanden, der in der Technik geübt ist, mehrere Änderungen und Substitutionen aus der Darstellung der Erfindung ersichtlich. Solche Änderungen und Substitutionen liegen Geltungsbereich dieser Erfindung und sollen durch die anhängenden Patentansprüche berücksichtigt sein.

ANHANG A Karten-Klassendateiformat zur bevorzugten Verwirklichung Einführung

Die Karten-Klassendatei ist eine komprimierte Form der Original- Klassendatei(en). Die Karten-Klassendatei enthält nur die zur Übersetzung der Java-Programme aus den Original-Klassendateien benötigten semantische Information. Die indirekten Referenzen in der Original- Klassendatei werden mit aus einer komprimierten Darstellung resultierenden direkten Referenzen ersetzt. Das Karten-Klassendateiformat basiert auf folgenden Prinzipien.

Enge Anlehnung ans standardmäßige Klassendateiformat:

Das Karten- Klassendateiformat sollte sich so eng wie möglich ans standardmäßige Klassendateiformat anlehnen. Die Java-Byte-Codes der Klassendatei bleiben unverändert. Die Unveränderung der Byte-Codes gewährleistet, dass die strukturellen und statischen Anforderungen auf denen nachprüfbar intakt bleiben.

Implementierungsfreundlichkeit:

Das Karten-Klassendateiformat muss sich durch die zur Nutzung von Java Virtual Machine-Implementers benötigte Einfachheit auszeichnen. Es soll verschiedene, doch verhältnismäßig äquivalente, Implementierungen erlauben.

Machbarkeit:

Das Karten-Klassendateiformat soll zwecks Anpassung an die Chipkartentechnologie kompakt sein. Es soll den Anforderungen der gängigen Technologie, ohne den Blick auf Innovationen von morgen zu verlieren, gerecht werden.

Diesem Dokument liegt das Kapitel 4 "The class file format", des Buchs mit dem Titel "The JavaTM Virtual Machine Specification"[1] zugrunde, welches nachstehend als das Rote Buch bezeichnet wird. Da das Dokument im Roten Buch beschriebenen standardmäßigen Klassendateiformat entspricht, präsentieren wir nur Information, welche sich davon unterscheidet. Das Rote Buch dient als die endgültige Autorität bei jeglichem Klärungsbedarf.

Primäränderungen, die das standardmäßigen Karten-Klassendateiformat betreffen, sind folgende:

Der Konstantenpool ist optimiert, um nur 16-Bit-Bezeichner zu enthalten und, da wo möglich, ist Indirektes durch eine direkte Referenz ersetzt. Attribute in der Original-Klassendatei sind beseitigt oder umgeordnet.

Das Java-Karten-Klassendateiformat

Dieser Abschnitt beschreibt das Java-Karten-Klassendateiformat. Jede Karten-Klassendatei enthält einen oder mehrere Java-Typen, wobei ein Typ eine Klasse oder eine Schnittstelle sein kann.

Eine Karten-Klassendatei besteht aus einem Strom von 8-Bit-Bytes. Alle 16- Bit-, 32-Bit- und 64-Bit-Mengen sind durch Einlesen in jeweils zwei, vier und acht konsekutive 8-Bit-Bytes konstruiert. Multi-Byte-Datenelemente werden immer in Reihenfolgen mit weitem Ende gespeichert, wobei die hohen Bytes zuerst kommen. In Java wird dieses Format durch die Schnittstellen java.io.DataInput und java.io.DataOutput und Klassen wie java.io.DataiInputStream und java.io.DataOutputStream unterstützt.

Zur Darstellung der Java-Klassendateidaten definieren und verwenden dasselbe Set von Datentypen; die Typen u1, u2 und u4 stellen jeweils eine 1- Byte, 2-Byte- oder 4-Byte Menge ohne Vorzeichen dar. In Java können diesen Typen durch Methoden wie readUnsignedByte, readUnsignedShort und readInt der Schnittestelle java.io.DataInput gelesen werden.

Das Karten-Klassendateiformat ist anhand von Pseudo-Strukturen, welche in einer C-ähnlichen Strukturnotation geschrieben sind, präsentiert. Um die Felder von Klassen der Java Card Virtual Machine und Klasseninstanzen nicht durcheinanderzubringen, bezeichnet man den Inhalt der das Karten- Klassendateiformat beschreibenden Strukturen als Elemente. Im Gegensatz zu den Feldern einer C-Struktur, werden sukzessive Elemente sequentiell in der Karten-Klassendatei ohne Auffüllen oder Ausrichten gespeichert.

Tabellen variabler Größen, welche sich aus Elementen variabler Größe zusammensetzen, kommen in verschiedenen Klassendateistrukturen zum Einsatz. Obgleich wir an eine C-ähnliche Array-Syntax zur Bezugnahme auf Tabellen-Elemente appellieren, bedeutet die Tatsache, dass Tabellen Ströme von Strukturen variabler Größe sind, dass es unmöglich ist, einen Tabellen- Index direkt in ein Byte-Offset in der Tabelle zu übersetzen.

Da, wo wir uns auf eine Datenstruktur als Array beziehen, handelt es sich buchstäblich um ein Array.

Um zwischen der Karten-Klassendateistruktur und der Standard- Klassendateistruktur zu unterscheiden, fügen wir eine Grosschreibung hinzu, beispielsweise durch Umbenennung von field_info in der Original- Klassendatei auf FieldInfo in der Karten-Klassendatei.

Karten-Klassendatei

Eine Karten-Klassendatei enthält eine einzige CardClassFile-Struktur:

Die Elemente Inder CardClassFile-Struktur sind folgende:

minor_version, major_version

Die Werte der Elemente minor_version und major_version sind die niedrigsten und höchsten Versionsnummern der Off-Card Java Card Virtual Machine, welche diese Karten-Klassendatei erzeugt. Eine Implementierung der Java Card Virtual Machine unterstützt normalerweise Klassendateien mit einer gegebenen höchsten Versionsnummer und niedrigsten Versionsnummern 0 mit Hilfe mancher besonderer minor_versions.

Die Bedeutung von Karten-Klassendatei-Versionsnummern kann nur durch das Java Card Forum definiert werden.

name_index

Der Wert des Elements name_index muss einen gültigen Java- Klassennamen darstellen. Der durch name_index dargestellte Java- Klassenname muss genau derselbe Java-Klassenname, welcher der in der Karte abzulaufenden Applikation main entspricht, sein. Eine Karten- Klassendatei enthält verschiedene Klassen oder Schnittstellen, welche die in der Karte ablaufende Applikation bilden. Da Java jeder Klasse die Möglichkeit bietet, eine Methode main zu enthalten, muss eine Unterscheidung der Klassendatei, welche die der Kartenapplikation entsprechende Methode main enthält, möglich sein.

const_size

Der Wert von const_size gibt die Anzahl der Einsprünge in den Konstantenpool der Karten-Klassendatei. Ein constant_pool Index gilt als gültig, wenn er grösser als oder gleich Null und kleiner als const_size ist.

max_class

Dieser Wert bezieht sich auf die Anzahl der in der Karten-Klassendatei vorhandenen Klassen. Da die Namensauflösung und -verknüpfung in der Java Card durch die Off-Card Java Virtual Machine erfolgt sind alle Klassendateien oder für eine Applikation benötigten Klassen zusammen in einer Karten-Klassendatei platziert.

constant_pool[]

Der Konstantenpool ist eine Tabelle variabler Längenstrukturen (), welche verschiedene String-Konstanten, Klassennamen, Feldnamen und sonstige Konstanten, auf welche innerhalb der CardClassFile-Struktur und ihrer Substrukturen Bezug genommen wird, darstellen.

CardClassFile-Strukture und ihre Substrukturen.

Der erste Einsprung in die Karten-Klassendatei ist constan_pool[0].

Jeder mit den Indizes mit dem Wert 0 beginnende constant_pool- Tabelleneinsprung über const_size ist eine Struktur variabler Länge ().

class()

Die Klasse ist eine Tabelle von max-class-Klassen, welche die auf die Karte geladene Applikation bilden.

Honstantenpool

Alle constant_pool-Tabelleneinsprünge haben folgendes Allgemeinformat:

Jedes Element in der constantpool-Tabelle muss mit einem die Art des cp_info-entry-Einprungs angebenden 1-Byte-Tags beginnen. Der Inhalt des Info-Felds schwankt je nach Tag-Wert. Die gültigen Tags und ihre Werte sind die gleichen wie jene, die im Roten Buch spezifiziert sind.

Jeder Tag-Byte muss von zwei oder mehreren Bytes, welche die Information zur spezifischen Konstante geben, gefolgt sein. Das Format der zusätzlichen Information ändert sich mit dem Tag-Wert. Die derzeit einzigen Tags, die eingebunden werden müssen, sind CONSTANT_Class, CONSTANT_FieldRef, CONSTANT_MethodRef und CONSTANT_InterfaceRef. Die Unterstützung für weitere Tags wird in dem Masse, wie sie in die Spezifikation eingebunden werden, hinzugefügt.

CONSTANT_Class

Die CONSTANT_Class_info-Struktur wird zur Darstellung einer masse oder einer Schnittstelle verwendet:

Die Elemente der CONSTANT_Class_info-Struktur sind folgende:

tag

Der Wert des Tag-Elements ist CONSTANT_Class (7).

name_index

Der Wert des Elements name_index muss einen gültigen Java- Klassennamen darstellen. Der durch name_index dargestellte Java- Klassenname muss genau derselbe Java-Klassenname sein wie jener, welcher durch den entsprechenden CONSTANT_class-Einsprung im constant_pool der Original-Klassendatei beschrieben ist.

CONSTANT_Fieldref, CONSTANT_Methodref und

CONSTANT_InterfaceMethodrefFields, Methoden und Schnittstellenmethoden sind durch ähnliche Strukturen dargestellt:

Die Elemente dieser Strukturen sind folgende:

tag

Das Tag-Element einer CONSTANT_FieldrefInfo-Struktur hat den Wert CONSTANT_Fieldref (9).

Das Tag-Element einer CONSTANT_MethodrefInfo-Struktur hat den Wert CONSTANT_Methodref (10).

Das Tag-Element einer CONSTANT_InterfaceMethodrefInfo-Struktur hat den Wert CONSTANT_InterfaceMethodref (11).

class_indes

Der Wert des Elements class_index muss einen gültigen Java-Klassen- oder Schnittstellennamen darstellen. Der durch class_index dargestellte Name muss genau dem Namen entsprechen, welcher durch den entsprechenden CONSTANT_Class_info-Einsprung im constant_pool der Original- Klassendatei beschrieben ist, entsprechen.

name_sig_indeg

Der Wert des Elements name_sig_index muss einen gültigen Java-Namen und -typ darstellen. Der durch name_sig_index dargestellte Name und Typ muss genau demselben Namen und Typ entsprechen, welcher durch den entsprechenden. CONSTANT_NameAndType_info-Einsprung in der constant_pool-Struktur der Original-Klassendatei beschrieben ist.

Class

Jede Klasse ist durch eine ClassInfo-Struktur fester Länge beschrieben. Das Format der Struktur ist so:

Die Elemente der ClassInfo-Struktur sind folgende:

name_index

Der Wert des Elements name_index muss einen gültigen Java- Klassennamen darstellen. Der durch name_index dargestellte Java- Klassenname muss genau demselben Java-Klassennamen entsprechen, welcher in der entsprechenden ClassFile-Struktur der Original-Klassendatei beschrieben ist.

max_field

Der Wert des Elements max_field gibt die Anzahl der FieldInfo ()-Strukturen in der Feldtabelle, welche die von dieser Klasse oder diesem Schnittstellentyp deklarierten Instanzvariablen darstellt. Dieser Wert bezieht sich auf die Anzahl nicht statischer Felder in der Karten-Klassendatei. Wenn die Klasse eine Schnittstelle darstellt, ist der Wert von max_field 0.

max_sfield

Der Wert des Elements max_sfield gibt die Anzahl der FieldInfo-Strukturen in der Feldtabelle, welche die von dieser Klasse oder diesem Schnittstellentyp deklarierten Klassenvariablen darstellt. Dieser Wert bezieht sich auf die Anzahl nicht statischer Felder in der Karten-Massendatei.

max_method

Der Wert des Elements max_method gibt die Anzahl der MethodInfo ()Q- Strukturen in der Methodentabelle.

max_interface

Der Wert des Elements max_interface gibt die Anzahl direkter Superschnittstellen dieser Klasse oder dieses Schnittstellentyps.

superclass

Bei einer Klassen muss der Wert des Elements superclass einen gültigen Java-Klassennamen darstellen. Der durch Superklasse dargestellte Java- Klassenname muss genau demselben Java-Klassennamen entsprechen, welcher in der entsprechenden ClassFile-Struktur der Original-Klassendatei beschrieben ist.

Weder Superklasse noch irgendeine ihrer Superklassen kann eine als final gekennzeichnete Klasse sein.

Wenn der Wert von Superklasse 0 ist, dann muss diese Klasse das Class java.lang.Object, die einzige Klasse oder Schnittstelle ohne eine Superklasse, darstellen.

Bei einer Schnittstelle muss der Wert superclass immer das Java class java.lang.Object darstellen.

access_flags

Der Wert des Elements access_flags ist eine Maske von Modifiers, welche mit Klassen- und Schnittstellendeklarationen verwendet werden. Die access_flags-Modifier und ihre Werte sind dieselben wie die access_flags- Modifiers in der entsprechenden ClassFile-Struktur der Original- Klassendatei.

field[]

Jeder Wert in der Feldtabelle muss eine FieldInfo ()-Struktur fester Länge sein, welche eine komplette Beschreibung eines Felds im Klassen oder Schnittstellentyp gibt. Die Feldtabelle beinhaltet nur jene Felder, die über diese Klassen oder Schnittstelle deklariert wurden. Sie beinhaltet keine Felder darstellenden Elemente, die von Superklassen oder Superschnittstellen geerbt wurden.

interface[]

Jeder Wert im interface array muss einen gültigen Schnittstellennamen darstellen. Der durch jeden Einsprung dargestellte Schnittstellenname muss genau demselben Schnittstellenname entsprechen, welcher im entsprechenden interface array der Original-Klassendatei beschrieben ist.

method[]

Jeder Wert in der Methodentabelle muss eine MethodInfo ()-Struktur variabler Länge sein, welche eine komplette Beschreibung von und Java Virtual Machine-Code für eine Methode in der Klasse oder Schnittstelle gibt. Die MethodInfo-Strukturen stellen alle Methoden, beide Instanzmethoden und, bei Klassen, (statische) Klassenmethoden dar, welche durch diesen Klassen- oder Schnittstellentyp deklariert wurden. Die Methodentabelle beinhaltet nur jene Methoden, die explizit durch diese Klassen deklariert sind. Schnittstellen haben nur die Einzelmethode < clinit> , die Methode zur Initialisierung der Schnittstelle. Die Methodentabelle beinhaltete keine Elemente, welche von Superklassen oder Superschnittstellen geerbte Methoden darstellen.

Fields

Jedes Feld wird in einer field_info-Struktur fester Länge beschrieben. Das Format dieser Struktur ist

Die Elemente der FieldInfo-Struktur sind folgende:

name_indeg

Der Wert des Elements name_index muss einen gültigen Java-Feldnamen darstellen. Der der durch name_index dargestellte Java-Feldname muss genaus derselbe Feldname, welcher in der entsprechenden field-info- Struktur der Original-Klassendatei beschrieben ist, sein.

signature_index

Der Wert des Elements signature_index muss einen gültigen Java-Feld- Deskriptor darstellen. Der durch Signatur-Index dargestellte Java-Feld- Deskriptor muss genau demselben Java-Feld-Deskriptor entsprechen, welcher in der entsprechenden field_info-Struktur der Original-Klassendatei beschrieben ist.

access_flags

Der Wert des Elements access_flags ist eine Maske von Modifiers, welche zur Beschreibung der Zugriffsgenehmigung auf und die Eigenschaften eines Felds beschreibt. Die access_flags-Modifiers und ihre Werte sind dieselben wie die access_flags-Modifiers in der entsprechenden field_info-Struktur der Original-Klassendatei.

Methoden

Jede Methode wird durch eine MethodInfo-Struktur variabler Länge beschrieben. Die MethodInfo-Struktur is eine Struktur variabler Länge, welche die Java Virtuel Machine-Instruktionen und zusätzliche Information für eine einzelne Java-Methode, Instanz-Initialisierungsmethode oder Klassen- oder Schnittstellen-Initialisierungsmethode enthält. Die Struktur hat folgendes Format:

Die Elemente der MethodInfo-Struktur sind folgende

name_indes

Der Wert des Elements name_index muss entweder einen der besonderen internen Methodennamen, < mit> oder < clinit> , oder einen gültigen Java- Methodennamen darstellen. Der durch name_index dargestellte Java- Methodennamen muss genau demselben Java-Methodennamen entsprechen, welcher in der entsprechenden method_info-Struktur der Original-Klassendatei beschreiben ist.

signature_indeg

Der Wert des Elements signature_index muss einen gültigen Java- Methodendeskriptor darstellen. Der der durch signature_index dargestellte Java-Methodendeskriptor muss genau demselben Java- Methodendeskriptor entsprechen, welcher in der entsprechenden method_info-Struktur der Original-Klassendatei beschrieben ist.

max_local

Der Wert des Elements max_local gibt die Anzahl der von der Methode verwendeten lokalen Variablen, wobei die durch Aufruf auf die Methode übergegangen Parameter ausgeschlossen sind. Der Index der ersten lokalen Variable ist 0. Der größte lokale Variablenindex für einen Einwortwert ist max_locals-1.

max_arg

Der Wert des Elements max_arg gibt die maximale Anzahl der Argumente zu dieser Methode.

max_stack

Der Wert des Elements max_stack gibt die maximale Anzahl der Wörter auf dem Operanden-Stack an jedem Punkt während der Ausführung dieser Methode.

access_flags

Der Wert des Elements access_flags ist eine Maske von Modifiers, welche zur Beschreibung der Zugriffsgenehmigung zu und Eigenschaften einer Methode oder Instanz-Initialisierungsmethode verwendet werden. Die access_flags- Modifiers und ihre Werte sind dieselben wie die access_flags-Modifiers in der entsprechenden method_info-Struktur der Original-Klassendatei.

code_length

Der Wert des Elements code_length gibt die Anzahl der Bytes im Code-Array für diese Methode. Der Wert von code_length muss grösser als 0 sein; das Code-Array darf nicht leer sein.

exception_length

Der Wert des Elements exception_length gibt die Anzahl der Einsprünge in die exception_info-Tabelle.

code[]

Das Code-Array gibt die aktuellen Bytes für Java Virtual Machine Code, welche die Methode implementieren. Wird das Code-Array in den Speicher auf einer byte-adressierbaren Maschine eingelesen, werden die Tableswitch- und Lookupswitch-32-Bit-Offsets 4-Byte ausgerichtet, sofern das erste Array-Byte auf einer 4-Byte-Grenze ausgerichtet ist; mehr zu den Code- Array-Ausrichtungsfolgen können aus den Beschreibungen zu solchen Instruktionen entnommen werden.

Die detaillierten Vorgaben zu Code Array-Contents sind umfassend und dieselben wie die in der Java Virtual Machine Specification beschriebenen.

einfo[]

Jeder Einsprung in das einfo-Array beschreibt eine Ausnahme- Handlerfunktion im Code-Array. Jeder einfo-Einsprung enthält folgende Elemente:

start_pc, end_pc

Die Werte der zwei Elemente start_pc und end_pc geben die Reihen im Code- Array an, bei welchen die Ausnahme-Handlerfunktion aktiv ist.

Der Wert von start_pc muss eine gültige Index-Info zum Code-Array des opcode einer Instruktion sein. Der Wert von end_pc muss entweder ein gültiger Index im Code-Array des opcode einer Instruktion oder gleich der Code-Array-Länge code_length sein. Der Wert von start_pc muss kleiner als deer von end_pc sein.

Das Element start_pc ist inklusiv und end_pc ist exklusiv, das heißt, die Ausnahme-Handlerfunktion musst aktiv sein, während der Programmzähler innerhalb des Intervalls [starr_pc, end_pc] ist.

handler_pc

Der Wert des Elements handler_pc gibt den Start der Ausnahme- Handlerfunktion an. Der Wert des Items muss ein gültiger Index im Code- Array, muss der Index des opcode einer Instruktion und muss kleiner als der Wert des Elements code_length sein.

catch_type

Ist der Wert des Elements catch_type nicht Null, muss es einen gültigen Java-Klassentyp darstellen. Der durch catch_type dargestellte Java- Klassentyp soll genau demselben Java-Klassentyp entsprechen, welcher durch catch_type in der entsprechenden method_info-Struktur der Original- Klassendatei beschrieben ist. Diese Klasse muss die Klasse Throwable oder einer ihrer Unterklassen sein. Die Exception-Handdlerfunktion wird nur gerufen, wenn die "geworfene" Ausnahme eine Instanz der gegebenen Klasse oder einer ihrer Unterklassen ist.

Ist der Wert des Elements catch_type gleich Null, wird die Ausnahmehandlerfunktion für alle Ausnahmen gerufen. Dies wird zur endgültigen Implementierung genutzt.

Attribute

In der Original-Klassendatei verwendete Attribute werden entweder beseitigt oder zwecks Komprimierung umgeordnet.

Die vordefinierten Attribute SourceFile. ConstantValue, Exceptions, LineNumberTable und Local-VariableTable können ohne Einbusse irgendwelcher für die Java-Byte-Codeübersetzung benötigten Information beseitigt werden.

Der vordefinierte Attribut-Code, welche alle Byte-Codes für eine besondere Methode enthält, wird in die entsprechende MethodInfo-Struktur bewegt.

Vorgaben auf Java Card Virtual Machine Code

Der Java Card Virtual Machine Code für eine Methode, Instanz- Initialisierungsmethode oder Klassen- oder Schnittstellen- Initialisierungsmethode wird im Array-Code der MethodInfo-Struktur einer Karten-Klassendatei gespeichert. Sowohl die statischen als auch die strukturellen Vorgaben auf diesem Code-Array sind dieselben, wie jene, die im Roten Buch beschrieben sind.

Grenzen der Java Card Virtual Machine und des Java Card- Klassendateiformats

Die folgenden Grenzen in der Java Card Virtual Machine werden von dieser Version der Java Card Virtual Machine Specification vorgeschrieben:

Der Klassendatei-Konstantenpool per Karte ist auf 65535 Einsprünge durch das 16-Bit-const_size-Feld der CardClassFile-Struktur () begrenzt. Dies wirkt wie eine interne Grenze auf die gesamte Komplexität einer einzelnen Karten-Klassendatei ein. Die Einsprünge, welche dem Konstantenpool der der Applikation in der Karte zur Verfügung stehenden Klassenhierarchie sind mitgezählt.

Die Code-Menge je Methode ist wegen der Größen der Indizes in der MethodInfo-Struktur auf 65535 Bytes begrenzt.

Die Anzahl lokaler Variablen in einer Methode ist wegen der Größe des Elements max_local der MethodInfo-Struktur () auf 255 begrenzt.

Die Anzahl der Felder einer masse ist wegen der Größe der Elemente max_field und max_sfield der ClassInfo-Struktur () auf 510 begrenzt.

Die Anzahl der Methoden einer Klasse ist wegen der Grösse des Elements max_method der ClassInfo-Struktur () auf 255 begrenzt.

Die Größe eines Operanden-Stacks ist wegen dem Feld max_stack der MethodInfo-Struktur () auf 255 Wörter begrenzt.

Literatur

[] Tim Lindholm und Frank Yellin, The Java Virtual Machine Specification, Addison-Weslay, 1996.

ANHANG B String zum ID-Input und -Output

Für den einwandfreien Betrieb der Card JVM ist es wichtig, dass die deklarierten und erzeugten IDs korrekt verwaltet werden. Diese Verwaltung wird durch die Definitionen im String zur ID-Input-Datei String-ID INMAP kontrolliert. Diese textuelle Datei, die Basis für die nachstehende Darstellung, deklariert, welche Bereiche des Namenplatzes für welche Zwecke genutzt werden können. Eine mögliche Anordnung dieser Aufgliederung kann manche IDs für den internen Gebrauch durch den Card JVM-Interpreter und verwendet werden, und der Rest wird den Card JVM- Applikationen zugewiesen.

constantBase 4000 # Ab hier ist dieser Platz Applikationsabhängig. Im wesentlichen werden allen in eine Chipkarte zu ladenden Applikationen ihre eigenden IDs innerhalb von 0x4000 bis 0x7FFF zugewiesen. Dieser Platz ist für jede Applikation frei, da keiner geladen Applikation der Zugriff auf andere Applikationen erlaubt wird.

Vorsicht ist bei der Verwaltung der IDs für vorgeladene Klassenbibliotheken geboten. Zur Verwaltung dieser IDs kann es hilfreich sein, die (optionale) Generierung des Strings zur ID-Output-File String-ID OUTMAP-File zu nutzen. Diese Aufgliederung ist die mit den neuen String-ID-Bindungen erhöhte String-ID INMAP. Diese Bindungen können erzeugt werden, wenn die Applikation des Karten-Klassendatei-Konverters beendet ist. String-ID OUTMap wird zur Unterstützung von Bibliotheken und OS-Interfaces, welche auf die Karte geladen sind, generiert. Diese Aufgliederung kann als String-ID INMap für Chipkartenapplikationen verwendet werden, weiche die Support-Bibliotheken und OS-Interfaces, die auf die Karte geladen sind, nutzen. Beim Aufbau neuer Applikationen kann diese Karte im allgemeinen ausrangiert werden.

Als Beispiel sei das folgende Java-Programm HelloSmartCard.java gegeben. Wenn kompiliert, generiert es eine Klassendatei HelloSmartCard. class. Diese Klassendatei hat in ihren Strings das eingebettet, was den Kassennamen, die Methode und Typinformation darstellt. Auf der Basis der beschriebenen String-ID INMap generiert der zuvor erwähnte Card Class File Converter eine Klassendatei, welche die in der Klassendatei mit den durch den Card Glass File Converter zugewiesenen IDs ersetzt. Tabelle 1 listet die im Konstantenpool der HelloSmartCard.class gefunden Strings mit ihren jeweils durch Card Class File Converter zugewiesenen IDs auf. Es ist zu beachten, dass manche Strings (wie "java/lang/Object") einen vorzugewiesenen Wert (F002) haben und manche Strings (wie "()V") einen neuen Wert (4004) erhalten.

Programm: HelloSmartCard.java

Relevante Einsprünge von String-ID OUTMap
ANHANG C Von der Card JVM in der bevorzugten Verwirklichung unterstützte Byte- Codes

Standardlässige Java-Byte-Codenummern für die in der bevorzugten Verwirklichtung, unterstützten Byte-Codes

Package util;

ANHANG D Byte-Code-Umsetzungsprozess durch den Karten-Klassendatei- Konverter
ANHANG E Beispiel: Ein Steuerprogramm Laden und Ausführen
ANHANG F Methoden für den Zugriff auf die Möglichkeiten des Kartenbetriebssystems in der Bevorzugten Realisierung

ANHANG G Byte-Code-Attribut-Tabellen Java-Byte-Codes in Typgruppen gliedern

Jedem Byte-Code wird ein 5-Bit-Typ, welcher ihm zugeordnet ist, zugewiesen. Dies dient zur Gruppierung der Codes in sich auf ähnliche Weise verhaltende Sets. Im allgemeinen spiegelt dieses Verhalten wider, wie die Byte-Code-Typen auf dem Stack funktionieren, aber die Typen 0, 13, 14 und 15 drücken spezifische Arten Instruktionen - so wie im Kommentarabschnitt angedeutet - aus.

Die nachstehende Tabelle veranschaulicht den Sack-Status vor und nach der Ausführung jedes Anweisungstyps.

Verwendung des standardmäßigen Java-Byte-Code (ohne Umordnung) - Attribut-Tabelle

ANHANG H Auf Java-Byte-Codes nach Typ durchgeführte Prüfungen

Anweisung decodieren. Dadurch erhalten wir die Länge zur Generierung des nächsten PC und Anweisungstyps.

Ein paar Prüfungen vor der Ausführung auf dieser Basis implementieren:

Abschließend ein paar Prüfungen nach der Ausführung implementieren.

ANHANG I Auf neubezifferten Java-Byte-Codes vorgenommene Prüfungen

Holanweisung. Der numerische Wert der Anweisung enthält implizit den Anweisungstyp:

Insn = getpc(-1);

Ein paar Prüfungen auf dieser Basis vor der Ausführung implementieren.

Abschliessend ein paar Prüfungen nach der Ausführung implementieren:

Nach Typ unterstützte Java-Byte-Codes umordnen


Anspruch[de]

1. Ein Mikrocontroller (10) mit einem Set von Ressourcen-Vorgaben und bestehend aus:

einem Speicher,

einem im Speicher geladenen Interpreter (16), welcher innerhalb des Sets von Ressourcen-Vorgaben funktioniert, dem Mikrocontroller (10), dadurch gekennzeichnet, dass er:

mindestens eine durch den Interpreter zu übersetzende im Speicher geladene Applikation hat, wobei mindestens eine Applikation durch eine Programmierungsumgebung generiert wird, die folgenden Elementen umfasst:

a) einem Compiler (22), welcher Anwendungs-Quellprogramme (20) in Quellcodeform höherer Programmiersprache in eine kompilierte Form (24) kompiliert,

b) einem Konverter (26) zur Umformatierung der kompilierten Form (24) in eine sich zur Übersetzung durch den Interpreter (16) eignende minimierte Form (27).

2. Mikrocontroller (10) gemäss Patentanspruch 1, bei welchem die kompilierte Form (24) Attribute enthält und der Konverter (26) ein Mittel (51d) zur Einfügung der vom Interpreter (16) benötigen Attribute, aber nicht zur Einfügung der vom Interpreter (16) nicht benötigten Attribute, umfasst.

3. Mikrocontroller (10) gemäss Patentanspruch 1 oder 2, bei welchem die kompilierte Form (24) ein standardmäßiges Java-Klassendateiformat ist und der Konverter (26) die im standardmäßigen Java- Klassendateiformat kompilierte Form (24) als Eingabe akzeptiert und die Ausgabe (27) in einer für die Übersetzung durch den Interpreter (16) geeigneten Form erzeugt.

4. Mikrocontroller (10) gemäss einem beliebigen vorhergehenden Patentanspruch, bei welchem der kompilierten Form (24) eine bezeichnende Zeichenkette (String) für Objekte, Klassen, Felder oder Methoden zugewiesen ist und der Konverter ein Mittel enthält, um (57) solche Strings in einheitliche Bezeichner (51b) aufzugliedern.

5. Mikrocontroller (10) gemäss Patentanspruch 4, bei welchem jeder einheitliche Bezeichner eine Ganzzahl ist.

6. Mikrocontroller (10) gemäss Patentanspruch 4 oder 5, bei welchem die Aufgliederung von Strings in einheitliche Bezeichner in einem String zur Map-Datei (30, 32) des Bezeichners gespeichert ist.

7. Mikrocontroller (10) gemäss einem der vorhergehenden Patentansprüche, bei welchem ein erstes Set von Features und ein erstes Set von Datentypen in höherer Programmiersprache unterstützt wird und der Interpreter (16) ein Subset des Sets von Datentypen unterstützt und der Konverter (26) überprüft (51c, 52), ob die kompilierte Form (24) nur Features im Subset des ersten Sets von Features und nur Datentypen im Subset des Sets von Datentypen enthält.

8. Mikrocontroller (10) gemäss Patentanspruch 4, 5, 6 oder 7, bei welchem die kompilierte Form (24) ein Byte-Codeformat ist und der Konverter (26) Mittel zur Übersetzung (54) von Byte-Codes in kompilierter Form (24) in Byte-Codes (27) in ein für die Übersetzung durch den Interpreter (16) geeignetes Format enthält, indem mindestens ein Schritt aus einem Prozess mit folgenden Schritten gewählt wird:

a) Aufzeichnung aller Sprünge und ihr Ziel in den Original-Byte- Codes (61);

b) Umsetzung spezifischer Byte-Codes in gleichwertige generische Byte-Codes oder umgekehrt (63);

c) Verwandlung der Byte-Code-Operanden von Referenzen, welche bezeichnende Strings verwenden, in Referenzen, welche einheitliche Bezeichner (64) verwenden;

d) Neubezifferung von Byte-Codes in kompilierter Form (24) mit gleichwertigen Byte-Codes in dem für die Übersetzung (66) geeigneten Format; und

e) Neuverknüpfung der Sprünge, für welche die Zieladresse über den Umsetzungsschritt b, c oder d (67) erfolgt.

9. Mikrocontroller (10) gemäss einem beliebigen vorstehenden Patentanspruch, dadurch gekennzeichnet, dass das Applikationsprogramm in eine kompilierte Form (24) kompiliert wird, bei welcher die zur Ausführung oder Übersetzung der kompilierten Form (24) benötigten Ressourcen die auf dem Mikrocontroller verfügbaren Ressourcen überschreiten.

10. Mikrocontroller (10) gemäss einem beliebigen vorstehenden Patentanspruch, bei welchem die kompilierte Form (24) zur Portabilität auf verschiedenen Computer-Plattformen bestimmt ist.

11. Mikrocontroller (10) gemäss einem beliebigen vorstehenden Patentanspruch, bei welchem der Interpreter (16) ferner in einer Weise konfiguriert ist, dass er während der Übersetzung einer Anwendung ermittelt, ob eine Anwendung den aus einem Set von Regeln gewählten Sicherheitskriterien gerecht wird mit Hilfe von mindestens einer Regel aus dem Set:

welches der Applikation den Zugriff auf nicht autorisierte Speicherteile sperrt,

welches der Applikation den Zugriff auf nicht autorisierte Mikrocontroller-Ressourcen sperrt,

wobei die Applikation aus Byte-Codes besteht und eine Vielzahl von Byte-Codes mindestens einmal vor der Ausführung prüft,

um sicherzustellen, dass die Ausführung der Byte-Codes keine Sicherheitsvorgabe verletzt.

12. Mikrocontroller (10) gemäss einem beliebigen vorstehenden Patentanspruch, bei welchem mindestens ein Applikationsprogramm durch einen die folgenden Schritte enthaltenden Prozess erzeugt wird:

vor dem Laden der Applikation sicherstellen, dass die Applikation keine Sicherheitsvorgaben verletzt, und die Applikation auf sichere Weise laden.

13. Mikrocontroller (10) gemäss Patentanspruch 12, bei welchem der Schritt zum Laden auf sichere Weise folgenden Schritt enthält:

Überprüfen, ob die Ladeidentität zum Laden von Applikationen auf den Mikrocontroller berechtigt ist.

14. Mikrocontroller (10) gemäss Patentanspruch 12 oder 13, bei welchem der Schritt zum Laden auf sichere Weise folgenden Schritt enthält:

Verschlüsseln der zu ladenden Applikation anhand eines Ladeschlüssels.

15. Eine Methode zur Programmierung eines Mikrocontrollers mit einem Speicher und einem Prozessor, welche gemäss einem Set von Ressourcen-Vorgaben funktionieren, wobei die Methode folgende Schritte umfasst:

Eingabe eines Applikationsprogramms (20) in einer ersten Programmiersprache;

Kompilierung (22) des Applikationsprogramms (20) in der ersten Programmiersprache in einen ersten Zwischencode (24) in Abhängigkeit von der ersten Programmiersprache;

wobei der erste Zwischencode (24) durch mindestens eine virtuelle Maschine für den ersten Zwischencode interpretierbar ist;

wobei die Methode zur Programmierung eines Mikrocontrollers dadurch gekennzeichnet ist, dass:

der erste Zwischencode (24) in einen zweiten Zwischencode (27) umgesetzt (26) wird;

wobei der zweite Zwischencode (27) durch mindestens eine virtuelle Maschine (16) für den zweiten Zwischencode interpretierbar ist; und

Laden des zweiten Zwischencodes in den Speicher des Mikrocontrollers (10).

16. Methode zur Programmierung eines Mikrocontrollers (10) gemäss Patentanspruch 15, dadurch gekennzeichnet, dass der Umsetzschritt ferner folgenden Schritt enthält:

Zuweisung einer bezeichnenden Zeichenkette (String) für Objekte, Klassen, Felder oder Methoden und Aufgliederung solcher Strings in einheitliche Bezeichner (51b).

17. Methode gemäss Patentanspruch 15 oder 16, bei welcher der Aufgliederungsschritt den Schritt zur Aufgliederung von Strings in Ganzzahlen enthält.

18. Methode gemäss Patentanspruch 15, 16 oder 17, bei welcher der Umsetzungsschritt mindestens einen der folgenden Schritte enthält:

a) Aufzeichnung aller Sprünge und ihrer Ziele in den Original-Byte- Codes (61);

b) Umsetzung spezifischer Byte-Codes in gleichwertige generische Byte-Codes oder umgekehrt (63);

c) Änderung der Byte-Code-Operanden von Referenzen, welche bezeichnende Strings verwenden, in Referenzen, welche eindeutige Bezeichner (64) verwenden;

d) Neunummerierung der Byte-Codes im kompilierten Format in äquivalente Byte-Code im für die Übersetzung (66) geeigneten Format; und

e) Neuverknüpfung der Sprünge, für welche die Zieladresse durch den Umsetzungsschritt a), b), c) oder d) (67) ausgeführt wird.

19. Methode gemäss Patentanspruch 15 bis 18, welche ferner dadurch gekennzeichnet ist, dass beim Laden des zweiten Zwischencodes in den Speicher des Mikrocontrollers zusätzlich eine Prüfung des zweiten Zwischencodes, bevor er geladen wird, enthält, um sicherzustellen, dass der zweite Zwischencode einer vordefinierten Integritäts-Prüfung gerecht wird und dass das Laden gemäss dem Sicherheitsprotokoll erfolgt.

20. Methode gemäss Patentanspruch 15 bis 19, dadurch gekennzeichnet, dass eine besondere Identität bestätigt werden muss, damit das Laden vor dem Laden des zweiten Zwischencodes möglich ist.

21. Methode gemäss Patentanspruch 15 bis 20, welche ferner durch die Bereitstellung eines Dechiffrierschlüssels gekennzeichnet ist und wobei das Sicherheitsprotokoll bedingt, dass der zweite Zwischencode anhand eines dem Dechiffrierschlüssel entsprechenden Ladeschlüssels verschlüsselt wird.

22. Mikrokontroller gemäss jedem beliebigen Patentanspruch 1 bis 14, welcher ferner dadurch gekennzeichnet, dass:

a) der Interpreter ablauffähig zur Übersetzung des in einer Ableitung der interpretierbaren Sprache des kompilierten Programms (27) geschrieben ist - wobei eine Ableitung eines in der interpretierbaren Programmiersprache geschriebenen Programms vom in der interpretierbaren Programmiersprache geschriebenen Programm abgeleitet ist - indem mindestens eine aus einem Set Regeln gewählte Regel angewandt wird mit:

(1) Durchführung von Sicherheitsprüfungen vor oder während der Übersetzung;

(2) Durchführung von strukturellen Prüfungen vor oder während der Übersetzung;

(3) Durchführung semantischer Prüfungen vor oder während der Übersetzung.

23. Mikrocontroller (10) gemäss Patentanspruch 22, bei welchem die abgeleiteten Programme Klassendateien oder Ableitungen von Klassendateien sind.

24. Mikrocontroller (10) gemäss jedem beliebigen Patentanspruch 22 oder 23, welcher ferner dadurch gekennzeichnet ist, dass der Speicherinhalt kleiner als 1 Megabyte ist.

25. Mikrocontroller (10) gemäss jedem beliebigen Patentanspruch 22 bis 24, bei welchem Sicherheitsprüfungen des Mikrocontrollers ferner folgende Merkmale aufweisen:

(b) Logikteil für den Empfang einer Anforderung von einem Anforderer für den Zugriff auf eine Vielzahl abgeleiteter Programme;

(c) Ermittlung - nach dem Empfang der Anforderung - ob eines aus der Vielzahl abgeleiteten Programme mit einem vordefinierten Set von Regeln übereinstimmt; und

(d) auf der Basis der Ermittlung dem Anforderer einen selektiven Zugriff zu einer Applikation aus der Vielzahl zu gewähren.

26. Mikrocontroller (10) gemäss Patentanspruch 25, bei welchem die vordefinierten Regeln durch den Interpreter während der Übersetzung des abgeleiteten Programms durchgesetzt werden durch Ermittlung, ob das abgeleitete Programm die Zugriffsberechtigung zu einem besonderen Speicherteil hat, auf welchen das abgeleitete Programm zuzugreifen versucht.

27. Mikrocontroller (10) gemäss jedem beliebigen Patentanspruch 22 bis 26, welcher ferner dadurch gekennzeichnet ist, dass der Mikrocontroller zur Durchführung von mindestens einer aus dem Set von Mitgliedern gewählten Sicherheitsprüfung konfiguriert ist:

a) Durchsetzung der vordefinierten Sicherheitsregelen, während das abgeleitete Programm übersetzt wird, wodurch dem abgeleiteten Programm der Zugriff auf nicht autorisierte Speicherteile oder nicht autorisierte Mikrocontroller-Ressourcen gesperrt wird.

b) Konfigurierung des Interpreters in einer Weise, dass jeder Byte- Code mindestens einmal vor der Ausführung geprüft wird, um zu ermitteln, ob der Byte-Code in Übereinstimmung mit Prüfungen vor und nach der Ausführung ausgeführt werden kaum.

c) Prüfung des abgeleiteten Programms vor dem Laden in den Mikrocontroller, um seine Integrität und das Laden in Übereinstimmung mit einem Sicherheitsprotokoll sicherzustellen.

28. Mikrocontroller (10) gemäss Patentanspruch 27, bei welchem das Sicherheitsprotokoll die Bestätigung einer besonderen Identität vorschreibt, um das Laden eines abgeleiteten Programms auf eine Karte zu ermöglichen.

29. Mikrocontroller (10) gemäss Patentanspruch 27, welcher ferner durch das Vorhandensein eines Dechiffrierschlüssels gekennzeichnet ist, wobei das Sicherheitsprotokoll vorschreibt, dass ein zu ladendes abgeleitetes Programm anhand eines dem Dechiffrierschlüssel entsprechenden Ladeschlüssels zu laden ist.

30. Mikrocontroller (10) gemäss jedem beliebigen Patentanspruch 22 bis 29, des weiteren dadurch gekennzeichnet, dass er zur Beistellung von Verschlüsselungs-Services, welche aus dem die Chiffrierung, Dechiffrierung, Unterschrift, Signaturprüfung, gegenseitige Authentifizierung, den Transportschlüssel und Sitzungsschlüssel enthaltenden Set gewählt wurden, konfiguriert ist.

31. Mikrocontroller (10) gemäss jedem beliebigen Patentanspruch 22 bis 30, des weiteren durch ein Dateisystem gekennzeichnet, welches zur Beistellung eines sicheren Zugriffs auf das Dateisystem über ein aus dem Set gewählten Mittel konfiguriert ist, bestehend aus:

a) dem Mikrocontroller, welcher Zugriff auf Kontroll-Listen zur Berechtigung zum Lesen ab einer Datei, Schreiben auf eine Datei, Löschen einer Datei hat,

b) dem Mikrocontroller, welcher die Schlüsselfreigabe zum Aufbau der Zugangsberechtigung zu einer Datei durchsetzt, und

c) dem Mikrokontroller zur Überprüfung der Kartenträgeridentität zum Aufbau der Zugangsberechtigung zu einer Datei.

32. Ein Computer-Programmprodukt für einen Mikrocontroller (10) mit einem Set von Ressourcen-Vorgaben und mit einem Speicher und einem im Speicher geladenen Interpreter (16), welcher innerhalb des Sets von Ressourcen-Vorgaben lauffähig ist, wobei das Computer- Programmprodukt mindestens eine vom Interpreter zu übersetzende in den Speicher des Mikrocontrollers (10) ladbare Applikation umfasst, wobei die Applikation von einer Programmierumgebung erzeugt wurde, die folgenden Elementen umfasst:

a) einem Compiler (22), welcher Anwendungs-Quellprogramme (20) in Quellcodeform höherer Programmiersprache in eine kompilierte Form (24) kompiliert,

b) einem Konverter (26) zur Umformatierung der kompilierten Form (24) in eine sich zur Übersetzung durch den Interpreter (16) eignende minimierte Form (27).

33. Eine Karte die einen Mikrocontroller gemäss Patentanspruch 1 umfasst.







IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com