WO2005055052A2 - Java smart card chip mit für globale variablen reserviertem speicherbereich - Google Patents

Java smart card chip mit für globale variablen reserviertem speicherbereich Download PDF

Info

Publication number
WO2005055052A2
WO2005055052A2 PCT/EP2004/013797 EP2004013797W WO2005055052A2 WO 2005055052 A2 WO2005055052 A2 WO 2005055052A2 EP 2004013797 W EP2004013797 W EP 2004013797W WO 2005055052 A2 WO2005055052 A2 WO 2005055052A2
Authority
WO
WIPO (PCT)
Prior art keywords
smart card
memory area
card chip
java
variable memory
Prior art date
Application number
PCT/EP2004/013797
Other languages
English (en)
French (fr)
Other versions
WO2005055052A3 (de
Inventor
Siegfried Vollmann
Manouchehr Hosseini
Monika Uminska-Ziesche
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to US10/582,118 priority Critical patent/US7702872B2/en
Priority to EP04803515A priority patent/EP1695207A2/de
Publication of WO2005055052A2 publication Critical patent/WO2005055052A2/de
Publication of WO2005055052A3 publication Critical patent/WO2005055052A3/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments
    • G06Q20/3563—Software being resident on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/17—Embedded application
    • G06F2212/177—Smart card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators

Definitions

  • the invention relates to a smart card chip with a virtual Java card machine and a memory area reserved for global variables.
  • the invention further relates to a module and a smart card with such a chip and a method for implementing a Java program code, in particular Java package, in such a smart card chip.
  • Smart cards i.e. Chip cards with a microprocessor are already being used today and will probably be used in a variety of applications, for example in mobile devices such as Mobile phones as SIM cards or USIM cards, as bank cards or electronic purses in electronic payment transactions, as health cards for insured persons of health insurance (patient card) and doctors (doctor card), as citizen cards, or as multi-application cards in which several of the named or other functionalities are implemented.
  • mobile devices such as Mobile phones as SIM cards or USIM cards, as bank cards or electronic purses in electronic payment transactions, as health cards for insured persons of health insurance (patient card) and doctors (doctor card), as citizen cards, or as multi-application cards in which several of the named or other functionalities are implemented.
  • a smart card chip has a plurality of memory areas, namely the non-volatile, write-once ROM, the non-volatile, rewritable EEPROM and the volatile, rewritable RAM.
  • the ROM and / or the EEPROM can be replaced by flash memories.
  • the chip manufacturer When the smart card chip is being manufactured, the chip manufacturer first implements a portion of the program code called a ROM mask, which primarily contains the operating system. The smart card manufacturer, who obtains the chip with the implemented ROM mask from the chip manufacturer, then carries out the completion of the smart card, with additions to the operating system and Applications of the smart card manufacturer can be implemented in the EEPROM. After completion, the smart card chip is ready for delivery to the customer.
  • a ROM mask which primarily contains the operating system.
  • the smart card manufacturer who obtains the chip with the implemented ROM mask from the chip manufacturer, then carries out the completion of the smart card, with additions to the operating system and Applications of the smart card manufacturer can be implemented in the EEPROM. After completion, the smart card chip is ready for delivery to the customer.
  • Object-oriented programming languages in particular Java TM from Sun Microsystems Inc., are very suitable for creating platform-independent and well-secured applications.
  • Java TM from Sun Microsystems Inc.
  • the runtime environments of object-oriented programming languages such as Java TM are usually too extensive to be easily implemented in a smart card chip.
  • Java Card TM technology from Sun Microsystems Inc., which e.g. in the current - and continuously updated - version in the document "Java Card TM 2.2 Runtime Environment (JCRE) Specification" (currently available at http://java.sun.com/products/javacard) represents a modified Java technology for runtime environments with limited system resources, which is also suitable for smart cards.
  • Java Card TM 2.2 Runtime Environment (JCRE) Specification currently available at http://java.sun.com/products/javacard
  • the runtime environment provided in the Java Card (more precisely in the chip) in accordance with the JCRE specification comprises at least the Java Card Virtual Machine (JCVM) and the Java Card Application Programming Interface (API) classes, and possibly other components.
  • JCVM Java Card Virtual Machine
  • API Java Card Application Programming Interface
  • the virtual machine of the Java card or virtual Java card machine (in the narrower sense) is understood to mean the on-card portion of the virtual Java card machine (in the broader sense).
  • the term virtual machine (VM) is therefore interpreted in the narrower sense and equated with that provided for on the Java Card On-card portion of the VM.
  • an off-card portion of the VM can also be provided in the broader sense.
  • a created program source code of a predetermined program e.g. A program to be loaded onto a Java Card TM is first compiled in the Java TM card technology, like in the Java TM technology, by means of a compiler, so that a class file is generated which has the format of an intermediate code, namely the Java byte code that can be interpreted by the Java virtual machine.
  • the compilation and conversion is carried out outside the Java Card, "Off-Card".
  • the cap file, and thus ultimately the predetermined program is loaded onto the Java Card and the bytecode of the cap file is linked.
  • the oncard linker is implemented in the Java Card (in the chip) and is functional without further components.
  • the offcard linker needs an export file that contains information for the linker and that is not loaded into the Java Card (the chip).
  • the virtual Java Card machine finally interprets the converted and linked bytecode of the cap files and executes it.
  • Java program code is stored in the form of packages. Each package contains part of the program code, e.g. data or one or more individual programs. The individual programs can either be system functions of the operating system (in compiled form: system classes) or applications. The structuring of the program code into packages is also retained in the converted cap file.
  • each package also contains an import component and an export component in the cap file.
  • the import component specifies which access options the package needs to other packages, for example which methods from other packages the package would like to use.
  • the required access options are specified, for example, by a reference "import ⁇ other package>" in the import component.
  • a reference "import ⁇ ...> / reference which in terms of form is a name reference (reference that is based on a name is directed, for example to “another package”), is usually converted into a so-called token when the cap file is generated, which is formally a number reference (reference which is directed to a number).
  • the export component specifies which access options the package offers to other packages, ie which methods the package makes available to other packages for use.
  • the access options made available are achieved, for example, by specifying an address in the export component, the address specifying the storage location of the program code provided.
  • Linking ensures that a new package loaded into a Java Card can actually access a predetermined other package and use its program code.
  • the newly loaded package loads link information (eg an address) from the export component of the other package into its own import component. For example, when linking, a token, ie a number reference generated from an "import" reference, is replaced in the import component of the new package with an address from the export component of the other package. The token (the reference) is thereby replaced with the The link and thus the actual use can only be set up if the newly loaded package has the export component of the other package, whose program code wants to use the new package, available stands.
  • link information eg an address
  • the export components of all packages that are implemented in a Java Card, or a predetermined subset of all of these export components, are summarized in the export file. If an additional (new) package is loaded into the Java Card before the Java Card is completed, it is linked using the offcard linker and the export file. After completing the Java Card, only the oncard linker can be used for linking.
  • Applications are usually implemented in the form of applets in the Java Card, the applets in turn being grouped into application packages.
  • preloaded packages preissuance packages
  • postloaded packages postloaded packages that are loaded into the Smart 'Card Chip after they have been completed, usually by the customer or customer, for example a credit institution or an authority.
  • the contents (e.g. applets or system functions) of different packages are protected against each other by firewalls, whereas the contents (applets etc.) within one and the same package are not protected against each other by firewalls.
  • Java provides a number of different types of variables.
  • variables eg instance variables or equivalent object variables (instance variables), local variables (local variables) and method parameters (method parameters).
  • they are not global, ie they can only be used within the context (ie within the object, the process or the method) in or with which they were created.
  • the firewall prevents the variables from being used, ie access to the variables from outside the context is prevented by the firewall.
  • the memory area reserved for instance variables is on the heap memory, in the non-volatile EEPROM (or alternatively in the flash memory).
  • the memory area reserved for local variables is on the stack memory, in RAM, and has only a short lifespan, namely the duration of the method execution.
  • Variables in Java are class variables that are statically generated variables (class variables, stalle variables).
  • the object of the invention is therefore to provide a smart card chip with a virtual Java card machine and a memory area reserved for global variables, which enables simple, fast access to the global variables which is gentle on the chip.
  • the smart card chip according to claim 1 has a variable memory area reserved for global variables, which is reserved in volatile working memory, for example in RAM. Access to the volatile working memory is fast and, in addition, the fact that the volatile working memory is used rather protects the non-volatile application memory, in particular EEPROM or a flash memory. This enables the chip According to claim 1 simple, fast and easy access to the global variables for the chip.
  • a smart card chip is created with a virtual Java card machine and a memory area reserved for global variables, which enables simple, fast and gentle access to the global variables for the chip.
  • the invention is particularly well suited for global variable applications where the variables must be global, e.g. because they have to be available beyond context boundaries, but for which a long lifespan of the variables is not necessary. Because the (fast) RAM memory, in which the memory area is reserved for the variables and in which the variables are created if required, is volatile. As a result, the variables created are deleted as soon as the energy supply to the RAM is interrupted.
  • variable memory area is preferably statically reserved, for example in that the variable memory area is reserved for class variables (synonymous: variables of the static type) because the
  • Access to the variables is particularly quick with a static reservation.
  • Access (read or write access) to the statically reserved variable memory area means that a statically reserved variable (variable of the static type) is used (read or overwritten). Since no firewall check is carried out when using statically reserved variables, the static reservation of the variable memory area has the additional advantage that access to the variables is faster than if the variable memory area were dynamic during the runtime of the program. It is therefore particularly preferred that the variable memory area be statically reserved.
  • variable memory area that can link to the variable memory area.
  • the ability of a program to be able to link to the variable memory area is preferably achieved in that the program for the link has an export component on the smart card chip.
  • the variable memory area appears to a program that wants to access it like a foreign program. Therefore, the program that wants to access the variable memory area needs the export information of the foreign program that created the variable memory area.
  • a program that wants to use the reserved variable memory area has the export component of a third-party program that created the variable memory area available for linking.
  • variable memory area that cannot link to the variable memory area.
  • the inability of a program to be able to link to the variable memory area is preferably achieved in that the program to the left is denied an export component of the smart card chip.
  • variable memory area is further preferably reserved in that a corresponding Java packet is stored in a system memory of the chip which preferably contains only the reservation of the variable memory area.
  • a Java package with the name eg "com.gieseckedevrient.javacard.os.commonram", which reserves memory space for a plurality of static variables "myRamVarA", “myRamVarB”, etc. of the data type short and byte and int for example have the following form: package com. gieseckede vrient.j avacar d.os. commonr am; static short myRamVarA; static short myRamVarB; etc.
  • the Java package is stored in the system memory (ROM, possibly also flash memory).
  • the corresponding data i.e. the static, global variables of the type short, byte, int stored in RAM.
  • variable memory area can only be accessed by programs stored in the system memory (ROM, Flash).
  • ROM read-only memory
  • Flash system memory
  • only programs that have been implemented in the smart card chip until the completion of the smart card chip can preferably access the variable memory area.
  • the export component is made available for linking only for packages that are implemented up to completion.
  • a loaded package that is up to completion is implemented, is preferably linked to the off card linker and the export file.
  • This loads the link information for linking to the variable memory area from the export component of the Java package, which reserves the variable memory area, into the import component of the loaded package.
  • the loaded packet can access the reserved variable memory area and there, in RAM, can use the RAM variables.
  • Packages that are implemented in the Java Card or chip after completion do not have the link information from the export component of the Java package that reserved the variable memory area in their import components. Therefore, according to the preferred embodiment, packets implemented after completion cannot use the RAM variables according to the invention, ie cannot access the reserved variable memory area in RAM.
  • the virtual Java card machine is preferably designed in this way and, if necessary, modified in relation to the virtual Java card machine in accordance with the Java Card VM specification in such a way that it uses the variable memory area based on the variable memory area reserved in the volatile main memory (RAM) global variables in RAM.
  • RAM main memory
  • the commands “getstatic” and “putstatic” of the virtual Java Card machine are modified as required in relation to the commands “getstatic” and “putstatic” virtual Java Card machine in accordance with the Java Card VM specification.
  • the modifications or changes made to the virtual Java card machine if necessary are preferably carried out in such a way that that the modifications / changes in the use of the VM are not recognizable externally.
  • the fact that the modifications cannot be recognized qualitatively means in particular that the smart card chip complies with a predetermined Java Card specification, which the chip would also meet without the modifications.
  • the modifications can optionally be recognizable externally, for example it can be externally recognizable that the use of the global RAM variables according to the invention is faster than the use of known global variables from the prior art.
  • the changes made to the "getstatic" and “putstatic” commands when necessary are preferably carried out in such a way that the use (for example creation, change variable value) of static variables using the “getstatic” and “putstatic” commands is unchanged from the use (eg create, change variable value) of static variables according to the Java Card VM specification.
  • Adherence to the specifications is preferably also ensured to the extent that a normal user cannot use the reserved variable memory area, ie no RAM according to the invention.
  • Can use variables because he lacks the link information because he is denied the export file required for linking.
  • the export file is kept by the manufacturer of the smart card and kept secret from users and buyers of smart cards.
  • only program developers of system programs (and optionally additionally preloaded packages) that are linked before completion can use the RAM variables according to the invention, since only these program developers of system programs (and possibly preloaded packages) use the secret export file and thus the the link information required to link to the reserved variable memory area is available. Only program developers of system programs (and possibly preloaded packages) are therefore exempt from the general confidentiality of the export file.
  • Smart card users who load programs (e.g. applications) into the smart card (or into the smart card chip) after completing the smart card can only use the oncard linker for linking, which contains the link information for linking to the reserved variable memory area in RAM.
  • 1 shows a schematic illustration of a Java card with a RAM package 5 implemented therein, by means of which a variable memory area 18 is statically reserved in the RAM of the Java card, in accordance with a preferred embodiment of the invention.
  • 1 has a non-volatile system memory 1, namely ROM 1, a non-volatile application memory 2, namely EEPROM 2, and a volatile working memory 3, namely RAM 3.
  • the virtual Java card machine VM 4 and further native code are implemented in ROM 1.
  • a number of packages Pckgl, Pckg2, ... Pckgn with different contents, partly system functions and partly applications, are implemented in ROM 1.
  • the RAM package 5 according to the invention is implemented in the ROM 1, that is to say the Java package, by which the variable memory area 18 is reserved in the RAM.
  • Several packages with applications, namely several preloaded EEPROM packages 16, are stored in EEPROM 2 before they are completed in the Java Card.
  • the EEPROM 2 contains a heap memory 19 with dynamic data (dynamic data), a plurality of buffers (buffers) and an area with native data.
  • the RAM 3 contains native RAM data, the variable memory area 18 (RamP.-Data) reserved by the RAM package, two buffer memories (buffers), a working memory area which is deleted on request (COD, Clear On Demand) and a working memory area which is deleted on reset, i.e. on reset (COR, Clear On Reset).
  • the virtual machine VM 4 in FIG. 1 contains, for example, the commands of the VM 4, such as “putstatic” 7, with which a static variable can be changed at runtime, as shown by the enlarged section 7 of the VM with the label “Putstatic” is indicated.
  • SAT access table
  • segment allocation table implemented in the Java Card, which contains, among other things, the start addresses of the packages implemented in the Java Card.
  • the access table SAT contains a static area descriptor 8, in particular for the RAM package, i.e. a descriptor 8 (or a specification) contained in the RAM package 5, which specifies a beginning and a size of a specific address area as a storage area for statically declared (reserved) variables.
  • the descriptor 8 (static area descriptor) contains two parts, namely the start address of the address area and the size of the address area. The starting address is chosen such that the address area determined by the static area descriptor 8 is in the RAM 3 of the Java Card, as indicated by the arrows 12, 13, which run from the descriptor 8 (static area descriptor) to the RAM 3. The selection of the start address made in this way (i.e.
  • descriptor 8 static area descriptor refers to an address in RAM represents a change compared to the Java Card VM specification, which is however not recognizable from the outside.
  • the package 6 shown in FIG. 1 with the number “n”, designated “Pckgn”, is a preloaded package, ie a package that was implemented in the Java Card before the Java Card was completed, and contains in the ROM memory 1 of the package code 9 stored in the Java Card, as indicated by the enlarged section 9 “preloaded pack. Code "is indicated.
  • the Pa- ket code 9 of preloaded package 6 in turn contains code for a constant pool 10 (“const. pool”) and code 11 for the “putstatic” command of the VM.
  • "Putstatic" 11 in the code of preloaded package 6 uses variable pool 10 to address a variable of the static type, namely in RAM 3, in reserved variable memory area 18, as indicated by arrows 14, 15, those from “Code putstatic” to "Const. Pool ... "(arrow 14) and from” Const. Pool ... “to” RamP. Data “(arrow 15).
  • the preloaded package package Pckgn 6 was linked by the offcard linker and using the export file of the Java Card.
  • the preloaded package package Pckgn 6 was provided with link information from RAM package 5, in particular with the address that stands for static variables (static area descriptor) in the descriptor 8. As a result, the preloaded package Pckgn 6 has the link information of the RAM package 5. Consequently, the preloaded package Pckgn 6 can use the reserved variable memory area 18 of the RAM package 5, thus use global variables according to the invention (RAM static variables).
  • a postloaded package 16 which is implemented in the EEPROM, cannot access the variable memory area 18 reserved in RAM 3, so that the postloaded package 16 in the
  • EEPROM cannot use global variables according to the invention in RAM. Only packages in system memory ROM can use the global variables in RAM.
  • preloaded packages in the EEPROM can also use the global variables in the RAM.
  • the preloaded packages in the ROM then have, like the packages in the system memory ROM also, the address information provided by the offcard linker in the export file with which you can link to the reserved variable memory area so that you can use the reserved variable memory area in RAM for variables.

Abstract

Die Erfindung schafft einen Smart Card Chip mit einem nichtflüchtigen Systemspeicher (ROM, Flash1), einer in dem nichtflüchtigen Systemspeicher (ROM, Flash1) implementierten virtuellen Java-Card-Maschine, einem nichtflüchtigen Anwendungsspeicher (EEPROM, Flash2), einem flüchtigen Arbeitsspeicher (RAM) und einem für globale Variablen reservierten Variablen-Speicherbereich, wobei der Variablen-Speicherbereich im flüchtigen Arbeitsspeicher (RAM) reserviert ist. Der Variablen-Speicherbereich ist vorzugsweise statisch reserviert. Die Verwendung der Variablen kann auf Systempackages und wahlweise zudem auf preloaded (ROM/EEPROM) packages beschränkt sein.

Description

Tava Smart Card Chip mit für globale Variablen reserviertem Speicherbereich
Die Erfindung betrifft einen Smart Card Chip mit einer virtuellen Java-Card- Maschine und einem für globale Variablen reservierten Speicherbereich. Weiter betrifft die Erfindung ein Modul und eine Smart Card mit einem derartigen Chip sowie ein Verfahren zum Implementieren eines Java Programmcodes, insbesondere Java Pakets, in einen solchen Smart Card Chip.
Smart Cards, d.h. Chipkarten mit Mikroprozessor, werden bereits heute und künftig voraussichtlich noch verstärkt bei einer Vielzahl von Anwendungen eingesetzt, beispielsweise bei Mobilgeräten wie z.B. Mobiltelefonen als SIM- Karten bzw. USIM-Karten, als Bankkarten oder elektronische Geldbörsen im elektronischen Zahlungsverkehr, als Gesundheitskarten für Versicherte von Krankenversicherungen (Patientenkarte) und Ärzte (Ärztekarte), als Bürger- karten, oder als Multiapplikationskarten, in denen mehrere der genannten oder anderer Funktionalitäten implementiert sind.
Ein Smart Card Chip hat eine Mehrzahl von Speicherbereichen, nämlich den nichtflüchtigen, nur einmal beschreibbaren ROM, den nichtflüchtigen, wie- derbeschreibbaren EEPROM und den flüchtigen, wiederbeschreibbaren RAM. Alternativ können Teile des ROM und/oder des EEPROM durch Flash-Speicher ersetzt sein.
Bei der Herstellung des Smart Card Chips wird zunächst durch den Chip- hersteller ein ROM-Maske genannter Programmcode- Anteil, der vor allem das Betriebssystem enthält, in den ROM implementiert. Anschließend wird, in der Regel durch den Smart Card Hersteller, der den Chip mit der implementierten ROM-Maske vom Chiphersteller bezieht, die Komplettierung der Smart Card durchgeführt, bei der Ergänzungen zum Betriebssystem und Anwendungen des Smart Card Herstellers in den EEPROM implementiert werden. Nach erfolgter Komplettierung ist der Smart Card Chip fertig zur Herausgabe an den Kunden.
Um plattformunabhängige und gut gegeneinander abgesicherte Anwendungen zu erstellen, eignen sich objektorientierte Programmiersprachen, insbesondere Java™ der Firma Sun Microsystems Inc., sehr gut. Die Laufzeitumgebungen objektorientierter Programmiersprachen wie Java™ sind jedoch in der Regel zu umfangreich, um sie ohne Weiteres in einen Smart Card Chip implementieren zu können.
Die Java Card™ Technologie der Firma Sun Microsystems Inc., die z.B. in der aktuellen - und laufend aktualisierten - Version in dem Dokument "Java Card™ 2.2 Runtime Environment (JCRE) Specification" (derzeit verfügbar unter http://java.sun.com/products/javacard) dargelegt ist, stellt eine abgewandelte Java Technologie für Laufzeitumgebungen mit beschränkten Systemressourcen dar, die sich auch für Smart Cards eignet.
Die in der Java Card (genauer im Chip) vorgesehene Laufzeitumgebung ge- maß der JCRE Spezifikation umf asst zumindest die virtuelle Java-Card- Maschine (Java Card Virtual Machine) (JCVM) und die Java Card Application Programming Interface (API) Klassen, und ggf. noch weitere Komponenten. Im Zusammenhang mit der Erfindung wird unter der Virtuellen Maschine der Java Card oder virtuellen Java-Card-Maschine (im engeren Sinn) der On-Card- Anteil der virtuellen Java-Card-Maschine (im weiteren Sinn) verstanden. Der Begriff der virtuellen Maschine (VM) wird also im engeren Sinn auf gef asst und gleichgesetzt mit dem auf der Java Card vorgesehenen On-Card- Anteil der VM. Neben dem On-Card- Anteil kann zusätzlich ein Off -Card- Anteil der VM im weiteren Sinn vorgesehen sein.
Ein erstellter Programm-Quellcode (Source Code) eines vorbestimmten Pro- gramms, z.B. eines auf eine Java Card™ zu ladenden Programms, wird bei der Java™ Card Technologie zunächst, wie bei der Java™ Technologie, mittels eines Compilers kompiliert, so dass eine Klassendatei erzeugt wird, die das Format eines Zwischencodes, nämlich des Java Bytecode, hat, der durch die virtuelle Java-Maschine interpretierbar ist. Anschließend wird bei der Java™ Card Technologie, im Unterschied zur Java™ Technologie, der Bytecode der Klassendatei zusätzlich mittels eines Konverters in einen konvertierten Bytecode in einer cap-Datei (cap = Card Application Protocol) konvertiert. Die Compilierung und Konvertierung wird außerhalb der Java Card, „Off -Card", durchgeführt. Die cap-Datei, und somit letzten Endes das vorbe- stimmte Programm, wird auf die Java Card geladen, und der Bytecode der cap-Datei wird gelinkt. Beim Linken werden u.a. Zugriffsmöglichkeiten des mit der cap-Datei auf die Java Card geladenen Programms auf andere in der Java Card vorhandene Programmcode-Elemente eingerichtetd.h. es werden Verbindungen zwischen den einzelnen Packages hergestellt. Beim Linken ist zu unterscheiden zwischen dem Offcard-Linker und dem Oncard-Linker.
Der Oncard-Linker ist in der Java Card (im Chip) implementiert und ist ohne weitere Komponenten funktionsfähig. Der Offcard-Linker benötigt zum Linken eine Export-Datei, die Informationen für das Linken enthält, und die nicht mit in die Java Card (den Chip) geladen wird. Die virtuelle Java-Card- Maschine interpretiert schließlich den konvertierten und gelinkten Bytecode der cap-Dateien und führt ihn aus. In der Regel ist Java-Programmcode in Form von Paketen (packages) abgelegt. Jedes Paket enthält einen Teil des Programmcodes, z.B. Daten oder ein oder mehrere einzelne Programme. Die einzelnen Programme können entweder Systemfunktionen des Betriebssystems (in kompilierter Form: Systemklassen) oder Anwendungen sein. Die Strukturierung des Programmcodes in Pakete ist auch in der konvertierten cap-Datei beibehalten.
In der cap-Datei enthält jedes Paket neben dem eigentlichen Programmcode zusätzlich eine Import-Komponente und eine Export-Komponente.
In der Import-Komponente ist festgelegt, welche Zugriffsmöglichkeiten das Paket auf andere Pakete benötigt, z.B. welche Methoden aus anderen Paketen das Paket benutzen möchte. Die benötigten Zugriffsmöglichkeiten werden beispielsweise durch eine Referenz „import<anderes Paket>" in der Im- port-Komponente angegeben. Dabei wird eine solche „import<...> /-Referenz, die der Form nach eine Namensreferenz (Referenz, die auf einen Namen gerichtet ist, z.B. auf „anderes Paket") ist, bei der Erzeugung der cap-Datei i.d.R. in ein sogenanntes Token umgewandelt, das der Form nach eine Nummernreferenz (Referenz, die auf eine Nummer gerichtet ist) ist.
In der Export-Komponente ist festgelegt, welche Zugriffsmöglichkeiten das Paket anderen Paketen bietet, d.h. z.B. welche Methoden das Paket anderen Paketen zur Benutzung zur Verfügung stellt. Die zur Verfügung gestellten Zugriffsmöglichkeiten werden beispielsweise durch die Angabe einer Adres- se in der Export-Komponente erzielt, wobei durch die Adresse der Speicherort des zur Verfügung gestellten Programmcodes angegeben ist. Dass ein neu in eine Java Card geladenes Paket tatsächlich auf ein vorbestimmtes anderes Paket zugreifen und dessen Programmcode nutzen kann, wird durch das Linken eingerichtet. Dabei, beim Linken, lädt das neu geladene Paket Linkinformation (z.B. eine Adresse) aus der Export-Komponente des anderen Pakets in die eigene Import-Komponente. Beispielsweise wird beim Linken ein Token, d.h. eine aus einer „import"-Referenz erzeugte Nummernreferenz, in der Import-Komponente des neuen Pakets durch eine Adresse aus der Export-Komponente des anderen Pakets ersetzt. Hierdurch wird der Token (die Referenz) mit dem Benutzungswunsch durch eine tat- sächliche Adress-Verknüpfung zwischen den beiden Paketen ersetzt. Die Verknüpfung und damit die tatsächliche Benutzungsmöglichkeit kann nur eingerichtet werden, wenn dem neu geladenen Paket die Export-Komponente des anderen Pakets, dessen Programmcode das neue Paket nutzen will, zur Verfügung steht.
Die Export-Komponenten aller Pakete, die in einer Java Card implementiert sind, oder eine vorbestimmte Teilmenge aller dieser Export-Komponenten, sind in der Export-Datei zusammengefasst. Wird vor der Komplettierung der Java Card ein zusätzliches (neues) Paket in die Java Card nachgeladen, wird es unter Verwendung des Offcard-Linkers und der Export-Datei gelinkt. Nach der Komplettierung der Java Card kann zum Linken nur der Oncard-Linker verwendet werden.
Anwendungen sind in der Regel in Form von Applets in der Java Card imp- lementiert, wobei die Applets wiederum zu Anwendungs-Paketen gruppiert sind. Bei den Anwendungs-Paketen gibt es sogenannte preloaded packages (preissuance packages), die vor oder bei der Komplettierung in den Smart Card Chip implementiert werden, und die in der Regel durch den Smart Card Hersteller implementiert werden. Weiter gibt es postloaded packages (postissuance packages), die nach erfolgter Komplettierung in den Smart ' Card Chip geladen werden, in der Regel durch den Abnehmer oder Kunden, beispielsweise ein Kreditinstitut oder eine Behörde.
Die Inhalte (z.B. Applets bzw. Systemfunktionen) unterschiedlicher Pakete sind durch Firewalls gegeneinander abgesichert, wohingegen die Inhalte (Applets etc.) innerhalb ein und desselben Pakets nicht mittels Firewalls ge- geneinander abgesichert sind.
Java stellt eine Reihen von unterschiedlichen Variablentypen zur Verfügung. Z.B. gibt es eine Reihe von nicht globalen, auf ihren Kontext beschränkten und dynamisch erzeugten Variablen, z.B. Instanzvariablen oder gleichbedeu- tend Objektvariablen (instance variables), lokale Variablen (local variables) und Methodenparameter (method parameters). Instanzvariablen, lokale Variablen, Methodenparameter haben gemeinsam, dass sie dynamisch während der Laufzeit eines Programms mit dem Objekt (= Instanz einer Klasse), dem Ablauf (z.B. Programmschleife), der Methode etc. erzeugt werden, zu dem sie gehören und nur so lange existieren wie das Objekt, der Ablauf bzw. die Methode existiert, d.h. sie sind transient. Zudem sind sie nicht global, d.h. sie sind nur innerhalb des Kontexts (d.h. innerhalb des Objekt, des Ablaufs bzw. der Methode) verwendbar, in bzw. mit dem sie erzeugt worden sind. Über den Kontext hinaus verhindert die Firewall, dass die Variablen verwendet werden, d.h. der Zugriff auf die Variablen von außerhalb des Kontext ist durch die Firewall verhindert. Der für Instanzvariablen reservierte Speicherbereich liegt auf dem heap- Speicher, im nichtflüchtigen EEPROM (oder alternativ im Flash-Speicher). Der für lokale Variablen reservierte Speicherbereich liegt auf dem Stack- ' Speicher, im RAM, und hat nur eine kurze Lebensdauer, nämlich die Dauer der Methoden- Ausführung.
Der Nachteil der nicht globalen Variablen ist, dass sie außerhalb ihres Kontext nicht verwendbar sind.
Neben den bereits genannten Variablen gibt es als die einzigen globalen
(s.u.) Variablen bei Java die Klassenvariablen, die statisch erzeugte Variablen sind (class variables, stalle variables).
Klassenvariablen (gleichbedeutend verwendeter Begriff: static Variablen) sind globale Variablen, d.h. sie sind nicht an einzelne Instanzen einer Klasse (= einzelne Objekte) gebunden. Klassenvariablen werden statisch deklariert, wobei der für die Klassenvariablen reservierte Speicherbereich im EEPROM liegt, also in einem nichtflüchtigen Speicherbereich der Java Card.
Schreibzugriffe auf den EEPROM sind langsam und kosten daher viel Zeit. Aus diesem Grund ist der Zugriff auf Klassenvariablen langsam, weshalb die Performance eines Programms, das Klassenvariablen verwendet, gering ist. Zum Anderen erlaubt ein EEPROM lediglich eine Höchstzahl von typischerweise 100 000 Schreibzyklen, weshalb es wünschenswert ist, Schreib- Zugriffe auf den EEPROM wo möglich zu vermeiden. Die Verwendung von Klassenvariablen, insbesondere in Fällen, wenn nur eine kurze Lebensdauer der Variablen erforderlich ist, verlangsamt somit die Performance des Pro- grammablaufs und belastet durch die dabei erfolgenden Schreibprozesse den EEPROM.
Andererseits besteht der Bedarf, Variablen global, also unabhängig vom Kontext eines speziellen Objekts, Pakets, einer speziellen Methode etc. zu verwenden, beispielsweise für den Austausch von Variablen zwischen unterschiedlichen Kontexten (Objekten, Paketen, Methoden) etc.. Derzeit ist diese Möglichkeit nur durch Klassenvariablen gegeben, die die weiter oben genannten Nachteile haben, wie starke Belastung des EEPROM und Langsam- keit.
Aufgabe der Erfindung ist es daher, einen Smart Card Chip mit einer virtuellen Java-Card-Maschine und einem für globale Variablen reservierten Speicherbereich zur Verfügung zu stellen, der einen einfachen, schnellen und für den Chip schonenden Zugriff auf die globalen Variablen ermöglicht.
Die Aufgabe wird gelöst durch ein Variablen-System nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angeführt.
Der Smart Card Chip gemäß Anspruch 1 hat einen für globale Variablen reservierten Variablen-Speicherbereich, der im flüchtigen Arbeitsspeicher reserviert ist, beispielsweise im RAM. Zugriffe auf den flüchtigen Arbeitsspeicher sind schnell und zudem wird dadurch, dass der flüchtige Arbeitsspei- eher verwendet wird, der nichtflüchtige Anwendungsspeicher, insbesondere EEPROM oder ein Flash-Speicher, geschont. Hierdurch ermöglicht der Chip gemäß Anspruch 1 einfachen, schnellen und für den Chip schonenden Zugriff auf die globalen Variablen.
Daher ist gemäß Anspruch 1 ein Smart Card Chip mit einer virtuellen Java- Card-Maschine und einem für globale Variablen reservierten Speicherbereich geschaffen, der einen einfachen, schnellen und für den Chip schonenden Zugriff auf die globalen Variablen ermöglicht.
Die Erfindung ist insbesondere für Anwendungsfälle für globale Variablen gut geeignet, bei denen die Variablen zwar global sein müssen, z.B. weil sie über Kontextgrenzen hinaus verfügbar sein müssen, bei denen aber eine lange Lebensdauer der Variablen nicht erforderlich ist. Denn der (schnelle) RAM-Speicher, in dem der Speicherbereich für die Variablen reserviert ist, und in dem die Variablen bei Bedarf angelegt werden, ist flüchtig. Folglich werden die angelegten Variablen gelöscht, sobald die Energieversorgung des RAM-Speichers unterbrochen wird.
Vorzugsweise ist der Variablen-Speicherbereich statisch reserviert, beispielsweise dadurch, dass der Variablen-Speicherbereich für Klassenvariab- len reserviert ist (gleichbedeutend: Variablen vom Typ static), da der
Zugriff auf die Variablen bei einer statischen Reservierung besonders schnell ist. Ein Zugriff (Lesezugriff bzw. Schreibzugriff) auf den statisch reservierten Variablen-Speicherbereich bedeutet, dass eine statisch reservierte Variable (Variable vom Typ static) verwendet (gelesen oder überschrieben) wird. Da bei der Verwendung von statisch reservierten Variablen keine Firewall- Prüfung durchgeführt wird, hat die statische Reservierung des Variablen- Speicherbereichs den zusätzlichen Vorteil, dass der Zugriff auf die Variablen schneller ist als wenn der Variablen-Speicherbereich dynamisch, während der Laufzeit des Programms reserviert würde.JPolglich ist es besonders bevorzugt, dass der Variablen-Speicherbereich statisch reserviert ist.
Weiter ist es bevorzugt, dass solche Programme auf den Variablen-Speicherbereich zugreifen können, die auf den Variablen-Speicherbereich linken können. Dabei ist weiter vorzugsweise das Vermögen eines Programms, auf den Variablen-Speicherbereich linken zu können, dadurch erzielt, dass dem Programm zum Linken eine Export-Komponente auf dem Smart Card Chip zur Verfügung steht. Der Variablen-Speicherbereich erscheint für ein Programm, das darauf zugreifen will, wie ein fremdes Programm. Daher benötigt das Programm, das auf den Variablen-Speicherbereich zugreifen will, die Export- Information des fremden Programms, das den Variablen-Speicherbereich geschaffen hat. Vorzugsweise hat also ein Programm, das den reservierten Variablen-Speicherbereich nutzen möchte, zum Linken die Export- Komponente eines fremden Programms zur Verfügung, das den Variablen- Speicherbereich geschaffen hat.
Weiter sind vorzugsweise solche Programme davon ausgeschlossen sind, den Variablen-Speicherbereich zu nutzen, die nicht auf den Variablen- Speicherbereich linken können. Das Unvermögen eines Programms, auf den Variablen-Speicherbereich linken zu können, ist vorzugsweise dadurch erzielt, dass dem Programm zum Linken eine Export-Komponente des Smart Card Chips vorenthalten ist.
Weiter bevorzugt ist der Variablen-Speicherbereich dadurch reserviert, dass in einem Systemspeicher des Chips ein entsprechendes Java Paket abgelegt ist, das vorzugsweise nur die Reservierung des Variablen-Speicherbereichs enthält. Ein solches Java Paket mit dem Namen z.B. „com.gieseckedevrient.javacard.os.commonram", das Speicherplatz für eine Mehrzahl von statischen Variablen „myRamVa- rA", „myRamVarB", etc. vom Datentyp short und Byte und Int reserviert, kann beispielsweise folgende Gestalt haben: p a c k a g e com. gieseckede vrient.j avacar d.os . commonr am; static short myRamVarA; static short myRamVarB; etc.
Das Java Paket wird im Systemspeicher (ROM, ggf. auch Flash-Speicher) abgespeichert. Bei der späteren Verwendung des Java Pakets werden die ent- sprechenden Daten, d.h. die statischen, globalen Variablen vom Typ short, Byte, Int im RAM abgelegt.
Weiter ist es bevorzugt, dass auf den Variablen-Speicherbereich nur im Systemspeicher (ROM, Flash) abgespeicherte Programme zugreifen können. Alternativ oder zusätzlich können vorzugsweise auf den Variablen- Speicherbereich nur Programme zugreifen, die bis zum Abschluss der Komplettierung des Smart Card Chips in dem Smart Card Chip implementiert worden sind.
Gemäß einer bevorzugten Ausführungsform wird nur für Pakete, die bis zur Komplettierung implementiert werden, zum Linken die Export-Komponente zur Verfügung gestellt. Ein geladenes Paket, das bis zur Komplettierung implementiert wird, wird vorzugsweise mit dem Off card-Linker und der Export-Datei gelinkt. Dadurch wird die Linkinformation zum Linken auf den Variablen-Speicherbereich aus der Export-Komponente des Java Pakets, das den Variablen-Speicherbereich reserviert, in die Import-Komponente des geladenen Pakets geladen. Die Folge ist, dass das geladene Paket auf den reservierten Variablen-Speicherbereich zugreifen kann und dort, im RAM, die RAM-Variablen benutzen kann. Pakete, die nach der Komplettierung in die Java Card bzw. den Chip implementiert werden, haben in ihren Import- Komponenten nicht die Linkinformation aus der Export-Komponente des Java Pakets, das den Variablen-Speicherbereich reserviert hat. Daher können gemäß der bevorzugten Ausführungsform nach der Komplettierung implementierte Pakete die erfindungsgemäßen RAM-Variablen nicht benutzen, d.h. nicht auf den reservierten Variablen-Speicherbereich im RAM zugreifen.
Die virtuelle Java-Card-Maschine ist vorzugsweise derart gestaltet, und dabei bei Bedarf gegenüber der virtuellen Java-Card-Maschine gemäß der Java Card VM Spezifikation modifiziert, dass sie auf Grundlage des im flüchtigen Arbeitsspeicher (RAM) reservierten Variablen-Speicherbereichs die Verwendung von globalen Variablen im RAM ermöglicht.
Insbesondere sind bei Bedarf die Befehle „getstatic" und „putstatic" der virtuellen Java-Card-Maschine gegenüber den Befehlen „getstatic" und „putstatic" virtuellen Java-Card-Maschine gemäß der Java Card VM Spezifikation modifiziert.
Vorzugsweise sind die bei Bedarf vorgenommenen Modifizierungen oder Änderungen an der virtuellen Java-Card-Maschine derart vorgenommen, dass die Modifizierungen / Änderungen bei der Verwendung der VM nach außen nicht qualitativ erkennbar sind. Dass die Modifizierungen qualitativ nicht erkennbar sind, bedeutet insbesondere, dass der Smart Card Chip einer vorbestimmten Java Card Spezifikation genügt, der der Chip ohne die Modi- fikationen ebenfalls genügen würde. Quantitativ können die Modifizierungen optional nach außen erkennbar sein, z.B. kann nach außen erkennbar sein, dass das Verwenden der erfindungsgemäßen globalen RAM-Variablen schneller ist als das Verwenden von bekannten globalen Variablen aus dem Stand der Technik. Insbesondere sind die bei Bedarf an den Befehlen „getstatic" und „putstatic" vorgenommenen Änderungen vorzugsweise derart durchgeführt, dass das Verwenden (z.B. Anlegen, Variablenwert ändern) von static Variablen unter Verwendung der Befehle „getstatic" und „putstatic" unverändert ist gegenüber dem Verwenden (z.B. Anlegen, Variablenwert ändern) von static Variablen gemäß der Java Card VM Spezifi- kation.
Dass die Änderungen nach außen nicht qualitativ erkennbar sind, wird beispielsweise dadurch erreicht, dass ein Variablen-Speicherbereich für globale Variablen im RAM reserviert wird, wobei für die Reservierung eine ansons- ten der Java Card VM Spezifikation genügende Variablen-Deklaration verwendet wird, beispielsweise eine Deklaration von static Variablen, nur mit dem Unterschied, dass die static area im RAM statt im EEPROM vorgesehen ist.
Die Einhaltung der Spezifikationen wird vorzugsweise ferner dahingehend gewährleistet, dass ein normaler Benutzer den reservierten Variablen- Speicherbereich nicht benutzen kann, d.h. keine erfindungsgemäßen RAM- Variablen benutzen kann, da ihm die Linkinformation fehlt, weil ihm die zum Linken erforderliche Export-Datei vorenthalten ist. Beispielsweise wird die Export-Datei beim Hersteller der Smart Card verwahrt und gegenüber ' Benutzern wie Abnehmern von Smart Cards geheim gehalten. Vorzugsweise können nur Programmentwickler von Systemprogrammen (und wahlweise zusätzlich von preloaded packages), die vor der Komplettierung gelinkt werden, die erfindungsgemäßen RAM- Variablen verwenden, da nur diesen Programmentwicklern von Systemprogrammen (und ggf. preloaded packages) die geheime Export-Datei und somit die zum Linken auf den reservier- ten Variablen-Speicherbereich erforderliche Linkinformation zur Verfügung steht. Nur Programmentwickler von Systemprogrammen (und ggf. preloaded packages) sind also von der allgemeinen Geheimhaltung der Export- Datei ausgenommen. Abnehmer von Smart Cards, die nach der Komplettierung der Smart Card Programme (z.B. Anwendungen) in die Smart Card (bzw. in den Smart Card Chip) laden, können zum Linken hingegen nur den Oncard-Linker verwenden, der die Linkinformation zum Linken auf den reservierten Variablen-Speicherbereich im RAM nicht hat.
Im folgenden wird die Erfindung anhand von Ausführungsbeispielen und unter Bezugnahme auf die einzige Figur 1 der Zeichnung näher erläutert.
Fig. 1 zeigt eine schematische Darstellung einer Java Card mit einem darin implementierten RAM package 5 , durch das ein Variablen- Speicherbereich 18 im RAM der Java Card statisch reserviert ist, ge- maß einer bevorzugten Ausführungsform der Erfindung. Die Java Card aus Fig. 1 hat einen nichtflüchtigen Systemspeicher 1, nämlich den ROM 1, einen nichtflüchtigen Anwendungsspeicher 2, nämlich den EEPROM 2, und einen flüchtigen Arbeitsspeicher 3, nämlich den RAM 3. •
Im ROM 1 sind die virtuelle Java-Card-Maschine VM 4 und weiterer nativer Code implementiert. Zudem sind im ROM 1 eine Reihe von Paketen Pckgl, Pckg2, ... Pckgn mit unterschiedlichen Inhalten, zum Teil Systemfunktionen und zum Teil Anwendungen, implementiert. Außerdem ist im ROM 1 das erfindungsgemäße RAM package 5 implementiert, also das Java Paket, durch welches der Variablen-Speicherbereich 18 im RAM reserviert ist. Im EEPROM 2 sind mehrere vor der Komplettierung in die Java Card geladene Pakete mit Anwendungen, nämlich mehrere preloaded EEPROM packages 16, abgespeichert. Zudem enthält der EEPROM 2 einen heap-Speicher 19 mit dynamischen Daten (Dynamic Data), mehrere Pufferspeicher (Buffers) und einen Bereich mit nativen Daten. Der RAM 3 enthält native RAM-Daten, den durch das RAM package reservierten Variablen-Speicherbereich 18 (RamP.- Data), zwei Pufferspeicher (Buffer), einen Arbeitsspeicherbereich, der auf Anfrage gelöscht wird (COD, Clear On Demand) und einen Arbeitsspeicherbereich, der bei Reset, also bei Rücksetzen, gelöscht wird (COR, Clear On Reset).
Die virtuelle Maschine VM 4 in Fig. 1 enthält beispielsweise die Befehle der VM 4 wie z.B. „putstatic" 7, mit dem sich eine static Variable zur Laufzeit ändern lässt, wie durch den vergrößerten Ausschnitt 7 der VM mit der Be- schriftung „Putstatic" angedeutet ist. Im beschriebenen Beispiel von Fig. 1 gibt es weiter eine in der Java Card implementierte Zugriffstabelle (SAT, segment allocation table), die u.a. die Anfangsadressen der in der Java Card implementierten Pakete (packages) " enthält.
Die Zugriffstabelle SAT enthält insbesondere für das RAM package einen static area descriptor 8, d.h. einen in dem RAM package 5 enthaltenen Deskriptor 8 (oder eine Angabe), der einen Anfang und eine Größe eines bestimmten Adressbereichs als Speicherbereich für statisch deklarierte (reser- vierte) Variablen angibt. Der Deskriptor 8 (static area descriptor) enthält zwei Teilangaben, nämlich die Anfangsadresse des Adressbereichs und die Größe des Adressbereichs. Die Anfangsadresse ist so gewählt, dass der durch den static area descriptor 8 bestimmte Adressbereich im RAM 3 der Java Card liegt, wie durch die Pfeile 12, 13 angedeutet ist, die vom Deskrip- tor 8 (static area descriptor) zum RAM 3 verlaufen. Durch die derart getroffene Auswahl der Anfangsadresse (d.h. Auswahl der Anfangsadresse so, dass der reservierte Variablen-Speicherbereich im RAM liegt) ist eine direkt auf den RAM-Speicher gerichtete Zugriffsinformation gebildet. Dass der Deskriptor 8 (static area descriptor) auf eine Adressangabe im RAM verweist, stellt eine Änderung gegenüber der Java Card VM Spezifikation dar, die jedoch nach außen nicht erkennbar ist.
Das in Fig. 1 dargestellte Paket 6 mit der Nummer „n", bezeichnet mit „Pckgn", ist ein preloaded package, d.h. ein Paket, das vor der Komplettie- rung der Java Card in der Java Card implementiert worden ist, und enthält im ROM-Speicher 1 der Java Card abgelegten Paket-Code 9, wie durch den vergrößerten Ausschnitt 9 „Preloaded Pack. Code" angedeutet ist. Der Pa- ket-Code 9 des preloaded package 6 wiederum enthält Code für einen Konstantenpool 10 („Const. Pool") und Code 11 für den Befehl „putstatic" der VM. Durch „putstatic" 11 im Code des preloaded package 6 (Pckgn) wird unter Verwendung des Konstantenpools 10 eine Variable vom Typ static adressiert, und zwar im RAM 3, im reservierten Variablen-Speicherbereich 18, wie durch die Pfeile 14, 15 angedeutet ist, die von „Code putstatic" zu „Const. Pool ..." (Pfeil 14) und von „Const. Pool ..." zu „RamP. Data" (Pfeil 15) verlaufen. Das preloaded package Paket Pckgn 6 wurde durch den Offcard-Linker und unter Verwendung der Export-Datei der Java Card gelinkt. Dabei wurde das preloaded package Paket Pckgn 6 mit Linkinformation des RAM package 5 ausgestattet, insbesondere mit der Adresse, die im Deskriptor 8 für static Variablen (static area descriptor) steht. Hierdurch hat das preloaded package Pckgn 6 die Linkinformation des RAM package 5. Folglich kann das preloaded package Pckgn 6 den reservierten Variablen- Speicherbereich 18 des RAM package 5 benutzen, also erfindungsgemäße globalen Variablen (RAM static Variablen) benutzen.
Bei dem Beispiel aus Fig. 1 kann ein postloaded package 16, das im EEPROM implementiert ist, nicht auf den im RAM 3 reservierten Variablen- Speicherbereich 18 zugreifen, so dass das postloaded package 16 im
EEPROM keine erfindungsgemäßen globalen Variablen im RAM benutzen kann. Nur Pakete im Systemspeicher ROM können die globalen Variablen im RAM benutzen.
Gemäß alternativen Ausführungsformen können auch preloaded packages im EEPROM die globalen Variablen im RAM benutzen. Die preloaded packages im ROM haben dann, wie die packages im Systemspeicher ROM auch, die vom Offcard-Linker in der Export-Datei bereitgestellte Adressinformation, mit der sie auf den reservierten Variablen-Speicherbereich linken können, so dass sie den reservierten Variablen-Speicherbereich im RAM für Variablen benutzen können.

Claims

P a t e n t a n s p r ü c h e
1. Smart Card Chip mit einem nichtflüchtigen Systemspeicher (ROM, Flashl), einer in dem nichtflüchtigen Systemspeicher (ROM, Flashl) imple- mentierten virtuellen Java-Card-Maschine, einem nichtflüchtigen Anwen- ' dungsspeicher (EEPROM, Flash2), einem flüchtigen Arbeitsspeicher (RAM) und einem für globale Variablen reservierten Variablen-Speicherbereich, wobei der Variablen-Speicherbereich im flüchtigen Arbeitsspeicher (RAM) reserviert ist.
2. Smart Card Chip nach Anspruch 1, wobei auf den Variablen- Speicherbereich nur im Systemspeicher (ROM, Flash) abgespeicherte Programme zugreifen können.
3. Smart Card Chip nach Anspruch 1 oder 2, wobei auf den Variablen- Speicherbereich nur Programme zugreifen können, die bis zum Abschluss der Komplettierung des Smart Card Chips in dem Smart Card Chip implementiert worden sind.
4. Smart Card Chip nach einem der Ansprüche 1 bis 3, wobei der Variablen-Speicherbereich statisch reserviert ist.
5. Smart Card Chip nach einem der Ansprüche 1 bis 4, wobei der Variablen-Speicherbereich durch eine direkt auf den Arbeitsspeicher (RAM) ge- richtete Zugriffsinformation reserviert ist.
6. Smart Card nach einem der Ansprüche 1 bis 5, wobei solche Programme auf den Variablen-Speicherbereich zugreifen können, die auf den Variablen-Speicherbereich linken können.
7. Smart Card Chip nach Anspruch 6, wobei das Vermögen eines Programms, auf den Variablen-Speicherbereich linken zu können, dadurch erzielt ist, dass dem Programm zum Linken eine Export-Komponente auf dem Smart Card Chip zur Verfügung steht.
8. Smart Card Chip nach einem der Ansprüche 1 bis 7, wobei solche Programme davon ausgeschlossen sind, den Variablen-Speicherbereich zu nutzen, die nicht auf den Variablen-Speicherbereich linken können.
9. Smart Card Chip nach Anspruch 8, wobei das Unvermögen eines Programms, auf den Variablen-Speicherbereich linken zu können, dadurch erzielt ist, dass dem Programm zum Linken eine Export-Komponente des Smart Card Chips vorenthalten ist.
10. Smart Card Chip nach einem der Ansprüche 1 bis 9, wobei der Variablen-Speicherbereich durch ein in dem Smart Card Chip implementiertes Java Paket (RAM package) reserviert ist.
11. Smart Card Chip nach Anspruch 10, wobei das Java Paket (RAM package) im Systemspeicher (ROM, Flashl) implementiert ist.
12. Smart Card Chip nach Anspruch 10 oder 11, wobei das Java Paket ausschließlich die Reservierung des Variablen-Speicherbereichs enthält.
13. Smart Card Chip nach einem der Ansprüche 10 bis 12, wobei eine Export-Komponente des Java Pakets (RAM package), in der die zum Linken auf den reservierten Variablen-Speicherbereich erforderliche Linkinformation enthalten ist, nicht in dem Smart Card Chip implementiert ist.
14. Smart Card Chip nach einem der Ansprüche 1 bis 13, wobei die virtu- eile Java-Card-Maschine derart gestaltet ist, und dabei bei Bedarf modifiziert ist, dass sie auf Grundlage des im flüchtigen Arbeitsspeicher (RAM) reservierten Variablen-Speicherbereichs die Verwendung von globalen Variablen im RAM ermöglicht.
15. Smart Card Chip nach Anspruch 14, wobei die virtuelle Java-Card- Maschine derart modifiziert ist, dass die Modifizierungen nach außen hin nicht qualitativ erkennbar sind, insbesondere dass der Smart Card Chip einer vorbestimmten Java Card Spezifikation genügt, welcher der Chip ohne die Modifikationen ebenfalls genügen würde.
16. Chipmodul mit einem Smart Card Chip gemäß einem der Ansprüche 1 bis 15.
17. Datenträger, insbesondere Java Card, mit einem Smart Card Chip ge- maß einem der Ansprüche 1 bis 15 und/oder einem Chipmodul gemäß Anspruch 16.
18. Verfahren zum Reservieren eines Variablen-Speicherbereichs in einem Smart Card Chip, der aufweist: eine nichtflüchtigen Systemspeicher (ROM, Flashl), eine in dem nichtflüchtigen Systemspeicher (ROM, Flashl) implementierte virtuelle Java-Card-Maschine, einen nichtflüchtigen Anwendungsspeicher (EEPROM, Flash2) und einen flüchtigen Arbeitsspeicher (RAM), wobei bei dem Verfahren ein Java Programmcode in dem Smart Card Chip implementiert wird, durch den ein Variablen-Speicherbereich für globale Variablen im flüchtigen Arbeitsspeicher (RAM) reserviert wird.
19. Verfahren nach Anspruch 18, wobei als Java Programmcode eine Java Paket (RAM package) implementiert wird.
20. Verfahren nach Anspruch 19, wobei eine Export-Komponente des Java Pakets, in der die zum Linken auf den Variablen-Speicherbereich erfor- derliche Linkinformation enthalten ist, nicht in dem Smart Card Chip implementiert wird.
21. Verfahren nach einem der Ansprüche 18 bis 20, wobei eine zum Linken auf den reservierten Variablen-Speicherbereich erforderliche Export- Datei nur solchen Programmen zum Linken zur Verfügung gestellt wird, die auf den Variablen-Speicherbereich zugreifen können sollen.
PCT/EP2004/013797 2003-12-08 2004-12-03 Java smart card chip mit für globale variablen reserviertem speicherbereich WO2005055052A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/582,118 US7702872B2 (en) 2003-12-08 2004-12-03 Java smart card chip having memory area reserved for global variables
EP04803515A EP1695207A2 (de) 2003-12-08 2004-12-03 Java smart card chip mit für globale variablen reserviertem speicherbereich

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10357257.0 2003-12-08
DE10357257A DE10357257A1 (de) 2003-12-08 2003-12-08 Java Smart Card Chip mit für globale Variablen reserviertem Speicherbereich

Publications (2)

Publication Number Publication Date
WO2005055052A2 true WO2005055052A2 (de) 2005-06-16
WO2005055052A3 WO2005055052A3 (de) 2006-05-26

Family

ID=34625639

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/013797 WO2005055052A2 (de) 2003-12-08 2004-12-03 Java smart card chip mit für globale variablen reserviertem speicherbereich

Country Status (4)

Country Link
US (1) US7702872B2 (de)
EP (1) EP1695207A2 (de)
DE (1) DE10357257A1 (de)
WO (1) WO2005055052A2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2273373A1 (de) * 2009-07-02 2011-01-12 Vodafone Holding GmbH Speichern von häufig geänderten Daten auf einer IC-Karte
US20110117944A1 (en) * 2009-11-17 2011-05-19 Yaxin Cao Method and system for task-level access arbitration between virtual modems in a multi-sim multi-standby communication device
CN102591787B (zh) * 2011-12-19 2015-09-02 北京握奇数据系统有限公司 Java卡的数据处理方法及装置
US8930893B2 (en) * 2012-06-28 2015-01-06 International Business Machines Corporation Initialization safety
US11030105B2 (en) 2014-07-14 2021-06-08 Oracle International Corporation Variable handles
CN105824651B (zh) * 2015-01-06 2019-01-01 中国移动通信集团公司 一种智能卡内应用安装方法及装置
CN105426237B (zh) * 2015-11-13 2018-11-06 武汉天喻信息产业股份有限公司 一种动态管理JavaCard暂态资源的方法及系统
CN107451498B (zh) * 2016-06-01 2020-06-09 北京数码视讯科技股份有限公司 一种对象间关联关系的提供方法、装置及智能卡
EP3291158A1 (de) * 2016-09-02 2018-03-07 Gemalto Sa Laden eines java-kartenspeichers mit einem java-kartenpaket durch einen kartenpersonalisierungsspezifikationsfluss
US10585647B2 (en) * 2017-05-02 2020-03-10 International Business Machines Corporation Program optimization by converting code portions to directly reference internal data representations
DE102022001682A1 (de) 2022-05-12 2023-11-16 Giesecke+Devrient ePayments GmbH Secure Element mit Heap-Speicher

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5581768A (en) * 1995-02-27 1996-12-03 Intel Corporation Method and apparatus for executing applications in place from write once/seldom memories
WO1998019237A1 (en) * 1996-10-25 1998-05-07 Schlumberger Systemes Using a high level programming language with a microcontroller
US20020093856A1 (en) * 2000-11-06 2002-07-18 International Business Machines Corporation File language verification
WO2003104974A2 (en) * 2002-06-07 2003-12-18 Sun Microsystems, Inc. Using short references to access program elements in a large address space

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU746459B2 (en) * 1997-03-24 2002-05-02 Visa International Service Association A system and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6880155B2 (en) * 1999-02-02 2005-04-12 Sun Microsystems, Inc. Token-based linking
FR2827974B1 (fr) * 2001-07-26 2005-02-11 Trusted Logic Procede pour la compression d'un code interprete par analyse semantique
US6588674B2 (en) * 2001-07-27 2003-07-08 Motorola, Inc. Memory management method and smartcard employing same
US7131121B2 (en) * 2001-11-14 2006-10-31 Axalto, Inc. Method and apparatus for linking converted applet files without relocation annotations
DE10202032A1 (de) * 2002-01-18 2003-07-31 Giesecke & Devrient Gmbh Laden und Interpretieren von Daten
JP3913128B2 (ja) * 2002-02-28 2007-05-09 松下電器産業株式会社 メモリカード
WO2004066672A1 (en) 2003-01-22 2004-08-05 Shelley Katz Apparatus and method for producing sound
US7484095B2 (en) * 2003-01-16 2009-01-27 Sun Microsystems, Inc. System for communicating program data between a first device and a second device
US7281244B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Using a digital fingerprint to commit loaded data in a device
US7281237B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Run-time verification of annotated software code
US7222331B2 (en) * 2003-01-16 2007-05-22 Sun Microsystems, Inc. Linking of virtual methods
US7165246B2 (en) * 2003-01-16 2007-01-16 Sun Microsystems, Inc. Optimized representation of data type information in program verification
US7114646B2 (en) * 2003-02-25 2006-10-03 Hillhouse Robert D Method and apparatus for biometric verification with data packet transmission prioritization
FR2864658B1 (fr) * 2003-12-30 2006-02-24 Trusted Logic Controle d'acces aux donnees par verification dynamique des references licites
JP4295129B2 (ja) * 2004-02-20 2009-07-15 富士通株式会社 記録媒体ライブラリ装置
US7478367B2 (en) * 2005-01-11 2009-01-13 International Business Machines Corporation Dynamic source code analyzer

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5581768A (en) * 1995-02-27 1996-12-03 Intel Corporation Method and apparatus for executing applications in place from write once/seldom memories
WO1998019237A1 (en) * 1996-10-25 1998-05-07 Schlumberger Systemes Using a high level programming language with a microcontroller
US20020093856A1 (en) * 2000-11-06 2002-07-18 International Business Machines Corporation File language verification
WO2003104974A2 (en) * 2002-06-07 2003-12-18 Sun Microsystems, Inc. Using short references to access program elements in a large address space

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Runtime Environment Specification, Java Card Platform, Version 2.2.1" INTERNET ARTICLE, [Online] Oktober 2003 (2003-10), XP002371505 Gefunden im Internet: URL:http://java.sun.com/products/javacard/specs.html> [gefunden am 2006-03-10] *
SHAYLOR N ET AL: "A java virtual machine architecture for very small devices" PROCEEDINGS OF ACM SIGPLAN. WORKSHOP ON LANGUAGES, COMPILERS AND TOOLS FOR EMBEDDED SYSTEMS, XX, XX, 11. Juni 2003 (2003-06-11), Seiten 1-8, XP002338016 *

Also Published As

Publication number Publication date
DE10357257A1 (de) 2005-06-30
US7702872B2 (en) 2010-04-20
EP1695207A2 (de) 2006-08-30
US20070168951A1 (en) 2007-07-19
WO2005055052A3 (de) 2006-05-26

Similar Documents

Publication Publication Date Title
DE60002295T2 (de) Aufwandslose ausnahmebehandlung
DE60108181T2 (de) Änderbarkeitsanalyse in java
DE60031370T2 (de) Tokenbasierte verknüpfung
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE19536548A1 (de) Vorrichtung und Verfahren zur vereinfachten Erzeugung von Werkzeugen zur Initialisierung und Personalisierung von und zur Kommunikation mit einer Chipkarte
DE69534867T2 (de) Verfahren und System zur Lieferung geschützter Gerätetreiber
WO2010009789A1 (de) Laden und aktualisieren einer personalisierungsbedürftigen applikation
WO2005055052A2 (de) Java smart card chip mit für globale variablen reserviertem speicherbereich
DE102004057490B4 (de) Vorrichtung und Verfahren zum Verarbeiten eines Programmcodes
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
DE60318993T2 (de) Eingebettete Speicherbereinigung
EP1709534B1 (de) Ausführung eines programms durch eine virtuelle maschine
DE10320062A1 (de) Speicherverwaltung bei einem tragbaren Datenträger
DE102007041873A1 (de) Installieren eines Patch in einem Smartcard-Modul
DE102004005676A1 (de) Datenträger mit plattformunabhängigem Anwendungs-Programmcode
EP1062630B1 (de) Datenträger
DE102004022907A1 (de) Datenträger mit Speicherverwaltung
DE102005032542A1 (de) Verwaltung von Applikationen in einem tragbaren Datenträger
EP1530131B1 (de) Beschleunigtes Referenzfinden für eine automatische Speicherbereinigung (Garbage Collection)
EP0992027A2 (de) Chipkarte zur ausführung von nicht änderbaren system-programmroutinen und diesen zugeordneten ersatz-programmroutinen, sowie verfahren zum betrieb der chipkarte
DE102004054068A1 (de) Verfahren zum Abfragen der Systemkonfiguration eines Datenträgers
DE10145783A1 (de) Erzeugen einer Nachricht zur Fehlersuche bei einem tragbaren Datenträger
EP1600855B1 (de) Erzeugen und Verwenden von Speicherbelegungsinformationen bei einem tragbaren Datenträger
EP0794519A1 (de) Chipkarte
DE102004051823A1 (de) Übergabe von Variablen zwischen Interpreter-basierten und nativen Programmcodeteilen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2004803515

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2004803515

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007168951

Country of ref document: US

Ref document number: 10582118

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10582118

Country of ref document: US