EP1695207A2 - Puce de carte intelligente java comportant une zone de mémoire reservée à des variables globales - Google Patents

Puce de carte intelligente java comportant une zone de mémoire reservée à des variables globales

Info

Publication number
EP1695207A2
EP1695207A2 EP04803515A EP04803515A EP1695207A2 EP 1695207 A2 EP1695207 A2 EP 1695207A2 EP 04803515 A EP04803515 A EP 04803515A EP 04803515 A EP04803515 A EP 04803515A EP 1695207 A2 EP1695207 A2 EP 1695207A2
Authority
EP
European Patent Office
Prior art keywords
smart card
memory area
card chip
java
variable memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04803515A
Other languages
German (de)
English (en)
Inventor
Siegfried Vollmann
Manouchehr Hosseini
Monika Uminska-Ziesche
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and 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 and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP1695207A2 publication Critical patent/EP1695207A2/fr
Withdrawn legal-status Critical Current

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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne une puce de carte intelligente comportant une mémoire système non-volatile (ROM, Flash1), une machine à carte Java virtuelle implémentée dans la mémoire système non-volatile (ROM, Flash1), une mémoire d'application non-volatile (EEPROM, Flash2), une mémoire de travail volatile (RAM) et une zone de mémoire de variables réservée à des variables globales, la zone de mémoire de variables étant réservée dans la mémoire de travail volatile (RAM). La zone de mémoire de variables est de préférence réservée de façon statique. L'utilisation des variables peut être limitée à des progiciels système, notamment à des progiciels préchargés (ROM/EEPROM).
EP04803515A 2003-12-08 2004-12-03 Puce de carte intelligente java comportant une zone de mémoire reservée à des variables globales Withdrawn EP1695207A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10357257A DE10357257A1 (de) 2003-12-08 2003-12-08 Java Smart Card Chip mit für globale Variablen reserviertem Speicherbereich
PCT/EP2004/013797 WO2005055052A2 (fr) 2003-12-08 2004-12-03 Puce de carte intelligente java comportant une zone de memoire reservee a des variables globales

Publications (1)

Publication Number Publication Date
EP1695207A2 true EP1695207A2 (fr) 2006-08-30

Family

ID=34625639

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04803515A Withdrawn EP1695207A2 (fr) 2003-12-08 2004-12-03 Puce de carte intelligente java comportant une zone de mémoire reservée à des variables globales

Country Status (4)

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

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2273373A1 (fr) * 2009-07-02 2011-01-12 Vodafone Holding GmbH Stockage de données modifiées fréquemment dans une carte CI
US8874167B2 (en) * 2009-11-17 2014-10-28 Broadcom Corporation Method and system for multi-standby operation for 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 (fr) * 2016-09-02 2018-03-07 Gemalto Sa Chargement d'une mémoire java card avec un package java card par un flux de spécification de personnalisation de carte
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
CN117785248B (zh) * 2024-02-28 2024-05-24 上海励驰半导体有限公司 程序升级中关键变量的注册方法、装置、存储介质及芯片

Family Cites Families (21)

* 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
ES2184066T3 (es) * 1996-10-25 2003-04-01 Schlumberger Systems & Service Uso de un lenguaje de programacion de alto nivel con microcontrolador.
CA2288824A1 (fr) * 1997-03-24 1998-10-01 Marc B. Kekicheff Procede et dispositif de carte a puce multi-application permettant de telecharger une application sur la carte posterieurement a son emission
US6880155B2 (en) * 1999-02-02 2005-04-12 Sun Microsystems, Inc. Token-based linking
US7506175B2 (en) 2000-11-06 2009-03-17 International Business Machines Corporation File language verification
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 松下電器産業株式会社 メモリカード
WO2003104974A2 (fr) 2002-06-07 2003-12-18 Sun Microsystems, Inc. Utilisation de references courtes pour acceder a des elements de programme dans un grand espace d'adresse
US7281244B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Using a digital fingerprint to commit loaded data in a device
US7484095B2 (en) * 2003-01-16 2009-01-27 Sun Microsystems, Inc. System for communicating program data between a first device and a second device
US7165246B2 (en) * 2003-01-16 2007-01-16 Sun Microsystems, Inc. Optimized representation of data type information in program verification
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
CA2553744A1 (fr) 2003-01-22 2004-08-05 Shelley Katz Appareil et procede de production de son
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005055052A2 *

Also Published As

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

Similar Documents

Publication Publication Date Title
DE69714752T2 (de) Verwendung einer hohen programmiersprache in einem mikrokontroller
DE60002295T2 (de) Aufwandslose ausnahmebehandlung
DE69835879T2 (de) Multifunktionschipkarte mit delegierungsmerkmal
DE60108181T2 (de) Änderbarkeitsanalyse in java
DE69230578T2 (de) Sprachenneutrale Objekte
DE60031370T2 (de) Tokenbasierte verknüpfung
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE69123775T2 (de) Programmsteuersystem für eine tragbare Datenspeichervorrichtung
DE19536548A1 (de) Vorrichtung und Verfahren zur vereinfachten Erzeugung von Werkzeugen zur Initialisierung und Personalisierung von und zur Kommunikation mit einer Chipkarte
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE69316576T2 (de) IC Karte mit alterunggeschützten Daten und Programmen
EP1695207A2 (fr) Puce de carte intelligente java comportant une zone de mémoire reservée à des variables globales
WO2010009789A1 (fr) Chargement et actualisation d’une application nécessitant une personnalisation
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 (fr) Execution d'un programme par une machine virtuelle
DE10320062A1 (de) Speicherverwaltung bei einem tragbaren Datenträger
DE102007041873A1 (de) Installieren eines Patch in einem Smartcard-Modul
DE102005056357A1 (de) Multithreading-fähige virtuelle Maschine
DE102004005676A1 (de) Datenträger mit plattformunabhängigem Anwendungs-Programmcode
DE102004022907A1 (de) Datenträger mit Speicherverwaltung
EP1062630B1 (fr) Support de donnees
EP1530131B1 (fr) Détermination accélérée de références pour un ramasse-miettes
WO1998059325A2 (fr) Carte a puce permettant d'executer des routines de programme systeme non modifiables, routines de programme de remplacement affectees a ces dernieres et mode de fonctionnement de la carte a puce

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR LV MK YU

RIN1 Information on inventor provided before grant (corrected)

Inventor name: UMINSKA-ZIESCHE, MONIKA

Inventor name: HOSSEINI, MANOUCHEHR

Inventor name: VOLLMANN, SIEGFRIED

17P Request for examination filed

Effective date: 20061127

RBV Designated contracting states (corrected)

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20070112

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20090313