MXPA99003796A - Using a high level programming language with a microcontroller - Google Patents

Abstract

An integrated circuit card is used with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high level programming language format. A processor of the card is configured to use the interpreter to interpret the application for execution and to use a communicator of the card to communicate with the terminal.

Description

USE OF A HIGH-LEVEL PROGRAMMING LANGUAGE WITH A MICROCONTROLLER Part of the presentation of this patent document contains material protected by copyright. The owner of the copyright has no objection to the reproduction of part of the patent document or patent presentation, as it appears in the patent records files of the Patent and Trademark Office, but it is reserved for other side all the author rights. According to article 119 (e) of 35 USC, this application claims the benefit of the previous North American provisional application serial number 60 / 029,057, filed on October 25, 1996. BACKGROUND OF THE INVENTION This invention relates generally to the field of programming, and more particularly to the use of a high-level programming language with a smart card or a microcontroller. Programmatic applications written in the language of "high-level Java programming have been designed in such a way that an application written in Java can be used in several different brands of computers or in different computer platforms without changes. This is achieved by the following procedure. When a Java application is written, it is compiled into "class" files that contain byte codes that are instructions for a hypothetical computer called a Java Virtual Machine. An implementation of this virtual machine is written for each supported platform. When a user wishes to use a particular Java application on a selected platform, the class files compiled from the desired application are loaded into the selected platform. The Java Virtual Machine for the selected platform is used, and interprets the byte codes in the class file, effectively activating the Java application. Java is described in the following references that are incorporated herein by reference: (1) Arnold, Ken, James Gosling, "The Java Program Language" Addison-Wesley, 1996; (2) James Gosling, Bill Joy, and Miscrosystems, 1996, (Web site: http://Java.sun.com/doc/language_specification); (3) James Gosling and Henry McGilton, "The Java Language Environment: A White Paper," Sun Microsystems, 1995 (Web site: http://Java.sun.com/doc/language_environment/); and (4) Tim Lindholm and Frank Yellin, "The Java Vortial Machine Specification," Addison-Wesley, 1997. These texts, among many others, describe how to program using Java. In order to use a Java application on a specific platform, you must write a Java virtual machine implementation that will work within the limits of the platform, and a mechanism must be offered to load the desired Java application on the platform , remaining again within the limits of this platform. Conventional platforms that support Java are typically microprocessor-based computers, with access to relatively large amounts of memory and hard disk storage space. Such microprocessor implementations are frequently used in desktop computers and personal computers. However, there is no conventional Java implementation in microcontrollers, as could typically be used in a smart card. Microcontrollers differ from microprocessors in many ways. For example, a microprocessor typically has a central processing unit that requires certain external components (e.g., memory, input control and output controls) to function properly. A typical microprocessor can gain access from a memory of megabyte order to a memory of the order of gigabyte, and can process 16, 32 or 64 bits of information or more with a simple instruction. In contrast to the microprocessor, a microcontroller includes a central processing unit, memory and other functional elements, all in a single semi conductor substrate, or integrated circuit (for example, a "lasca"). Compared with a relatively large external memory which is accessed through the microprocessor, the typical microcontroller has access to much smaller memory. A typical microcontroller can have access to an integrated memory of 1 to 64 kilobytes, and in general 16 kilobytes. There are generally 3 different types of memory: random access memory (RAM), read-only memory (ROM), and electrically erasable programmable read-only memory (EEPROM). In a microcontroller, the amount of each type of available memory is limited by the amount of integrated circuit space used for each type of memory. Typically, RAM takes up most of the space, and is the most limited. The ROM takes the smaller space, and is more abundant. EEPROM is more abundant than RAM but less abundant than ROM. Each type of memory is suitable for different purposes. Even though ROM is the least expensive, it is only suitable for data that does not change, such as operating system code. EEPROM is useful for storing data that should be preserved when the power supply is suspended, but it is extremely slow to write. RAM can be written and read at high speed, but it is an expensive memory and the data in the RAM memory is lost when the power supply is turned off. A microprocessor system typically has little ROM memory and little EEPROM memory, and has 1 to 128 megabytes of RAM, since it is not limited by what can fit into a single integrated circuit device, and often has access to a external disk memory system that serves as a large non-volatile storage area, where you can write, at a lower cost than EEPROM. However, a microcontroller typically has a small RAM of 0.1 to 2.0 K, 2K to 8K of EEPROM, and 8K to 56K of ROM. Due to the small number of external components required and their small size, microcontrollers are frequently used in integrated circuit cards, such as smart cards. Such smart cards are provided in various forms, including cards lowered in contact, which must be inserted into a reader for use, and contactless cards, which do not require insertion. In fact, microcontrollers with contactless communication are often integrated into specialized forms, such as watches and rings, effectively integrating the functionality of a smart card in an ergonomically attractive manner. Due to the limited environment, smart card applications are typically written in a low-level programming language (for example, assembly language) to conserve memory. The integrated circuit card is a secure, robust, tamper-proof and portable device for storing data. The integrated circuit card is the most personal of the personal computers due to its small size and due to the data security features of programmatic and equipment unique to the integrated circuit card. The primary task of the integrated circuit card and the microcontroller in the card is to protect the data stored on the card. Therefore, since its invention in 1974, the technology of integrated circuit cards has been closely protected for these same security reasons. The cards were used for the first time in French banks as debit cards. In this application, before authorizing a card-based financial transaction, the user of the card must demonstrate that he or she is aware of a four-digit personal identification number (PIN) stored on the card in addition to having said card. Any information that could contribute to the discovery of the PIN number on a stolen or lost card could not be disclosed. In factSince no one could say what information would be useful in this regard, virtually all information regarding integrated circuit cards was kept confidential. Due to security concerns, applications described for integrated circuit cards have unique properties. For example, each request is typically identified with a particular owner or identity. Because requests are typically written in a low-level programming language, such as assembly language, applications are written for a particular type of microcontroller. Due to the nature of low-level programming languages, unauthorized applications can access data on the integrated circuit card. Programs written for an integrated circuit card are identified with a particular identity in such a way that if two identities wish to carry out the same programming function there must be two copies of some parts of the application in the microcontroller of the integrated circuit card. Integrated circuit card systems have historically been closed systems. An integrated circuit card contained a specific application specially designed to work with a specific terminal application. Security review when an integrated circuit card was employed consisted primarily of making sure that the card application and the terminal application were a corresponding pair and that the data on the card was valid. As the popularity of integrated circuit cards grew, it became clear that integrated circuit card uses would preclude carrying a different integrated circuit card for each integrated circuit card application. Accordingly, multiple cooperation applications began to be provided on single-source integrated circuit cards. Thus, for example, an automatic cash register (ATM) access card and a debit card can coexist on a single integrated circuit card platform. However, this was still a closed system since all the applications in the terminal and the card were installed by a provider who had explicit knowledge of the other suppliers. The limitation of information regarding integrated circuit cards - especially information as to how to communicate with them and how to program them - has limited the general application of the integrated circuit card. However, the emergence of the formation of public digital networks (eg, Internet and World Wide Web) opened new application domains for integrated circuit cards. In particular, this has led to the need to load new applications on the card that do not have explicit knowledge of the other providers, but without the possibility of compromising the security of the card. However, typically, this is not practical with conventional cards that are programmed using low-level languages. SUMMARY OF THE INVENTION In general, in one aspect, the invention features an integrated circuit card for use with a terminal. The integrated circuit card includes a memory that stores an interpreter and an application that has a high-level programming language format. A card processor is configured to use the interpreter to interpret the application for execution and to use a card communicator to communicate with the terminal. Among the advantages of the present invention are one or several of the following. New applications can be downloaded to a smart card without compromising the security of the smart card. These applications can be provided by different companies loaded at different times using different terminals. Security is not covered because applications are protected against unauthorized access to any application code or data by the security features provided by the Java virtual machine. Smart card applications can be created in high-level languages such as Java and Eiffel, using powerful main program development tools. New applications can be quickly prototyped and downloaded to a smart card in a matter of hours without having to use soft masks. Nested systems that employ microcontrollers can also obtain many advantages to download new applications, development of high-level programs, as well as rapid prototyping by the use of this invention. The implementations of the present invention may include one or more of the following. The high-level programming language format of the present application may have a class file format and may have a Java programming language format. The processor can be a microcontroller. At least a part of the memory can be located in the processor. The application may have been processed from a second application having a row of characters, and the row of characters may be represented in the first application by means of an identifier (for example an integer). The processor may also be configured to receive a request from an applicant (e.g., processor or terminal) for access to an item (e.g., an application stored in memory, data stored in the memory or in the communicator) of the card, after receipt of the request, interact with the applicant to authenticate an identity of 1 applicant, and based on the identity, selectively access the item. The memory can also store an access control list for the element. The access control list provides an indication as to the types of access to be granted to the identity, and based on the access control list, the processor selectively grants specific types of access (e.g., read data, data of writing, attached data, creation data, data of removal or to execute an application) to the applicant. The application can be one of several applications stored in memory. The processor may be further configured to receive a request from an applicant to access one of several applications; after the receipt of the request, it is determined whether said application complies with a predetermined set of rules; and based on the determination, the applicant is selectively granted access to said application. The default rules provide a guide to determine whether that application has access to a predetermined region of memory. The processor may be configured itself to authenticate an identity of the requester and grant access to said application based on the identity. The processor may also be configured to interact with the terminal through the communicator to authenticate an identity; determine if the identity has been authenticated; and based on the determination, selectively allow communication between the terminal and the integrated circuit card. The communicator and the terminal can communicate through communication channels. The processor may also be configured to assign one of the communication channels to the identity when the processor allows communication between the terminal and the integrated circuit card. The processor can also be configured to assign a session key to the assigned communication channel and use the session key when the processor and the terminal communicate * through the assigned communication channel. The terminal may have a card reader, and the communicator may include a contact for communication with the card reader. The terminal may have a wireless communication device, and the communicator may include a wireless transceiver to communicate with the wireless communication device. The terminal may have a wireless communication device, and the communicator may include a wireless transmitter to communicate with the wireless communication device. In general, in another aspect, the invention features a method for use with an integrated circuit card and a terminal. The method includes storing an interpreter and at least one application having a high-level programming language format in a memory of the integrated circuit card. A processor of the integrated circuit card employs the interpreter to interpret the at least one application for execution, and the processor employs a communicator of the card when communicating between the processor and the terminal. In general, in another aspect, the invention presents a smart card. The smart card includes a memory that stores a Java interpreter and a processor configured to use the interpreter to interpret a Java application for execution. In general, in another aspect, the invention features a microcontroller having a semiconductor substrate and a memory located in the substrate. A programming language interpreter is stored in memory and configured to implement security patches. A central processing unit is located on the substrate and connected to the memory. I plementations of the invention may include one or more of the following. The interpreter can be a Java byte code interpreter. Safety reviews may include the setting of fire breaks and may include the application of a sandbox safety model. In general, in another aspect, the invention features a smart card having a programming language interpreter stored in a memory of the card. The interpreter is configured to implement a security review. A central processing unit of the card is connected to the memory. In general, in another aspect, the invention features an integrated circuit card employed with the terminal. The card includes a communicator and a memory that stores an interpreter and first instructions of a first application. The first instructions have been converted from the second instructions of a second application. The integrated circuit card includes a processor connected to the memory and configured to use the interpreter to execute the first instructions and to communicate to the terminal through the communicator. The implementations of the present invention may include one or more of the following. The first application and / or the second application can have a file format (s). The first and / or second applications may include byte codes, such as for example Java byte codes. The first instructions can be generalized or well-paid versions of the second instructions. The second instructions may include constant references, and the first instructions may include constants that replace the constant references of the second instructions. The second instructions can include references, and the references can change their location during the conversation of the second instructions to the first instructions. The first instructions can be re-linked with the references after the change. The first instructions may include byte codes for a particular type of virtual machine, and the second instructions may include byte codes for a second type of virtual machine. The first type is different from the second type. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes the conversion of second instructions from a second application to first instructions of a first application; storing the first instructions in a memory of the integrated circuit card; and the use of an integrated circuit card interpreter to execute the first instructions. In general, in another aspect, the invention features an integrated circuit for use with a terminal. The integrated circuit card has a communicator configured to communicate with the terminal and a memory that stores a first application that has been processed from a second application having a row of characters. The row of characters is represented in the first application by means of an identifier. The integrated circuit card includes a processor connected to the memory. The processor is configured to employ the interpreter to interpret the first application for execution and to use the communicator to communicate with the terminal. In general, in other aspects, the invention presents a method for use with an integrated circuit card and a terminal. The method includes the processing of a second application to create a first application. The second application has a row of characters. The row of characters are represented by an identifier in the second application. The interpreter and the first application are stored in a memory of the integrated circuit card. A processor uses an interpreter to interpret the first application for execution. In general, in another aspect, the invention features a microcontroller that includes a memory that stores an application and an interpreter. The application has a class file format. A processor of the microcontroller is connected to the memory and configured to use the interpreter to interpret the execution request. In implementations of the invention, the microcontroller may also include a communicator configured to communicate a terminal. In general, in another aspect, the invention features a method for use with an integrated circuit card. The method includes the storage of a first application in a memory of the integrated circuit card, the storage of a second application of the memory of the integrated circuit card, and the creation of a firebreak that isolates the first application and the second application in such a way that the second application can not access either the first application or data processed with the first application. In general, in another aspect, the invention features an integrated circuit card for use with a terminal. The integrated circuit card includes a communicator configured to communicate with the terminal, a memory and a processor. Memory stores applications, and each application has a high-level programming language format. The memory also stores an interpreter. The processor is connected to the memory and configured to: a) use the interpreter to interpret the applications for execution, b) use the interpreter to create a firewall to isolate applications between them, and c) use the communicator to communicate with the terminal. Other advantages and features will be apparent from the following description and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of an integrated card system. Figure 2 is a flowchart illustrating the preparation of Java applications for download into an integrated circuit card. Figure 3 is a block diagram of the files used and generated by the card class file converter. Figure 4 is a block diagram illustrating the transformation of application class file (s) into a card class file. Figure 5 is a flow diagram illustrating the operation of the class file converter. Figure 6 is a flow diagram illustrating the modification of the byte codes. Figure 7 is a block diagram illustrating the transformation of specific byte codes into general byte codes. Figure 8 is a block diagram illustrating the replacement of constant references with constants. Figure 9 is a block diagram illustrating the replacement of references with their updated values.

Figure 10 is a block diagram illustrating the renumbering of original byte codes. Figure 11 is a block diagram illustrating the translation of original byte codes for a different virtual machine architecture. Fig. 12 is a block diagram illustrating the loading of applications into an integrated circuit card. Figure 13 is a block diagram illustrating the execution of applications on an integrated circuit card. Figure 14 is a schematic diagram illustrating the organization of memory from ROM, RAM and EEPROM. Fig. 15 is a flow chart illustrating the overall architecture of the Java virtual machine for card. Figure 16 is a flow diagram illustrating the execution of the method in the Java virtual machine for card with security patches. Figure 17 is a flow diagram illustrating the execution of byte code in the Java virtual machine for card. Figure 18 is a flow diagram illustrating the method execution in the Java virtual machine for card without security checks. Figure 19 is a block diagram illustrating the association between card applications and identities.

Figure 20 is a block diagram illustrating the access rights of a specific application. Figure 21 is a perspective view of a microcontroller on a smart card. Figure 22 is a perspective view of a microcontroller in a telephone. Figure 23 is a perspective view of a microcontroller on a keychain. Figure 24 is a perspective view of a microcontroller in a ring. Figure 25 is a perspective view of a micro controller on a circuit board of a car. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to FIG. 1, an integrated circuit card 10 (e.g., a smart card) is constructed to provide high-level, multi-application programming, based on Java, and around execution. The integrated circuit card 10 has a communicator 12 configured to communicate with a terminal communicator 12 b of a terminal 14. In some embodiments, the integrated circuit card 10 is a smart card with an 8-bit microcontroller, 512 bytes of RAM, 4 Kbytes of EEPROM and 20 K of ROM; the terminal communicator 12 b is a conventional contact smart card reader; and terminal 14 is a conventional personal computer having the Windows NT operating system that supports the personal computer smart card (PC / SC) standard and provides Java development support. In some embodiments, the microcontroller, memory and communicator are nested in a plastic card that has substantially the same dimensions as a typical credit card. In other modalities, the microcontroller, the memory and the communicator are connected in bases other than a plastic card, such as jewelry (for example, watches, rings or bracelets), automotive equipment, telecommunications equipment such as, for example, cards of subscriber identity module (SIM), security device (for example cryptographic modules) and electrical devices. The terminal 14 prepares and downloads the Java applications on the integrated circuit card 10 using the terminal communicator 12 b. The terminal communicator 12 b is a communications device capable of establishing a communication channel between the integrated circuit card 10 and the terminal 14. Some communication options include contact card readers, wireless communications via radio frequency or infrared techniques, serial communication protocols, packet communication protocols, ISO 7816 communication protocol, to name some of these techniques. The terminal 14 can also interact with applications that operate on the integrated circuit card 10. In some cases, different terminals can be used for these purposes. For example, one type of terminal can be used to separate applications, different terminals can be used to download the applications, and other terminals can be used to handle the various applications. The terminals can be automated cash registers (ATM) s, point of sale terminals, account security systems, quota payment systems, access control systems, or any other system that communicates with an integrated circuit card or microcontroller The integrated circuit card 10 contains a card Java virtual machine (Card JVM) 16a which is used to interpret applications contained in the card 10. With reference to figure 2, the Java 20 application includes 3 Java source code files A. Java 20 a, B. Java 20 by C. Java 20 c. These source code files are prepared and compiled in a Java 22 application development environment. When the Java 20 application is compiled by the development environment 22, application class 24 files are produced, with these class A files Class 24 a, B Class 24 b, C Class 24 c corresponding to their Java source code of respective class 20 a, 20 b, 20 c. The application class 24 files follow the standard class file format, in accordance with what is documented in chapter four of the Java virtual machine specification by Tim Lindhol and Frank Ye1lin, "The Java Virtual Machine Specification," Addison- Wesley 1996. These application case files 24 are fed into the card class file converter 26 which consolidates and compresses the files, producing a unique card class file 27. The card class file 27 scraped into the card of integrated circuit 10 using a conventional card charger 28. With reference to FIG. 3, the card class file converter 26 is a class file post-processor that processes a class 24 file set encoded in the file format Java standard, optionally employing a string to record map file ID 30 to produce a Java 27 card class file in a file format of card class. A card class file format of this type is described in Annex A which is incorporated herein by reference. In addition, in some embodiments, the card class file converter 26 produces a string to send map file ID 32 which is used as input for a subsequent execution of the card class file converter. In some modalities, for the string to map the ID to be consistent with a previously generated card class file (in the case where several class files refer to the same strings), the card class file converter 26 can accept pre-defined chains for ID mapping from a string for register mark file ID 30. In the absence of such a file, the iDs are generated by the card class file converter 26. The annex B, which is incorporated herein by reference, describes a possible way of implementing and producing the string for the mark-in file ID 30 and the string for the mark-out file ID 32 and illustrates this mapping by means of an example. With reference to Figure 4, a typical application class file 24 a includes a class 41 file information; a set of class 42 constant; a class, created fields, referenced interfaces, and method information 43; and various attribute information 44, in accordance with what was presented with details in the Java Virtual Machine Specification mentioned above. Note that a large part of the attribute information 44 is not required for this mode and 46 is eliminated by means of the card class file converter 26. The deleted attributes include SourceFile, ConstantValue, Exceptions, LineNumberTable, LocalVariableTable, and any attribute of optional vendor. The typical card class file 27 as described in Annex A is derived from the application class 24 files as follows. The card class file information 46 is derived from the aggregate class file information 41 of all the application class files 24 a, 24 b, and 24 c. The card class file constant set 47 is derived from the aggregate class constant set 42 of all application class files 24 a, 24 b, and 24 c. The card class, created fields, referenced interfaces as well as method information 48 are derived from the class of aggregates, created fields, referenced interfaces and method information 43 of all application class files 24 a, 24 b, and 24 c. The card attribute information 49 in this mode is derived from only the code attribute of aggregate attribute information 44 of all application class files 24 a, 24 b, and 24 c. In order to avoid the dynamic link in the card, all the information that is distributed in several Java class files 24 a, 24 b and 24 c that form the application 24, are joined in a card class file 27 by means of of the process illustrated in the flow chart of Figure 5. The first class file to be processed is selected 51 a. The constant assembly 42 is compacted 51 b in the following manner. All objects, classes, fields, methods referenced in a Java class file 24 a are identified by using strings in the constant set 42 of the class file 24 a. EX card class file converter 26 compacts the constant set 42 found in the Java class file 24 to an optimized version. This compaction is achieved by mapping all the strings found in the constant class 42 file set into integers (whose size depends on the architecture of the microcontroller). These integers are also known as IDs. Each ID identifies only a particular object, a particular class, a particular field or a particular method in the application 20 accordingly, a particular class, a particular field or a particular method in the application 20. Therefore, the file converter of card class 26 replaces the strings in the constant set of Java class file 42 with its corresponding unique ID. Annex B shows an exemplary application HelloSmartCard.Java, with a table that illustrates the IDs corresponding to the strings. Found in the constant set of the class file for this application. The IDs used for this example are non-signed 16-bit integers. Then, the card class file converter 26 checks to determine the presence of unsupported features 51 c in the code attribute of the input Java class file 24 a. The card JVM 16 supports only a subset of the full Java byte codes in accordance with that described in Annex C, which is incorporated herein by reference. Accordingly, the card class file converter 26 checks to determine the presence of byte codes not supported in the code attribute of the Java class file 24 a. If unsupported byte codes 52 are found, the card class file converter indicates an error and suspends the conversion 53. In the program code fragments marked "A" in Annex D shows how these spurious byte codes are they drive. Another level of revision can be carried out by requesting that the standard Java development environment 22 compile application 20 with a "-G" marker. Based on the aforementioned Java virtual machine specification, this option asks the Java compiler to put information about the variables used in a Java 20 application in the LocalVariableTable attribute of the class file 24 a. The card class file converter 26 uses this information to check whether the Java class file 24 a refers to data types not supported by the Java card. Then, the card class file converter 26 undresses all unnecessary parts 51 c from the Java class 24 file to not required for its interpretation. A Java class file 24 a stores information that belongs to the byte codes in the class file in the Attributes section 44 of the Java class file. Attributes not required for JVM interpretation of card 16 such as SourceFile, Cons antValue, Exions, LineNumberTable, and LocalVariableTable can safely be undone 45. The only retained attribute is the Code attribute. The Code attribute contains the byte codes that correspond to the methods in the Java class file 24 a. The modification of the byte codes 54 includes the examination of the code attribute information 44 for each method in the class file, and the modification of the byte code operands that refer to entries in the set of file constants. of Java class 42 to reflect the entries in the set of card class file constants 47. In certain embodiments, the byte codes are also modified as described below. The modification of the byte codes 54 includes five passes (with two optional passes) in accordance with what is described in the flow chart of Figure 6. The original byte codes 60 are found in the attribute of Code 44 of the class file of Java 24 a in process. The first pass 61 'records all the stops and their destinations in the original byte codes. During the subsequent translation of bytecode a single byte code can be translated into double or triple bytes. Figure 7 illustrates an example where the byte code ILOAD _0 is replaced by 2 bytes, the ILOAD byte code and argument 0. When this is done, the code size changes, which requires an adjustment of the destinations of jump affected. Accordingly, before making these transformations, the original byte codes 60 are analyzed to determine any jump byte code and its current position and destination are noted. The fragment of program code marked "B" in Annex D shows how these jumps are recorded. Annex D is incorporated by reference. Once the hops have been registered, if the optional byte code translation 72 is not carried, the card class file converter 26 can follow up to the third pass 64. Otherwise, the card class file converter converts code of specific bytes in generic byte codes. Specifically, the translated byte codes are not interpreted in the card JVM 16 but are supported by the conversion of the byte codes into equivalent byte codes that can be interpreted by JVM on card 16 (Figure 7). The byte codes 70 can be replaced by other semantically equivalent but different byte codes 72. This generally involves the translation of small specific unique byte codes such as ILOAD_0 in their more general versions. For example, ILOAD_0 may be replaced by the ILOAD byte code with an argument 0. This translation is done to reduce the number of bytecode translated by the card JVM 16 thereby reducing the complexity and the code space requirement for card JVM 16. The fragment of program code marked "C" in Annex D shows how these translations are made. Note that such translations increase the size of the resulting byte code and force the recalculation of any affected leap. On the third pass 64, the card class file converter reconstructs constant references by eliminating the strings used to denote these constants. Figure 8 shows an example where the byte code LDC 80 which refers to the constant «18» found through an index in the set of constants 42 of Java class file 24 a can be translated into the code of BIPUSH bytes 82. In this pass, the card class file converter 26 modifies the operands for all the byte codes that refer to the entries in the set of Java class file constants 42 to reflect its new location in the card class file constant set 47. Figure 9 shows an example in which the argument to a bytecode, INVOKESTATIC 90, refers to an entry in the set of Java 42 class file constants modified to reflect the new location of this entry in the set of card class file constants 47. Modified operand 94 shows this transformation. The fragment of program code marked "D" in Annex D shows how these modifications are carried out. Once the constant references are re-linked, if the optional bytecode modification is not carried out, the card class file converter can continue until the sixth and last pass 67. Otherwise, the class file converter of card modifies the original byte codes in a different set of byte codes supported by the particular card JVM 16 that is employing a potential modification renumbers the original byte codes 60 in card JVM byte codes 16 (see FIG. ). This renumbering causes the byte codes 100 in the original byte codes 60 to be modified into renumbered byte codes 102. ILOAD of byte code recognized by the value 21 can be renumbered until it is recognized by the value 50. This modification it can be carried out to optimize the type tests (also known in the prior art as pass revisions 3) in the card 16 JVM. The program code fragment marked "E" in Annex D shows an implementation of this mode . This modification can be carried out in order to reduce the program space required by the card JVM 16 to interpret the byte code. Essentially this modification groups the byte codes into card JVM byte codes 16 in such a way that the byte codes with similar operands are grouped together, and there are no spaces between the card 16 JVM byte codes. This allows the JVM card 16 efficiently check card JVM byte codes 16 and validate the types as executed. In some embodiments, the card class file converter modifies the original byte codes 60 into a different set of byte codes designed for a different virtual machine architecture, as shown in Figure 11. ILOAD 112 byte code Java for use in a stack of words 114 can be replaced by the card JVM byte code ILOAD_B 116 for use in a byte stack 118. An element in a stack of words 114 requires the allocation of 4 bytes stack space, while an element in the byte stack 118 requires only one byte of stack space. Although this option may provide an increase in the execution speed, there is a risk of losing the security features available in the original byte codes.

Since the previous stages 63, 63 or 66 may have changed the size of the byte codes 60, the converter of the card class file 26 has to re-link 67 any jump made. Since the jumps were recorded in the first step 61 of the card class file converter 26, this adjustment is carried out by setting the jump destinations to their appropriate values. The fragment of program code marked "F" in Annex D shows how these jumps are fixed. The card class file converter now modifies the byte codes 68 equivalent to the original byte codes 60 ready for loading. The translation from the Java class file 24 to the card class file 27 is now complete. Referring again to Figure 5, if more Class 24. files remain to be processed, the previous steps 51 a, 51 b, 51 c, 52 and 54 are repeated for each remaining class file. The card class file converter 26 brings together the maps and modified byte codes for the classes 24 that have been processed, places them as an aggregate and generates a card class file 27. When required, the converter card file 26 generates a string to the output map file of ID 32 which contains a list of all the new IDs allocated for the strings found in the set of constants 42 of the Java 24 class files during the translation. With reference to Figure 12, the card charger 28 within the terminal 14 sends a card class file to the load and execution control 120 within the integrated circuit card 10 using standard ISO 7816 commands. The load control and execution 120 with a card operation system 122, which provides the necessary system resources, including support for a card file system 124, which can be used to store several card applications 126. Many card chargers conventional cards are written in low-level languages, supported by the operating system of the card 122. In the preferred embodiment, the bootstrap loader is written in Java, and the integrated circuit card 10 includes a Java virtual machine for handle this application. A Java implementation of the load and execution control 120 is illustrated in Annex E which is incorporated by reference. The load control and execution 120 receives the card class file 26 and produces a Java card application 126x stored in the card file system 126 in the EEPROM memory of the integrated circuit board 10. Multiple Java card applications 126x , 126y, and 126z can be stored in a single card in this manner. The load control and execution 120 supports commands by which the terminal 14 can select which Java card application should be handled immediately or when restarting the next card. With reference to Figure 13, upon receipt of a restart or execution command of the load and execution control 120, the Card Java Virtual Machine (Card JVM) 16 begins execution of a predetermined (eg, primary) method. of the selected class in the selected Java card application 126 z. The card JVM 16 provides the Java card application 126z access to the underlying card operating system 122, which provides capabilities such as 1/0, EEPROM support, file systems, access control, and other system functions employing native Java methods in accordance with what is illustrated in Annex F that is incorporated by reference. The selected Java card application 126z communicates with an appropriate application in terminal 14 by using the communicator 12 a to establish a communication channel with the terminal 14. Data from the communicator 12 through terminal 14 pass through a controller of communicator 132 in the terminal, written specifically to handle the communications protocol used by the communicator 12 a. The data then passes to an integrated circuit card controller 134 specifically written to address the capabilities of the particular integrated circuit card 10 being employed, and provides high level programmatic services to the terminal application 136. In the preferred mode, said controller would be an appropriate programmatic of PC / SC (SSP) smart card service provider. The data then passes to the terminal application 136 which must handle the capabilities provided by the particular card application 126z that is being handled. In this way, commands and responses pass between the terminal application 136 and the selected card application 126z. The terminal application interacts with the user, receiving user commands, some of which pass to the selected Java card application 126z, and receiving response from the Java 126z card application, which are processed and returned to the user. With reference to Figure 14, the card JVM 16 is an interpreter interpreting a 126x card application. The memory resources in the microcontroller that impact the card JVM 16 are the card ROM 140, the card RAM 141 and the card EEPROM 142. The card ROM 140 is used to store the card JVM. 16 and the card operating system 122. The card ROM 140 can also be used to store fixed card applications 140a and class 140b libraries. Loadable applications 141 a, 141 b and libraries 141 c may also be stored in the card RAM memory 141. The card JVM 16 interprets a card application 141 a, 141 b or 140 a. The card JVM 16 uses the card RAM memory to store the VM stack 144 a and the system sets 144 b variables. The card JVM 16 keeps track of the operations performed through the VM 144 a. The objects created by the card JVM 16 are either in the RAM heap 144 c, in the EEPROM heap 146 a or in the file system 147. All the piles handled by the card JVM 16 may be stored in the card RAM memory 141 as a stack of RAM 144 co may well be distributed in card EEPROM 142 as an EPROM Heap 146 a. The card RAM 141 is also used to record the state of the system stack 148 that is employed by routines written in the native code of the microcontroller. The card JVM 16 uses card EEPROM memory 142 to store application data either in the EEPROM stack 146 or in the file system 147. Application data stored in a file can be manipulated through an interface with the system operation of the card 122. This interface is provided by a class library 140b stored in the card ROM 140, by a loadable class library 141c stored in the card EEPROM memory 142. An interface of this type is described in Appendix F. Applications and data on the card are isolated by means of a "fire-cut-off" mechanism 149. To handle the limited resources available in the microcontrollers, the card JVM 16 implements a strict subset of the Java programming language. Therefore, a Java 20 application is compiled into a class file that contains a strict subset of Java byte codes. This allows application developers to program this tight subset of Java and still maintain compatibility with existing Java virtual machines. The semantics of the Java byte codes interpreted by the card JVM 16 are described in the aforementioned Java virtual machine specification. The subset of byte codes interpreted by card JVM 16 can be found in Annex C. The card class file converter 26 reviews the Java 20 application to ensure the use of only the features available in this subset and converts it in a form understandable and interpreted by the JVM of card 16. In other modalities, the card JVM 16 is designed to interpret a different set or an increased set of byte codes 116. Even though a different set of byte codes may lead to certain improvements in performance, the non-compliance to a subset Strict Java may not be desirable from the security perspective present in the original Java byte codes or compatibility with major Java development tools. All JVM applications 126 of card 16 have an entry point indicated by means of a class and a method in the class. This entry point is mapped in the chain to the ID 30 entry map and is assigned by the card class file converter 26. Classes, methods and fields within a Java application 20 receive IDs from the inverter. card class files 26. For example, the ID that corresponds to the main application class can be defined as F001 and the ID corresponding to its main method, such as "V () main" could be defined as F002. The overall execution architecture of the card JVM is described in the flow chart of Figure 15. The execution of the card JVM 16 begins at execution control 120, which selects a card application 126z for execution. Continue finding and assigning an entry point 152 (one method) in this card application for interpretation by the card 16 JVM. The card JVM 16 interprets the method 153. If the interpretation is successful 154, the card JVM 16 reports success 155 by returning control to execution control 120. If, in the course of interpretation 153, card JVM 16 encounters an unattached error or exception (specifically a resource limitation or a security breach) ), the card JVM 16 separates 156 and reports the appropriate error to terminal 14. An essential part of the card JVM 16 is a subroutine that handles the execution of the byte codes. This subroutine is described in the flow diagram of Figure 16. Given a method 160, it executes the byte codes in this method. The subroutine begins by preparing the parameters of this method 161. This includes setting a stack pointer VM 144 a, stack frame limits VM 144 a, and setting the program counter to the first byte code of the method. Then, the markers of method 162 are checked. If the method is marked natively, then the method is in fact a call to a native method code (subroutine written in the native processor code of the microcontroller). In this case, the card JVM 16 prepares a poor 163 call and returns to the subroutine of the native code. The parameters for the native method can be passed in VM stack 144 to or through system stack 148. Appropriate security revisions are elaborated and called the native method subroutine. When returning, the result (if there is a result) of the subroutine of the native method is placed in the stack VM 144 a in such a way that it can be accessed through the following byte code to be executed. The assignment loop 164 of the card JVM 16 is then recorded. The byte code allocation loop is responsible for preparing, executing and removing each byte code. The loop terminates when it has just interpreted the byte codes in the method 160, or when the card JVM 16 encounters a resource limitation or a security violation. If the previous byte code caused a branch 165 to be taken, the card JVM prepares for branch 165 a. The next byte code is retrieved 165b. In order to keep the processing cost of each bytecode low, as many common elements as possible, such as bytecode arguments, are extracted and stored., length, and type. In order to offer the security offered by the security model of the programming language, the byte codes must be verified and determined in the class file in accordance with this model. These revisions are typically carried out in the prior art by a program known as the byte code verifier which operates in four passes in accordance with that described in the Java Virtual Machine Specification. To offer the security of activation time that is guaranteed by the byte code verifier, the card JVM 16 must carry out the revisions corresponding to pass 3 and pass 4 of the verifier. This revision can be avoided by the card JVM 16 if it can guarantee (which is almost impossible to do) that the byte codes 60 interpreted by the card JVM 16 are secure codes. At a minimum, code security can be maintained to the extent that object references can not be falsified and to the extent that VM stack 144 a and local variable limits are observed. This requires checking the state of the VM 144 stack in terms of the byte code that is running. To apply the security model of the programming language, a table of 256 bytes is created as shown in Annex G which is incorporated herein by reference. This table is indexed by the byte code number. This table contains the type and length information associated with the index byte code. It is encoded with the first 5 bits that represent the type and the last 3 bits that represent the length. The type and length of the bytecode is indexed directly from the table by the bytecode number. This type and this length are then used for review as shown in Annex H which is incorporated herein by reference. In Annex H, the revision process begins by decoding the length and type of the table in Annex H that is incorporated herein by reference. The length is used to increase the program counter. The type is used first for pre-execution review, in order to ensure that the data types in the VM stack 144 a are correct for the byte code that is about to be executed. The 256 bytes of the ROM for table storage allow the original Java byte codes to be used in the card JVM 16 and minimize the required changes to the Java class file when loading into the card. Additional Java byte codes can be easily supported since it is relatively easy to update the appropriate table entries. In other embodiments, as shown in Figure 10, the Java byte codes in the method are renumbered in such a way that the type and byte code length information stored in the table in Annex H is implicit in the reordering. Annex H is incorporated herein by reference. Therefore, the checks that must be carried out on the state of the VM 144 a stack and the byte code that is being processed do not have to involve a table lookup. Revisions can be carried out by means of simple comparison sets as shown in Appendix I by reference. This mode is preferable when the ROM space is very requested since it eliminates a table of 256 bytes. However, the addition of new byte codes to the set of supported byte codes should be carefully considered since the new byte codes should be adjusted in the implicit numbering scheme of the supported byte codes. In another embodiment, the card JVM 16 chooses not to perform any security checks in favor of the execution speed of the card 16 JVM. This is illustrated in the flow chart in figure 18. The flow chart of Figure 18 is the same as the flow diagram in Figure 16 with removal of security checks. This option is not desirable from a security perspective, unless you can guarantee that the byte codes are safe. The JVM card 16 can apply other security checks as well. If the bytecode can refer to a local variable, the card JVM 16 checks if this reference is valid, indicating an error if it is not the case. If the reference is valid, the card JVM 16 stores the type of the local variable for future search. The stack pointer VM 144 a is checked to determine if it is still in a valid range. If this is not the case, an exception is determined. The byte code number is checked. If it is not supported, an exception is indicated.

Finally, the byte code itself is sent 165d. The byte codes translated by the card JVM 16 appear in the list in Annex C. The semantics of the byte codes are described in the aforementioned Java Virtual Machine Specification regarding the state of the VM 144 stack before and after sending the bytecode. Note also that certain byte codes (the byte codes, INVOKESTATIC, INVOKESPECIAL, INVOKENONVIRTUAL, and INVOKEVIRTUAL) may cause reentry in the card JVM 16 requiring processing to begin at the input of the subroutine 161. Figure 17 shows the diagram flow of the byte code execution routine. The routine receives a 171 byte code to execute. The card JVM 16 executes 172 the instructions required for the bytecode. If during the execution the card JVM 16 encounters a resource limitation 173, it returns an error 156. This error is returned to the terminal 16 by means of the card JVM 16. If the byte code is executed successfully, returns a 175 success. After execution, the result type is used to set the VM 144 stack to correctly 165 e, to properly mark the data types in the VM stack 144 a. The previously-assembled byte code information 165 b from the byte code information table is used to set the state of the VM stack 144 a in accordance with the code that has just been executed. In other embodiments, setting the output state of the stack VM 144 a in relation to the byte code executed is simplified if the byte code is renumbered. This is shown in Annex I that is incorporated herein by reference. In another embodiment, the card JVM 16 may prevent adjustment of the output state of the VM stack 144 in favor of the execution speed of the card 16 JVM. This option is not desirable from a security perspective, unless you can guarantee that the byte codes are safe. After execution of the bytecode, byte code 165 f is removed. This includes the disappearance of arguments from the VM 144 stack. Once the byte code processing is finished, loop 164 is repeated for the next byte code for the method. Upon completion of the send loop 164, the stack of VM 144 a is emptied 166. This prevents them from filtering object references to other card JVM invocations 16 and prevents the breakdown of the security of the card 16 JVM. 167 of the 164 byte code send loop indicates that the card JVM 16 has finished executing the required method. To isolate data and applications on the integrated circuit card 10 from each other, the integrated circuit card 10 is based on the firebreaking mechanism 149 provided by the card 16 JVM. Since the card JVM implements the checker reviews of passed 3 and passed 4 standards detects any attempt by an application to refer to the data or coding space used by another application, and signal to a security error 156. For example, conventional low-level applications may issue types of data of no reference in references, thus enabling access to a non-authorized memory space, and violating security. With this invention, such an attempt by a card application 126z to use a non-reference data type as a reference will cause a security breach 156. Conventional Java, this protected application environment is referred to as an application interpretation environment. of sandbox. However, these fire-fighting facilities do not work independently. In fact, the facilities are spliced and mutually reinforcing with conventional access control lists and coding mechanisms illustrated in the following table: Coding Machine Lists. virtual access control Access Control Protection Data to other data access before only to program Together these facilities isolate both data and applications in the integrated circuit card 10 and ensure that each card application 126 can have access only to authorized resources of the integrated circuit card 10. With reference to figure 19, the 126x, 126y and 126z card applications may be equipped with specific privileges when the card applications 126 are executed. These privileges determine, for example, to which data files the card applications 126 may access and which operations may carry out the card 126 applications in the 147 file system.

The privileges granted to the card applications 126 are normally established at the time at which a particular card application 126 z is initiated by the user typically from the terminal 14. The integrated circuit card 10 employs identification verification methods cryptographic to associate an identity 190 (for example identities 190 a, 190 b, and 190 c) and consequently, a set of privileges for the execution of the card application 126. The association of the specific identity 190 ca the card application 126z is performed when the card application 126 z begins execution, thereby creating a specific operating application 200, as shown in Figure 20. The identity 190 is a single legible text string reliably associated with an identity element. The identity element (for example, personal identification number (PIN) or an RSA private key) is a coding key. With reference to Figure 20, in order to handle a specific card application 126z, the identity 190c of the card application 126 z must be authenticated. The identity 190 c is authenticated by demonstrating knowledge of the identity element associated with the identity 190c. Accordingly, in order to activate the 126z card application, an agent (for example, the cardholder or another application that wishes to activate the application) must show that he / she possesses or knows the encryption key that defines the identity of the card. the application. One way to demonstrate the position of a code key is simply to show the key itself. NIP verification is an example of this form of authentication. Another way to demonstrate the position of an encoding key without displaying the same key is to show the ability to encode or decode plain text with the key. Thus, a specific operating application 200 on the integrated circuit card 10 includes a card application 126 z plus an authentic identity 190 c. No card application 126 can operate without both elements in place. The card application 126 z defines data processing operations to be carried out, and the authenticated identity 190 c determines in which computational objects these operations can be carried out. For example, a specific application 126z can only access the C 202 identity files in the file system 147 associated with the specific identity 190 c, and the specific card application 126 z can not access other files 204 associated with identities other than the specific identity 190 c. The integrated circuit card 10 can take additional steps to insure data isolation and application. The integrated circuit card 10 provides 3 sets of programmatic characteristics: access control lists of authenticated identities; a Java-based virtual machine; and session coding keys at a time to protect data files, application execution, and communication channels, respectively. Collectively, for a modality, these feature sets provide the application with short application data fires 149 for a modality. Next, each set of programmatic characteristics is discussed and then the three sets are shown to work together to ensure data isolation and application on the integrated circuit card 10. An access control list (ACL) is related to each computational object (e.g., a data file or a communication channel) in the integrated circuit card 10 that is to be protected, i.e., to which the access must be controlled. An entry in an ACL (for a particular computational object) is a data format known as e-tuple: Type: identity: permissions The type field indicates the type of the next identity (in the identity field), for example, a user (for example "John Smith"), or a group. The permission field indicates a list of operations (for example, reading, adding and updating) that can be performed by the identity in the computational object. For example, in the case of a data file that has the ACL entry: USER: AcmeAirlines: RAU, Any application whose identity is "AcmeAirlines" can read ("R"), add ("A") and update (" U ») the data file. In addition, the ACL can be used selectively to allow the creation and removal of data files. In addition, the ACL can be used selectively to allow the execution of an application. When an application 200 has access to a computational object, the access is interpreted by the card JVM 16 and passed to the operating system of the card 122, which determines whether there is an ACL associated with the object. If there is an associated ACL, then the identity 190 c associated with the running application 200 is compared in the ACL. If no identity is found or if the identity is not allowed for the type of access requested, then access is denied. Otherwise, access is allowed. With reference to Figure 13, to avoid the potential problems caused by the unique data path between the integrated circuit card 10 and the terminal 14, communication channel isolation is achieved by including in the identity authentication process the exchange of a time description key 209 between the card application 126z and the terminal application 136. The key 209 is then used to encode subsequent traffic between the authentication terminal application 136 and the authenticated card application 126z. Given the one-time session key 209, an illicit terminal application can not "listen" for an authenticated communication between the terminal 14 and the integrated circuit card 10, nor can the illicit terminal authentication "cheat" the card application to perform unauthorized operations on your part. The coding and decoding of card / terminal traffic can be handled either by a card operating system 122 or by the same card application 126z. In the first case, the communication with terminal 14 is transparently encoded for the application, and the message traffic arrives decoded in the data space of the application. In the latter case, the card application 126z chooses the encoding and decoding embodiment to provide an extra layer of security since the application could encode data as soon as data is created and decoded only when it is about to be used. Otherwise, the data would remain encoded with session key 209.

Thus, the application firebreak includes 3 sets of programmatic that reinforce each other. The data files are protected by authenticated identity access control lists. The application execution spaces are protected by the card JVM 16. The communication channels are protected by session coding keys at a time 209. In other embodiments, the techniques described above are used with a microcontroller (such as the processor 12) and can control devices (eg, part of an automobile engine) other than an integrated circuit card. In these applications, the microcontroller provides a small platform (ie, a central processing unit, and a memory, both located on a semiconductor substrate) to store and execute high-level programming languages. Most existing devices and new designs using a microcontroller would use this invention to provide the ability to program in microcontroller using a high level language, and the application of this invention to devices of this type is specifically included. The application includes any program, such as Java applications, Java applets, Java aglets, Java servlets, Java commlets, Java components, and other non-Java programs that may result in class files in accordance with what is described below. Class files can have a source other than Java program files. Several programming languages other than Java also have compilers or assemblers to generate class files for their respective source files. For example, an Eiffel programming language can be used to generate class files using "J-Eiffel" from Primin kalberer, an Eiffel compiler with JVM byte code generation (Web site: http // www. Spin. Ch / 'kalberer / jive / index.htm). An Ada 95 translator is described to Java byte code in the following reference (which is incorporated herein by reference) namely: Taft, S. Truker, "Programming the Internet in Ada 95", Ada Europe '96m 1996 minutes Jasmin is a Java byte code assembler that can be used to generate class files, in accordance with what is described in the following reference (which is incorporated here by reference): Meyer, Jon and Troy Downing, «Java Virtual Machine» , O'Reilly, 1997. Regardless of the source of the class files, the previous description applies to languages other than Java to generate codes to interpret. Figure 21 shows an integrated circuit card, or smart card, including a microcontroller 210 mounted on a plastic card 212 has approximately the same form factor as a typical credit card. A communicator 12 a may employ a contact pad 214 to establish a communication channel, or the communicator 12 a may employ a wireless communication system. In other embodiments, a microcontroller 210 mounts to a mobile or fixed telephone 220, effectively adding smart card capabilities to the telephone, as shown in FIG. 22. In these embodiments, the microcontroller 210 is mounted on a module (such as a subscriber identity module (SIM)), for insertion and removal of the telephone 220. In other embodiments, a microcontroller 210 is added to a key ring 230 as shown in figure 23. This can be used to protect access to a car equipped to recognize the identity associated with the microcontroller 210 in the key ring 230. Jewel such as watch or ring 240 may also host a microcontroller 210 in an ergonomic manner, as shown in Figure 24. Such modalities typically employ a wireless communication system to establish a communication channel and are a convenient way to implement access control with a minimum of problems for the user.

Figure 25 illustrates a microcontroller 210 mounted on an electrical subsystem 252 of an automobile 254. In this embodiment, the microcontroller is used for various purposes, such as for example to control access to the automobile (for example, to check the identity or condition of the vehicle). Sobriety before allowing the car's ignition system), pay fees through wireless communication, or make a connection with a global positioning system (GPS) to track the location of the car, just to mention some options. While specific embodiments of the present invention have been described, various modifications and substitutions will be apparent to one skilled in the art. Such modifications and substitutions are within the scope of the present invention and are covered by the appended claims.

APPENDIX A Card class file format for preferred mode. Introduction The card class file is a compressed format of the original class file (s). The card class file contains only the semantic information required to interpret Java programs from the original class files. Indirect references in the original class file are replaced with direct references resulting in a compact presentation. The card class file format is based on the following principles: Stay close to the standard class file format: The card class file format should remain as close as possible to the standard class file format. The Java byte codes in the class file remain unchanged. The non-alteration of the byte codes ensures that the structural and static limitations on them remain intact in a verifiable manner. Ease of implementation: the card class file format should be simple enough to be interesting for the Java Virtual Machine implementers. It must allow different implementations, however, with an equivalent behavior. Factability: the card class file format must be compact in order to host a smart card technology. It must meet the limitations of current technology without losing sight of the innovations of tomorrow. This document is based on chapter 4, "the class file format", in the book entitled "The Java (TM) Virtual Machine Sepecification" (1) known below as the Red book. Since this document is based on the standard class file format described in the Red book, we present only information that is different. The book Red serves as the final authority for any clarification. The primary changes in relation to the standard format of the class file are: The set of constants is optimized to contain only 16-bit identifiers and, if possible, the indirection is replaced by a direct reference. The attributes in the original class file are either deleted or regrouped. The Java card class file format This section describes the Java card class file format. Each card class file contains one or many types of Java, where a type can be a class or an interface. A card class file consists of an 8 bit byte stream. All quantities of 16 bits, 32 bits, and 64 bits are constructed for reading in 2, 4 and 8 consecutive bytes of 8 bits, respectively. Multiple byte data elements are always stored in order of termination may r, where the high bytes pass first. In Java, this format is supported by Java interfaces. io.Datalnput and Java.oi.DataOutputStream and classes such as Java.oi.DatalnputStream and Java. io.DataOutputStrean. We define and use the same set of data types that represent Java class file data: ul types, u2 and u4 represent an amount of 1 byte, 2 bytes or 4 unsigned bytes, respectively. In Java, these types can be read by methods such as readUsignedB te, readUnsignedShort, and readlnt from the inreface Java.Datalnput. The card class file format is presented using a pseudo-structure written in a structural type-C notation. To avoid confusion with the fields of the classes of the Java Card Virtual Machine and class cases, the contents of the structures that describe The card class file format are known as elements. Unlike the fields of a C structure, successive elements are stored in the card class file sequentially, without filling or alignment. Variable-sized tables, which consist of elements of variable size, are used in various class file structures. Even though we will use a C-type set syntax to refer to the table elements, the fact that tables are streams of structures of various sizes means that it is not possible to directly translate a table index into a byte offset in the table. When we refer to a structure to a data structure as a whole, it is literally a set.

In order to distinguish between the card class file structure and the standard class file structure, we add capital letters; For example, we rename field_info in the original class file as Fiellnfo in the card class file. Card class file A card class file contains a unique CardClassFile structure: CardClasFile Ul major_version; Ul mdnor_version; U2 name_index; U2 const_size; U2 max class; Cplnfo constant_pool (const_size); Classlnfo class (max_class); The elements in the CardClassFile structure are the following: Minor__version, major_version The values of the minor_version and major_version elements are the numbers of the major and minor versions of the out-of-card Java Card Virtual Machine that produced this card class file. An implementation of the Java Card Virtual Machine usually supports card class files that have a given major version number and a minor version number 0 up to a particular minor_version. Only the Java Card Forum can define the meaning of the card class file version numbers. Name_index The value of the name_index element must represent a valid Java class name. The Java class name represented by name_index must be exactly the same as the Java class name that corresponds to the main application to be used on the card. A card class file contains several classes or interfaces that make up the application that works on the card. Since Java allows each class to contain a main method, there must be a way to distinguish the class file that contains the main method that corresponds to the card application. Const_size The value of const_size provides the number of entries in the set of card class file constants. A constant_pool index is considered valid if it is greater than zero or equal to zero and less than const_size. max_class This value refers to the number of classes present in the card class file. Since the name resolution and the link in the Java Card are performed by the Java Virtual Machine off-card, all the class files or classes required for an application are placed together in a card class file. Constant_pool Constant_pool is a variable length structure table () that represents several chain constants, class names, field names, and other known constants within the structure of CardClassFile and its substructures. The first entry in the card class file is constant_pool (0). Each of the constant_pool table entries in indexes 0 to const_size is a variable length structure (). Class The class is a table of classes of Max_claes that constitute the application loaded on the card. Constant set All the entries in the constant_pool table have the following general format: CpInfo. { Ul tag; Ul info []; } Each element in the constant_pool table must start with a 1-byte marker that indicates the input type of cp_info. The contents of the info sets vary with the marker value. Valid markers and their values are the same as those specified in the Red book. Each marker byte must be followed by two or more bytes that provide information regarding the specific constant. The format of the additional information varies with the marker value. Currently the only markers that require its inclusion are CONSTANT_Class, CONSTANT_FÍeldRef, CONSTANT ÍthodhodRef and CONSTANT_InterfaceRef. Support for other markers are added as they are included in the specification. CONSTANT Class The CONSTANT_Class_info structure is used to represent a class or an interface: CONSTANT_ClassInfo. { Ul tag; U2 name_index; } The elements of a CONSTANT_Class_info structure are the following: Marker The marker element has the value of CONSTANT_Class (7).

Name_index The value of the name_index element must represent a valid Java class name. The Java class name represented by name_index must be exactly the same as the Java class name described in the corresponding CONSTANT_Class entry in the CONSTANT_pool of the original class file. Fields, methods and interface methods of CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref are represented by simistructures: CONSTANT_FieldrefInfo. { Ul tag; U2 class_index; U2 name_sig_index; } CONSTANTJMethodrefInfo [Ul tag; U2 class_index; U2 name_sig_index; } CONSTANT_InterfaceMethodrefinfo. { Ul tag; U2 class_index; U2 name_sig_index; } The elements of these structures are the following: Marker The marker element is a structure of CONSTANT: fieldreflnfo has the value CONSTANT_Fieldref (9) The marker element of a CONSTANT_MethodrefInfo structure has the value CONSTANT_Methodref (10). The marker element of a structure CONSTANT_InterfaceMethodrefInfo has the value of CONSTANT_InterfaceMethodref (11). Class_index The value of the clas_index element must represent a class Valid Java or the interface name. The name represented by Class_index must be exactly the same name as the name described by the corresponding CONSTANT Class info entry in the constant pool of the original class file. Name_sig_index The value of the name_sig_index element must be represented by a valid Java name and type. The name and type represented by name_sig_index must be exactly the same name and the same type as described in the entry CONSTANT_NameAndType_Info in the constant_pool structure of the original class file. Class Each class is described by means of a ClassInfo structure of changing length. The format of this structure is: ClassInfo. { U2 name_index; Ul max_field; Ul max_sfield; Ul max_method; Ul max_interface; U2 superclass; U2 access_flags; Fieldlnfo field [max_field + max_sfield]; Interfacelnfo Interface [max_interface]: Methodlnfo method [max_method]; } The elements of the ClassInfo structure are the following: Ñame index The value of the name_index element must represent a valid Java class name. The Java class name represented by name_index must be exactly the same Java class name described in the corresponding ClassFile structure of the original class file. Max_fiel The value of the max_field element provides the structure number of Fieldlnfo () in the field table that represents the variables of the case, decd by this class or type of interface. This value refers to the number of non-static fields in the card class file. If the class represents an interface, the value of max_field is O. Max_sfield The value of the element max_sfield provides the structure number Fieldlnfo in the field table that represents the class variables, decd by this class or type of inrefaz. This value refers to the number of static fields in the card class file. Max_method The value of the max_method element as are the number of structures Methodlnfo () in the method table. Max-interface The value of the max_interface element provides the number of direct superinterfaces of this class or type of interface.

Superclass For a class, the value of the superclass element must represent a valid Java class name, the Java class name represented by the superclass must be exactly the same as the Java class name that is described in the corresponding ClassFile structure of the original class file. Neither surpassed nor any of its superclasses can be a final class. If the value of superclass 0, then this class must represent the Java class. lang. Object, the only class or interface without a superclass. For an interface, the value of the superclass must always represent the Java class. lang.Object. Acess_flags The value of the acces_flags element is a mask of modifiers used with class and interface declarations. The acess_flags modifiers and their values are the same as the acess_flags modifiers in the corresponding ClassFile structure of the original class file. Field Each value in the field table must be a fixed length structure Fiellnfo () that provides a complete description of a field in the class or type of interface. The field table includes only the fields declared by this class or interface. It does not include elements that represent fields inherited from superclasses or superinterfaces. Interface Each value in the set of interfaces must represent a valid interface name. The interface name represented by each entry must be exactly the same interface name described in the corresponding set of interfaces of the original class file. Method Each value in the method table must be a variable length structure Methodlnfo () that provides a complete description of a Java virtual machine code for a method in the class or interface. The Methodlnfo structures represent all the methods, both class methods and, for classes, class methods (static), declared by this class or interface type. The method table includes only the methods explicitly declared by this class. Imherfaces that have only one unique method <; clinit > the interface initialization method. The method table does not include elements that represent methods inherited from superclasses or superinterfaces. Fields Each field is described by means of a fixed length field_info structure. The format of this structure is FieldInfo. { U2 name_index; U2 signature_index; U2 access_flags; } the elements in the Fieldlnfo structure are the following: name_index The value of the name_index element must represent a valid Java field name. The Java field name represented by name_index must be exactly the same as the Java field name described in the corresponding field_info structure of the original class file. Signature_index The value of the signature_index element must represent a valid Java field descriptor. The Java field descriptor represented by signature_index must be exactly the same as the Java field descriptor described in the corresponding field_info structure of the original class file. Access_flags The value of the access_flags element is a modifier mask that is used to describe access permissions and properties of a field. The access_flags modifiers and their values are the same as the access_flags modifiers as the corresponding field_info structure of the original class file.

Methods Each method is described by means of a structure Variable length method. The Methodlnfo structure is a variable length structure that contains the instructions of the Java Virtual Machine and auxiliary information for a unique Java method, case initialization method, or class or interface initialization method.

The structure has the following format: U2 name_index; U2 signature_index; Ul max_local; Ul max_arg; Ul max_stack; Ul access_flags; U2 code_lengtj; U2 exception_length; Ul code [code_length]; . { u2 start_pc; u2 end_pc; u2 catch_type; } einfo [exception_length]; } The elements of the Methodlnfo structure are the following: Ñame index The value of the name_index element must represent either one of the special internal method names, or < init > or < clinit > or a valid Java method name. The Java method name represented by name_index must be exactly the same Java method name as described in the corresponding method_info structure of the original class file. Signature_index The value of the signature_index element must represent a valid Java method descriptor. The Java method descriptor represented by signature_index must be exactly the same Java method descriptor as the one described in the corresponding method_info structure of the original class file. Max_local The value of the max_local element provides the number of local variables used by this method, excluding the parameters passed to the method when an invocation is carried out. The index of the first local variable is 0. The largest local variable index for a value of a word is max_locals-l. Max_arg The value of the max_arg element provides the maximum number of arguments for this method. Max stack The value of the max_stack element provides the maximum number of words in the operand stack at any point during the execution of this method. Access_flags • The value of the access_flags element is a modification mask that is used to describe access permission and properties of a method or case initialization method. The access_flags modifiers and their values are the same as the access_flags modifiers as in the corresponding method_info structure of the original class file. Code_length The value of the code_length element provides the number of bytes in the code set for this method. The value of code_length must be greater than 0; the code set should not be empty. Exception_length The value of the exception_length element provides the number of entries in the exception_info table. Code The code array provides the actual number of bytes of the Java Virtual Machine code that implement the method. When the code array is read into memory in a steerable machine in bytes, if the first byte of the array is aligned within a 4-byte limit, the 32-bit offsets of tablewitch and lookupswitch will be aligned in 4 bytes; see the descriptions of these instructions for more information on the consequences of aligning code arrangements. The detailed limitations of the contents of the code arrangement are extensive and are the same as those described in the Java Virtual Machine Specification. Einfo Each entry in the arrangement einfo describes an exception handler in the code arrangement. Each einfo entry contains the following elements; start_pc, end_pc The values of these two elements start_pc and end_pc indicate the ranges in the code array in which the exception handler is active. The value of start_pc must be a valid index in the code array in the opcode of an instruction. The value of end_pc must be either a valid index in the code array of the opcode of an instruction or it must be equal to code_length, the length of the code arrangement. The value of start_pc must be less than the value of end_pc. The start_pc is inclusive and the end_pc is exclusive, that is, the exception handler must be active while the program counter is within the interval [start_pc, end_pc] Handlerjpc The value of the handlerjpc element indicates the start of the exception handler. The value of the element of being a valid index in the code array, must be the opcode index of an instruction, and must be less than the value of the code_length element. Catch_type If the value of the catch_type element is not 0, it must represent a valid Java class type. The type of Java class represented by catch_type must be exactly the same as the Java class type described by the catch_type in the corresponding method_info structure of the original class file. This class must be the Disposable class or one of its subclasses. The exception handler will intervene only if the thrown exception is a case of the given class or one of its subclasses. If the value of the catch_type element is zero, the exception handler will intervene for all exceptions. This is used to finally implement. Attributes The attributes used in the original class file are either deleted or regrouped for compaction. The predefined attributes SourceFile, ConstantValue, Exceptions, LineNumberTable, and Local-VariableTable can be selected without sacrificing any information required for the interpretation of Java byte code. The predefined Attribute Code that contains all the byte codes for a particular method are moved in the corresponding Methodlnfo structure. Limitations on the Java Virtual Machine Code The Java Virtual Machine code for a method, case initialization method, or class method or interface initialization is stored in the fix code of the Methodlnfo structure of a card class file. Both the static and structural limitations in this code arrangement are the same as those described in the Red book. Imitations of the Java Card Virtual Machine and the Java Card Class File Format. The following limitations regarding the Java Virtual Card Machine are imposed by this version of the Java Card Virtual Machine specification: The set of file class constants per card is limited to 65535 entries due to the const_size field of 16 bits of the structure of CardClassFile (). This acts as an internal limitation on the total complexity of a single card class file. This also includes the entries that correspond to the set of constants of the class hierarchy available for the application on the card.

The amount of code per method is limited to 65535 bytes due to the sizes of the indexes in the structure Methodlnfo. The number of local variables in a method is limited to 255 by the size of the max_local element of the structure Methodlnfo (). The number of fields in a class is limited to 510 by the size of the max_field and max_sfield elements of the ClassInfo () structure. The number of methods in a class is limited to 255 by the size of the max_method () element. The size of an operand stack is limited to 255 words by the max_stack field of the MethodInfo () structure. Bibliography (l) Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Addison-Wesley, 1996.

ANNEXES B Chain to ID entry and exit For the correct operation of the card JVM it is important that the declared and generated IDs are handled correctly. This handling is controlled by the definitions in the string to register ID file String-ID In ap. This textual file, whose base is shown below, declares which areas of the namespace can be used for what purposes. A possible fix of this map may reserve albunas IDs for internal use by the card JVM interpreter and the rest is assigned to card JVM applications. # / String-ID file Inmap # # 4000-7FFF available for application use # F000-FFFE reserved for internal use of card JVM # constantBase F000 # The area from F000 to FFFF is reserved # for internal use of card # JVM MainApplication # FOOO-name of start class # (changes for each application) Main () V # FOOl-name of start method # (can change for each application) Java / lang / Object # F002 Java / lang / String # F003 < init > () V # F004 < clinit > () V # F005 [L # F006 [I # F007 [C # F008 [B # F009 [S # F000A # constantBase FFFO # This area is reserved for simple return types L # FFFO V # FFF1 I # FFF2 S # FFF3 C # FFF4 B # FFF5 Z # FFF6 # constantBase 4000 # From now on this space depends on the application. Essentially, all applications loaded on a smart card receive their own IDs within 0x4000 to 0x7FFF. This space is free for each application since no loaded application is allowed to access other applications. Care must be taken to handle the IDs for preloaded class libraries. The handling of these IDs is facilitated by the generation (optional) of the string up to the ID output file, String-ID OUTMap file. This map is the INMap String-ID incremented with the new string-ID constructs. These links can be produced when the card class file convert application is terminated. The String-ID OUTMap is generated to support libraries and OS interfaces loaded on the card. This map can be used as the INMap String-ID for smart card applications that use the support libraries and OS interfaces loaded on the card. When new applications are built, this file can usually be undone. As an example we will consider the following Java program, HelloSmartCard.Java when compiled generated a HelloSmartCard class file. Class. This class file has integrated in the strings that represent the class name as methods and type information. Based on the INMap String-ID described above, the Card Class File Converter generates a card class file that replaces the strings present in the class file with IDs assigned by the Card Class File converter.

Table 1 presents a list of the strings found in the HelloSmartCard set of constants. class with their IDs assigned to the respective card class file converter. Note that some strings (such as "Java / lang / Object") have a reassigned value (F002) and some strings (such as < < () V ») have a new value (4004). Program: HelloSmartCard.Java Public class HelloSmartCard. { Public byte to variable; Static public cancels main (). { HelloSmartCardh = new HelloSmartCard (); h.aVariable = (byte) 13; } } Relevant String-ID OUTMap entries ANNEX C Byte codes supported by the card JVM in the preferred mode Standard Java byte code numbers for the supported byte codes in the preferred package useful mode; / * * List of Java bytecodes relays managed by this JVM * ref.Lindohim and Yellin.

* Copyright © 1996 Schlu berger Austin Products Center, • Schlumberger, Austin, Texas, USA. * / public interface BytecodeDefn. { public static end byte j_NOP = (byte) 0; public static end byte ACONST NULL = (byte) 1; public static end byte IC0NST_Ml = (byte) 2; public static end byte ICONST_0 = (byte) 3, public static end byte ICONST_l = (byte) 4J public static end byte ICONST_2 = (byte) 5; public static end byte ICONST_3 = (byte) 6 public static end byte IC0NST_4 = (byte) 7j public static end byte IC0NST_5 = (byte) 8, static public end byte BIPUSH = (byte) 16; static public final byte SIPUSH = (byte) 17; static final public byte LDCl = (byte) 18; static final public byte LDC2 = (byte) 19; public static final byte ILOAD = (byte) 21; public static final byte ALOAD = (byte) 25; static public final byte ILOAD_0 = (byte) 26; static public final byte ILOAD_l = (byte) 27; static public final byte IL0AD_2 = (byte) 28; public static end byte IL0AD_3 = (byte) 29; static public final byte ALOAD_0 = (byte) 42; static public final byte ALOAD_l = (byte) 43; static public final byte AL0AD_2 = (byte) 44; static public final byte AL0AD_3 = (byte) 45; public static final byte ILOAD = (byte) 46; static final public byte AALOAD = (byte) 50; public static final byte BALOAD = (byte) 51; static public final byte CALOAD = (byte) 52; static public final byte ISTORE = (byte) 54; public static final byte ASTORE = (byte) 58; static public final byte ISTORE_0 = (byte) 59; static public final byte ISTORE_l = (byte) 60; static public final byte ISTORE_2 = (byte) 61; public static end byte ISTORE_3 = (byte) 62; public static end byte ASTORE_0 = (byte) 75; static public final byte ASTORE_l = (byte) 76; static public final byte ASTORE_2 = (byte) 77; static public final byte ASTORE_3 = (byte) 78; static final public byte IASTORE = (byte) 79; final static byte public AASTORE = (byte) 83; public static end byte BASTORE = (byte) 84; public static final byte CASTORE = (byte) 85; static public end byte POP = (byte) 87; static public final byte P0P2 = (byte) 88; static final public byte DUP = (byte) 89; static final public byte DUP_Xl = (byte) 90; static public final byte DUP_X2 = (byte) 91; static final public byte DUP2 = (byte) 92; static public final byte DUP2_Xl = (byte) 93; static public final byte DUP2_X2 = (byte) 94; static final public byte SWAP = (byte) 95; static final public byte IADD = (byte) 96; public static final byte ISUB = (byte) 100; public static end byte IMUL = (byte) 104; public static final byte IDIV = (byte) 108; static public final byte IREM = (byte) 112; public static final byte INEG = (byte) 116; public static final byte ISHL = (byte) 120; public static final byte ISHR = (byte) 122; static final public byte IUSHR = (byte) 124; public static end byte IAND = (byte) 126; static public final byte IOR = (byte) 128; static final public byte IXOR = (byte) 130; final static byte public IINC = (byte) 132; static public final byte INT2BYTE = (byte) 145; final public static byte INT2CHAR = (byte) 146; static final public byte INT2SHORT = (byte) 147; public static final byte IFEQ = (byte) 153; public static final byte IFNE = (byte) 154; public static final byte IFLT = (byte) 155; static final public byte IFGE = (byte) 156; public static final byte IFGT = (byte) 157; public static final byte IFLE = (byte) 158; public static final byte IF_ICMPEQ = (byte) 159; final public static byte IF_ICMPNE = (byte) 160; public static end byte IF_ICMPLT = (byte) 161; public static end byte IF_ICMPGE = (byte) 162; public static end byte IF_ICMPGT = (byte) 163; public static end byte IF_ICMPLE = (byte) 164; static public final byte IF_ACMPEQ = (byte) 165; public static end byte IF_ACMPNE = (byte) 166; end static public toyote GOTO = (byte) 167; static public final byte j_JSR = (byte) 168; public static end byte RET = (byte) 169; static final public byte TABLESWITCH = (byte) 170; static public final byte LOODUPSWITCH = (byte) 171; static public final byte IRETURN = (byte) 172; public static final byte ARETURN = (byte) 176; static public end byte RETURN = (byte) 177; static public final byte GETSTATIC = (byte) 178; final public static byte PUTSTATIC = (byte) 179; static public final byte GETFIELD = (byte) 180; static final public byte PUTFIELD = (byte) 181; final public static byte INVOKEVIRTUAL = (byte) 182; final public static byte INVOKENONVIRTUAL = (byte) 183; public static end byte INVOKESTATIC = (byte) 184; public static end byte INVOKEINTERFACE = (byte) 185; public static final byte NEW = (byte) 187; static final public byte NE ARRAY = (byte) 188; public static end byte ARRAYLENGTH = (byte) 1 0; static public final byte ATHROW = (byte) 191; public static end byte CHECKCAST = (byte) 192; static final public byte INSTANCEOF = (byte) 193; public static end byte IFNULL = (byte) 198; static final public byte IFNONNULL = (byte) 199; } ANNEX D Card class file converter byte code conversion process / * * Reprocess code block * / static annular reproccessMethod (Method * imeth). { int pe; int npc; int align; bytecode * code; int codelen; int; int opad; int npad; int apc; int high; int low; / * codeinfo is a table that tracks the bytecodes Valid Java and its * corresponding offset * / code = imeth- > external- > code; codelen = imeth- > external- > code_length; jumpsPos = 0; aling = 0 / * Scan for unsupported opcodes * / for (pc = 0; pc <codelen; pc = npc). { if (codeinfo [code [pc]] .valid ==). { error ("Uncupported opcode% d", code [pe]); } npc = nextPC (pc, code); } / * Scans for jump instructions of an insert in the jump table * / for (pc = 0; pc <codelen; pc = npc). { npc = nextPC (pc, code); if (codeinfo [code [pc]]. valid == 3 { insertJump (pc + l, pc, (intl6) ((code [pc + l] «8) [code [pc + 2])); } else if (codeinfo [code [pc]] .valid == 4) { apc = pc &-4; low = (code [apc + 8] «24) | (code [apc + 9]« 16 ) | (code [apc + 10] «8) | code [apc + ll]; higt = (code [apc + 12]« 24) | (code [apc + 13] «16) | (code [apc + 14 ] «8) | code [apc + 15]; for (i = 0; i < high-low + l; i ++) { InsertJump (apc + (i * 4) + l8, pc, (intld) (( code [apc + (i * 4) +18] «8) | code [apc + (i * 4) +19]));.}. insertJump (apc + 6, ie, (intl6) ((code [apc + 6 ] «8) | code [apc + 7])); } else if (codeinfo [code [pc]] .valid == 5). { apc = pc &-4; low = (code [apc + 8] «24) | (code [apc + 9] «16) | (code [apc + 10] «8) | code [apc + ll]; for (i = 0; i <low; i ++). { insertJump (apc + (i * 8) +18, e, (intld) ((code [apc + (i * 8) +18 «8) | code [apc + (i * 8) +19])); } insert Jump (apc + 6, eg, (intl6) ((code [apc + 6] «8) | code [apc + 7])); } } # / fdef TRANSLATE_BYTECODE / * Translating specific opcodes to generlaes * / for (pe = 0; pc <codelen, pc = npc). { / * It is a translation code * / if (codeinfo [code [pc]] .valid == 2). { switch (code [pc]). { case ILOAD_0; case ILOAD_l case ILOAD_2 case ILOAD 3 insertSpace (code, dtcodelen, eg, 1); aling + = l; code [pc + l] = code [pc] - ILOAD_0; code [pc + O] = ILOAD; pitch; case ALOAD_0: case AL0AD_1: case AL0AD_2: case ALOAD_3: insertSpace (code, Scodelen, eg, 1); aling + = l: code [pc + 1] = code [pe] -ALOAD_0; code [pc + O] = ALOAD; pitch; case ISTORE_0¡ case ISTORE_lj case ISTORE_2¡ case ISTORE_3, insertSpace (code, &codelen, eg, 1); aling + = l: code [pc + 1] = code [pe] -ISTORE_0; code [pc + O] = ISTORE; break; ASTORE_0 case; ASTORE 1 case; case AST0RE_2; case AST0RE_3; insertSpace (code, dcodelen, pe, 1); aling + = l: code [pc + l] = code [pc] -ASTORE_0; cod [pc + O] = ASTORE; pitch; case | C0NST_M1: insertSpace (code, &codelen, eg, 2); aling + = 2: code [pc + 2] = 255; code [pc + 1] = 255; cod [pc + O] = SIPUSH; break; case | CONST_0j case | CONST_lj case | CONST_2, case | CONST_3 case | CONST_4, case | CONST_5; insertSpace (code, Scodelen, pe, 2); aling + = 2: code [pc + 2] = Code [pe] - | CONST_0; code [pc + l] = 0; code [pc + O] = SIPUSH; break; case LDC1; insertSpace (code, &codelen, pe, 1); aling + = l: code [pc + l] = 0; code [pc + O] = LDC2; break; BIPUSH case; insertSpace (code, Scodelen, pe, 1); aling + = l: if ((int8) code [pc + 2] > = 0). { code [pc + l] = 0; } else { code [pc + l] = 255; } code [pc + O] = SIPUSH; break; INT2SHORT case; removeSpace (code, Scodelen, pe, 1); aling + = l: npc = pc; I continued; } } else if (codeinfo [code [pc]]. valid == 4 ° j | codeinfo [code [pc]] .valid == 5)} / * The switches are aligned in 4-byte limits. Since inserting and removing bytecodes, this can combine the alignment of switching instructions. Therefore we must readjust the filling in the switches to compensate. * / opad = (4- (((pc + l) -align)% 4))% 4; / * Current switch padding * / npad = (4 - ((pc + l)% 4))% 4; / * New switch padding * / if (npad> opad). { insertSpace (code, dcodelen, pc + l, npad-opad); aling + = (npad-opad):} else if (npad < opad). { removeSpace (code, &codelen, pc + l, opad-npad); aling - = (opad-npad); } } npc = nextPC (pc, code); } #endif / * rejoin constants * / for (pc = 0; pc <codelen; pe = npc). { npc = nextPC (pc, code); i = (unitl6) ((code [pc + l] «8) + code [pc + 2]); switch (code [pe]). { case LDC2; / * i == general index * / switch (citem (i) .type). { case CONSTANT_integer; i = citem (i) .v.tint; code [pc] = SIPUSH; break; case CONSTANT_String; i = buiistringlndex (i); break; default; error ("Unsupported loading of constant type"); break; } break; NEW case; INTANCEOF case; CHECKCAST case; / • * «i» == class index * / i = buildClassIndex (i); break; GETFIELD case; PUTFIELD case; / * «I» == field index * / / * i = builFieldSignatureIndex (i); * / i = buildStaticFieldSignatureIndex (i); break; GETSTATIC case; PUTSTATIC case; / * «I» == field index * / i = buildStaticFieldSignatureIndex (i); break; INVOKEVIRTUAL case; INVOKENONVIRTUAL case; INVOKESTATIC case; INVOKEINTERFACE case; / * «I» == method signature index * / i = buildsignaturelndex (i) break; } / * insert reference of application constants * / code [pc + 1] = (i »8) &0xFF; code [pc + 2] = i &0xFF; } #ifdefMODIFY_BYTECODE / * translate codes * / for (pc = 0; pc <eodelen; pc = npe). { npc = nextPC (pc, code); code [pc] = codeinfo [code [pc]] .translation; } #endeif / * re-link jumps * / for (i = 0; i < jumpPos; i ++). { apc = jumpTable (i). at; pc = jumpTable (i) .from; npc = jumpTable (i) .to-pc; code [apc + 0] - (npc »8) &0xFF; code [apc + 1] = npc & 0xFF; } / * Fixed length * / imeth- > external- > code_length = codelen; imeth- > esize = (SIZE0FMETH0D + codelen + 3) &-4; } ANNEX E Example of load control and execution program.

Public class Bootstrap. { // Constants used in the whole program static final byte BUFFER: LENGTH = 32; static end byte ACK_SIZE = (byte) l; static end byte ACK_CODE = (byte) O; static end byte OS_HEADER_SIZE = (byte) 0x10; static end byte GPOS_CREATE_FILE = (byte) OXeO; static end byte ST_INVALID_CLASS = (byte) OXCO; static end byte ST_INVALID_PARAMETER = (byte) OXAO; static end byte ST_INS_NOT_SUPPORTED = (byte) OXBO; static end byte ST_SUCCESS = (byte) 0X00; static end byte ISO_COMMAND_LENGTH = (byte) 5; static end byte ISO_READ_BINARY = (byte) OXBO; static end byte ISO_UPDATE_BINARY = (byte) 0XD6; static end byte ISO_INIT_APPLICATION = (byte) 0XF2; static end byte ISO_VERIFY_KEY = (byte) 0X2A; static end byte ISO_SELECT_FILE = (byte) 0XA4; static end byte ISO_CLASS = (byte) OXCO; static end byte ISO_APP_CLASS = (byte) OXFO; static main public annular (). { byte pbuffer [] = new byte [ISO_COMMAND_LENGTH]; byte dbuffer [] = new byte [BUFFER_LEGTH]; byte ackByte [] = new byte [ACK SIZE]; //short field; short compensation; bytebReturnStatus; // Initialize communications _OS.SendATR (); do. { // Retrieve the command header OS.GetMessage (pbuffer, ISO_COMMAND_LENGTH, ACK_CODE); // Verify message class-only ISO + application if ((pbuffer [0] 1 = ISO_APP_CLASS) & (pbuffer [0]! = ISO_CLASS)). { YOU. SendStatuS (ST_INVALID_CLASS); } else { // pass through the switch // send the recognition code // check if the length of the data is large if (pbuffer [4] > BUFFER_LENGTH). { bReturnStatus = ST_INVALID_PARAMETER; } else { switch (pbuffer [1]). { ISO_SELECT_FILE case; // we always consider that the length is 2 if (pbuffer [4]! = 2). { bReturnStatus = ST_INVALID_PARAMETER; } else { // get the fileld (displaced) in the data buffer _OS-GetMessage (dbuffer, (byte) 2, pbuffer [l]); // send dbuffer [0..1] at a short offset = (short) ((debuffer [0] «8) | (dbuffer [l] & 0x00FF)); bReturnStatus = _OS. SelectFile (offset); } break; ISO_VERIFY_KEY case; // get the terminal key _OS.GetMessage (dbuffer, pbuffer [4], pbuffer [l]); bReturnStatus = _OS.VerifyKey (pbuffer [3], dbuffer, pbuffer [4]); break; case ISO_INIT_APPLICATION; // You should send the id of a valid OS program file: GetMessage (dbuffer, (byte) l, pbuffer [l]); // calculate field (displaced) from pbuffer [2..3] through the sending offset = (short) ((pbuffer [2] «8) | (pbuffer [3] &0x00FF)); bReturnStatus = _0S: Execute (offset, debuffer [0]); break; case GPOS_CREATE_FILE; if (pbuffer [4]! = OS_HEADER_SIZE). { bReturnStatus = ST_INVALID_PARAMETER; break; } // Receive OS data: GetMessage (dbuffer, pbuffer [4], pbuffer [l]); BReturnStatus = _OS. CreateFile (dbuffer); Break; Case ISO_UPDATE_BINARY; _0S. GetMessage (dbuffer, pbuffer [4], pbuffer [1]); // calculate displacement of pbuffer [2..3] through conversion offeset = (short) ((pbuffer [2] «8) | (pbuffer [3] & 0X00FF)); // considering that a file has already been selected hReturnStatus = _OS.WriteBinaryFile (offset, pbuffer [4], dbuffer); break; ISO_READ_BINARY case; // calculate displacement of pbuffer [2..3] through conversion offeset = (short) ((pbuffer [2] «8) | (pbuffer [3] &0x00FF)); // considering that a file has already been selected bReturnStatus = _OS.ReadBinaryFile (offeset, pbuffer [4], dbuffer); // considering that a file has already been selected ackByte [0] = pbuf f er [1]; if (bReturnStatus == ST_SUCCESS). { _OS. SendMessage (ackByte, ACK_SiZE); _OS. SendMessage (dbuffer, pbuf fer [4]); } break; default; bReturnStatus = ST_INS_NOT_SUPPORTED; } } _ O < S. SendStatus (bReturnStatus)} } while (true); } } ANNEX F Methods for accessing card operating system capabilities in the preferred mode. Public class _OS. { native static byte SelectFile (short file_id); static native byte SelectParent (); static native byte SelectCD (); static native byte SelectRoot (); static native byte CreateFile (byte file_hdr []); static native byte DeleteFile (short file_id); // General manipulation of static native byte file ResetFile (); static native byte ReadByte (byte offset); static native short ReadWord (byte offset); // Header manipulation static native byte GetFileinfo (byte file_hdr []); // binary file support static native byte ReadBinaryFile (short offset, byte data_length, byte buffer []); static native byte WriteBinaryFile (short offset, byte data_length, byte buffer []); // support registered support file static native byte SelectRecord (byte record_nb, byte mode); static native byte NextRecord (); static native byte PreviousRecord (); static native byte ReadRecord (byte recor_data [], byte record_nb, byte offset, byte length); static native byte WriteRecord (byte buffer [], byte recor_nb, byte offset, byte length); // Cyclic file support static native byte LastUpdatedRec (); // Message sending functions static native byte GetMessage (byte buffer [], byte expected_length, byte ack_code); static native byte SendMessage (byte byffer [], byte data_length); static native byte SetSpeed (byte speed); // Identity handling static native byte CheckAcces (byte ac_action); static native byte Verifykey (byte key_number, byte key_buffer [], byte key_length); static native byte VerifyCHV (byte CHV_number, byte CHV_buffer [], byte unblock_flag); static native byte ModifyCHV (byte CHV_number, byte oíd CHV_buffer []. Byte new_CHV_buffer [], byte unblock_flag); static native byte GetFileStatus (); static native byte SetFileStatus (byte file_status); static native byte GrantSupervisorMode (); static native byte RevokeSupervisorMode (); static native byte SetFileACL (byte file_acl []); static native byte GetFileACL (byte file_acl []); // static native empty file context manipulation InitFileStatus (); static native empty BackupFileStatus (); static native empty RestoreFileStatus (); // Utilities byte static native CompareBuffer (byte pattern_length, byte buffer_l [], byte buffer_2 []); static native byte dRecord (byte recor_data [], byte variable static native integer AvailableMemor (); static native empty ResetCard (byte mode); static native byte SendATR (); static native byte SetDefaultATR (byte buffer [], byte length); byte static native Execute (short file_id, byte flag); // global state variable functions static native byte Getldentity (); static native byte GetRecordNb (); static native integer variable GetApplicationld; static native byte GetRecordLegth (); static native integer variable GetFileType (); static native empty GetFileLength (state of bytes); } ANNEX G Attribute byte code tables Division of Java byte code into type groups Each bytecode receives a 5-bit type associated with it. This is used to group the codes into sets of similar behavior. In general, this behavior reflects how the types of byte codes operate on the stack, but types 0, 13, 14, and 15 reflect specific types of instructions in accordance with what is stated in the comments section. The following table illustrates the state of the battery before and after the execution of each one or instructions.

The use of a standard Java byte code (without reordering) - attribute search table / * * The bytecode table decodes information. It has a bytecode type and a bytecode length. We currently support all standard bytecode (that is, not fast) that provide codes from 0 to 201 (202 codes in total). * / #define T_ 0 #define T3 1 #define T6 2 / define IT 3 / define T2 4 / define T7 5 / define T9 6 / define T8 7 / define T12 8 / define UNCLE 9 / define T5 10 / define TIL 11 / define T16 12 / define T4 13 / define T13 14 / define T14 15 / define T15 16 / define D (T, L) 0 (14, i. >, / * NOP * / D (Til / 1), / * ACONST_NULL * / D (UNCLE / 1) r / * IC0NST_M1 * / D (UNCLE / 1), / * IC0NST_ 0 * / D (UNCLE 1 1), / * ICONST_l * / D (UNCLE 1 1), / * ICONST_2 * / D (UNCLE 1 1), / * ICONST_3 * / D (UNCLE 1 1), / * ICONST_4 * / DI UNCLE, 1), / * ICONST 5 Di t_, 1) DI T_, 1) D | T_, 1) DI T_, 1) DI T_, 1) Say T_, 1) DI T_, 1) Say UNCLE, 2), / * BIPUSH * / DI UNCLE, 3), / * BIPUSH * / DI T_, 2 ), / * LDCl * / DI Til, 3), / * LDC2 * / Di T, 3 Di T5 2 / * ILOAD * / DI T_ 2 D | T_ 2 D | T_ 2 Di T5 2 / * ALOAD * / D | T5 1 / * ILOAD_0 * / DI T5 1 / * ILOAD_l * / DI T5 1 / * ILOAD_2 * / D | T5 1 / * ILOAD 3 D | T_ 1 Di T_ 1 DI T 1 / * ALOAD_0 * / / * ALOAD_l * / / * ALOAD_2 * / / * ALOAD_3 * / / * ILOAD * / / * AALOAD * / / * BALOAD * / / * CALOAD * / / * S ALOAD * / / * ISTORE * / / * ASTORE * / / * ISTORE_0 * / / * ISTORE_l * / / * ISTORE_2 * / / * I STORE 3 * / / * ASTORE_0 * / / * ASTORE_l * / / * ASTORE_2 * / / * ASTORE_3 * / / * LASAST * / D (T_, 1) / / * AASTORE * / D (T6, i), / * BASTORE * / D (T_, i), / * CASTORE * / D (T6, i), / * SASTORE * / D (T2, i), / * POP * / D (T3, i), / * POP2 * / D (T13 / 1) / * DUP * / D (T13,) / * DUP_X1 * / D (T13.1) / * DUP_X2 * / D (T13.i), / * DUP2 * / D T13,). / * DUP2_X1 * / D [T13, i), / * DUP2_X2 * / D [T13 / i), / * SWAP * / D r T1 t i) / / * IADD * / D '_ f i) Di' _, 1), DI TI r) / D (T_ r 1) / / * ISUB * / D (t_ r 1), D (t_ i), D (t_, 1) / D (t?, 1) / / * IMUL * / D (t_, 1) f D (t_, 1) / D (t_, 1) / / * IDIV / * IREM / * INEG / * ISHL / * ISHR / * IUSHR * / / * IAND / * IOR / * IXOR * / / * IINC D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T9 1 / * INT2BYTE * / D (T9 1 / * INT2CHAR * / D (T_ 1 / * INT2SHORT * / D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T_ 1 D (T2 3 / * IFEQ * / D (T2 3 / * IFNE * / D (T2 3 / * IFLT * / D (T2 3 / * IFGE * / D (T2 3 / * IFGT * / D (T2, 3), / * IFLT * / D (T3, 3), / * IF_ICMPEQ * / D (T3, 3), / * IF_ICMPNE * / D (T3, 3), / * IF_ICMPLT * / D (T3, 3), / * IF_ICMPGE * / D (T3, 3), / * IF_ICMPGT * / D (T3, 3), / * IF_ICMPLE * / D (T3, 3), / * IF_ACMPEQ * / D (T4, 3), / * GOTO * / D (T_, 3), / * JSR * / D (T_, 2), / * RET * / D (T2, 0), / * TABLESWITCH * / D (T2, 0), / * LOOKUPSWITCH * / D (T2, 1), / * IRETURN * / D (T_, 1), D (T_, 1), D (T8, 1), / * ARETURN * / D (T4, 1), / * RETURN * * / D (T15, 3), / * GETSTATIC * / D (T15, 3), / * PUTSTATIC * / D (T15, 3), / * GETFIELD * / D (T15, 3), / * PUTFIELD * / D (T14, 3), / * INVOKEVIRTUAL * / D (T14, 3), / * INVOKESPECIAL * / D (T14, 3), / * INVOKESTATIC * / D (T14, 5), / * INVOKEINTERFACE * / D (T_, i), D (Til, 3), / * NEW * / D (T16, 2), / * NEWARRAY * / D (T_, 3), D (T12, 1), / * ARRAYLENGTH * / D (T8,), / * ATHROW * / D (T16, 3), / * CHECKCAST * / D (T12, 3), / * INSTANCEOF * / D (T_, i), D (T_, i), D (T_, i), D (T_, 4), D (T8, 3), / * IFNULL * / D (T8 r 3), / * IFNONNULL D (T_ - 5), D (T_, 5), D (T_ fi). D (T_, 1), D (T_ (i), D (T_, i), D (T_, i), D (T_, i), D (T_, i), D (T_, i), 10 fifteen twenty ANNEX H Revisions made in Java byte codes by type Decoding instructions. This gives us the length to generate the next PC, and the instruction type Pcargl = GET_ILENGTH (_decodeinfo [insn]); Itype = GETITYPE (_decodeinfo [insn.]. Implement some pre-execution revisions based on / * check the status of input stack based on the type of instruction * / if (itype <= ITYPE9) { (itype < = ITYPE1) { check_stack_int (1);.}. check_stack_int_ (0);.}. else if (itype < = ITYPE12) { check_stack_ref (0);.}. else if (itype < = ITYPE11) { pusch (l);.}. Finally, implement some revisions after execution / - Set the exit status * / if (itype < = ITYPE8) { if (itype < = ITYPE6) { If (itype > = ITYPE6) { Pop (l);.}. Pop (l);.}. Pop (l):.}. Else if (itype < = ITYPE10) {set_stack_int (0);.}. else if (itype > = ITYPE11 & itype < = ITYPE16) { set_stack_ref (0);.}.

ANNEX I Revisions made in renumbered Java byte codes Obtain instructions. The numerical value of the instruction implicitly contains the instruction type insn = getpc (-l); implement some pre-execution checks based on the following: / * * revice the input stack status By renumbering byte codes we can carry out the necessary security checks by testing if the value of the byte code (and by consequently the byte code) belongs to the correct group * / if (insn < = TYPE9_END). { if (insn < = TYPE1_END). { check_stack_int (1); } check_stack_int (0); } else if (insn < = TYPE12_END). { check_stack_ref (0); } else if (insn < = TYPE11 END). { push (1)} Finally, implement some revisions after execution / * • stable output stack status. * / if (insn < = TYPE8_END). { if (insn < = TYPE6_END). { if (insn > = TYPE6_START). { pop (l); } pop (l); } pop (l); } else if (insn < = TYPE10_END). { set_stack_int (0); } else if (insn > = TYPE11_START & insn < = TYPE16_END). { set_stack_ref (0); } Reordering of supported Java byte codes by type / * TYPE 3 * / / define s_POP2 O / define s_IF_ICMPEQ 1 / define s_IF_ICMPNE 2 / define s_IF_ICMPLT 3 / define s_IF_ICMPGE 4 / define s_IF_ICMPGT 5 / define s_IF_ICMPLE 6 / define s_IF_ACMPEQ 7 / define s_IF_ACMPNE 8 / * TYPE 6 * / / define TYPE6_START 9 / define s__SASTORE 9 / define s_AASTORE 10 / define s_BASTORE ll / define TYPE6_END 12 / * type 1 * / / define s_IADD 13 / define s__ISUB 14 / define s_IMUL 15 / define s_IDIV 16 / define s_IREM 17 / define s_ISHL 18 / define s_ISHR 19 / define s_IUSHR 20 / define s IAND 21 / define s_IOR 22 / define s_IXOR 23 / define TYPE1_END 23 / * TYPE 2 * / / define s_ISTORE 24 / define s_POP 25 / define s_IFEQ 26 / define s_IFNE 27 / define s_IFLT 28 / define s_IFGE 29 / define s_IFGT 30 / define s_IFLE 31 / define s TABLESWITCH 32 / define s_LOOKUPSWITCH 33 / define s_IRETURN 34 / * TYPE 7 * / / define s_SALOAD 35 / define s_AALOAD 36 / define s_BALOAD 37 / * TYPE 9 * / / define s_INEG 39 / define s_INT2BYTE 40 / define s_INT2CHAR 41 / define TYPE9_END 41 / * TYPE 8 * / / define s_ASTORE 42 / define s_ARETURN 43 / define s_ATHROW 44 / define s_IFNULL 45 / define s_IFNONNULL 46 / define TYPE8_ END 46 / * TYPE 12 * / / define s_ARRAYLENGTH 47 / define s_INSTANCEOF 48 / define TYPE12_END 48 / * TYPE 10 * / / define s_SIPUSH 49 / define TYPE10_END 49 / * TYPE 5 * / / define s_IL? AD 50 / define s_ALOAD 51 / * TYPE 11 * / / define TYPE11_START 52 / define s_ACONST_NULL 52 / define s_LDC2 53 / define s_JRS 54 / define s_NEW 55 / define TYPE11_END 55 / * TYPE 16 * / / define s NEWARRAY 56 / define s_CHECKCAST 57 / define TYPE16_END 57 / * TYPE 13 * / / define s_DUP 58 / define s_DUP_Xl 59 / define s_DUP_X2 60 / define s_DUP2 61 / define s_DUP2_Xl 62 / define s_DUP2_X2 63 / define s_SWAP 64 / * TYPE 14 * / / define s_INVOKEVIRTUAL 65 / * 01000001 * / / define S_INVOKENONVIRTUAL 66 / * 01000010 * / / define s_INVOKESTATIC 67 / * 01000011 * / / define s_INVOKEINTERFACE 68 / * 01000100 * / / * TYPE 15 * / / define s_GETSTATIC 69 / define s_PUTSTATIC 70 / define s_GETFIELD 71 / define s_PUTFIELD 72 / * TYPE 4 * / / define s_NOP 73 / define s_IINC 74 / define s_GOTO 75 / define s RET 76 / define s RETURN 77

Claims (105)

1. CLAIMS. 1. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory that stores: an application that has a high-level programming language format, an interpreter; a processor coupled to the memory, the processor is configured to use the interpreter to interpret the application for excitation and to use the communicator to communicate with the terminal.
2. 2. The integrated circuit card of claim 1, wherein the high-level programming language format comprises a class file format.
3. 3. The integrated circuit card of claim 1 wherein the processing comprises a microcontroller.
4. 4. The integrated circuit card of claim 1, wherein at least a portion of the memory is located in the processor.
5. 5. The integrated circuit card of claim 1 wherein the high-level programming language format comprises a Java programming language format.
6. 6. The integrated circuit card of claim 1, wherein the application has been processed from a second application having a character string, the character string is represented in the first application by means of an identifier.
7. 7. The integrated circuit card of claim 6, wherein the identifier comprises an integer.
8. 8. The integrated circuit card of claim 1 wherein the processor is further configured to: receive a request from an applicant that requires access to an element of the card; after receiving the request, interact with the applicant to authenticate an identity of the applicant; based on identity, selectively grant access to the element.
9. 9. An integrated circuit card of claim 8, wherein the applicant comprises the processor.
10. 10. An integrated circuit card of claim 8, wherein the applicant comprises the terminal.
11. 11. The integrated circuit card of claim 8, wherein the element comprises the application stored in the memory, once access is allowed, the requester is configured to use the application.
12. 12. The integrated circuit card of claim 8, wherein the element comprises another application stored in the memory.
13. 13. The integrated circuit card of claim 8, wherein the element includes data stored in the memory.
14. 14. The integrated circuit card of claim 8, wherein the element comprises the communicator.
15. 15. The integrated circuit card of claim 8, wherein the memory also stores an access control list for the item, the access control list provides an indication of the types of access to be granted to the identity, the processor is It also configures to: based on the access control list, selectively grant specific types of access to the applicant.
16. 16. An integrated circuit card according to claim 15, wherein the types of access include reading data.
17. 17. The integrated circuit card of claim 15 wherein the types of access include data writing.
18. 18. The integrated circuit card of claim 15 wherein the types of access include the data annex.
19. 19. The integrated circuit card of claim 15 wherein the types of access include the creation of data.
20. 20. The integrated circuit card of claim 15 wherein the types of access include data removal.
21. 21. The integrated circuit card of claim 15 wherein the types of access include the execution of an application.
22. 22. The integrated circuit card of claim 1, wherein the application is one of several applications stored in memory, the processor is further configured to: receive a request from an applicant to access one of several applications; after receiving the request, to terminate if said application complies with a predetermined set of rules; based on the determination, selectively grant access to the applicant to said one of the plurality of applications.
23. 23. The integrated circuit card of claim 22, wherein the predetermined rules provide a guide for determining whether said application has access to a predetermined region of the memory.
24. 24. The integrated circuit card of claim 22, wherein the processor is further configured to: authenticate an identity of the requester; grant access to said application based on identity.
25. 25. The integrated circuit card of claim 1, wherein the processor is further configured to: interact with the terminal through the communicator to authenticate an identity; determine if the identity has been authenticated; based on the determination, selectively allow communication between the terminal and the integrated circuit card.
26. 26. The integrated circuit card of the claim 25, where the communicator and the terminal communicate through communication channels. The processor is further configured to assimilate one of the communication channels to the identity when the processor allows communication between the terminal and the integrated circuit card.
27. 27. The integrated circuit card of the claim 26, wherein the processor is further configured to: assign a session key to said communication channel, use the session key when the processor and the terminal communicate through said communication channel.
28. 28. The integrated circuit card of claim 1, wherein the terminal has a card reader and the communicator comprises a contact to communicate with the card reader.
29. 29. The integrated circuit card of claim 1, wherein the terminal has a wireless communication device and the communicator a wireless transceiver for communicating with the wireless communication device.
30. 30. The integrated circuit card of claim 1, wherein the terminal has a wireless communication device and the communicator comprises a wireless transmitter for communication with the wireless communication device.
31. 31. A method for use with an integrated circuit card and a terminal, comprising: storing an interpreter and an application having a high-level programming language format in a memory of the integrated circuit card; the use of an integrated circuit card processor uses the interpreter to interpret the application for execution; the use of a card communicator when communicating between the processor and the processor.
32. 32. The method of claim 31, wherein the high-level programming language format comprises a class file format.
33. 33. The method of claim 31, wherein the processor comprises a microcontroller.
34. 34. The method of claim 31, wherein at least a portion of the memory is located in the processor.
35. 35. The method of claim 31, wherein the high-level programming language format comprises a Java programming language format
36. 36. The method of claim 1, wherein the request has been processed from a second application that has a string of characters, further comprising: the representation of the character string in the first application by an identifier
37. 37. The method of claim 36, wherein the identifier includes an integer.
38. 38. The method of claim 31, further comprising: receiving a request from an applicant to access an element of the card; After the receipt of the request, interaction with the applicant to authenticate an identity of the applicant; Based on identity, it selectively grants access to the element.
39. 39. The method of claim 38, wherein the applicant comprises the processor.
40. 40. The method of claim 38, wherein the applicant comprises the terminal.
41. 41. The method of claim 38, wherein the element comprises the application stored in the memory, which also includes: once the access is allowed, the course of the application with the applicant.
42. 42. The method of claim 38, wherein the element comprises another application stored in the memory.
43. 43. The method of claim 38, wherein the element includes data stored in the memory.
44. 44. The method of claim 38, wherein the element comprises the communicator.
45. 45. The method of claim 38, wherein the memory also stores an access control list for the item, the access control list provides an indication of the type of access to be granted to the identity, which further comprises: based on the access control list, using the processor to selectively grant specific types of access to the requestor.
46. 46. The method of claim 45, wherein the access types include data reading.
47. 47. The method of claim 45, wherein the access types include data writing.
48. 48. The method of claim 45, wherein the types of access include the data annex.
49. 49. The method of claim 45, wherein the types of access include data creation.
50. 50. The method of claim 45, wherein the types of access include data removal.
51. 51. The method of claim 31, wherein the application is one of several applications stored in the memory, further comprising: receiving a request from an applicant to access one of the applications stored in the memory; upon receiving the request, determine whether said application among several applications complies with a predetermined set of rules; based on the determination, selectively grant access to said application among several applications.
52. 52. The method of claim 45, wherein the types of access include the execution of an application.
53. 53. The method of claim 52, wherein the predetermined rules provide a guide for determining whether said application among said various applications has access to a predetermined region of the memory.
54. The method of claim 52, further comprising: authenticating an identity of the requester; based on identity, grant access to said application among several applications.
55. 55. The method of claim 31, further comprising: communicating with the terminal to authenticate an identity; determine if the identity has been authenticated; based on the determination, selectively allow communication between the terminal and the integrated circuit card.
56. 56. The method of claim 55, further comprising: communicating between the terminal and the processor through communication channels; the assignment of one of the communication channels to the identity when communication between the card reader and the integrated circuit card is allowed.
57. 57. The method of claim 56, further comprising: assigning a session key to one of the communication channels; and the use of the session key when the processor and the terminal communicate through one of the communication channels.
58. 58. A smart card comprising: a memory that stores a Java interpreter; a processor configured to use the interpreter to interpret a Java application for execution.
59. 59. A microcontroller comprising: a semiconductor substrate; a memory located on the substrate; a programming language interpreter stored in memory and configured to implement security checks; a central processing unit located on the substrate and connected to the memory.
60. 60. The microcontroller of claim 59, wherein the interpreter comprises a Java byte code interpreter.
61. 61. The microcontroller of claim 59, wherein the security patches comprise firewall establishment.
62. 62. The microcontroller of claim 59, wherein the security checks comprise the application of a sandbox security model.
63. 63. A smart card comprising: a memory; a programming language interpreter stored in memory and configured to implement security checks; a central processing unit connected to memory.
64. 64. The smart card of claim 63, wherein the interpreter comprises a byte code interpreter of Java.
65. 65. The smart card of claim 63, wherein the security checks comprise the establishment of firewalls.
66. 66. The smart card of claim 63, wherein the security checks comprise the application of a sandbox security model.
67. 67. An integrated circuit card for use with a terminal, comprising: a communicator; a memory that stores an interpreter and first instructions of a first application, the first instructions have been converted from according to the instructions of a second application; a processor coupled to the memory and configured to use the interpreter to execute the first instructions and to communicate with the terminal through the communicator.
68. 68. An integrated circuit card of claim 67, wherein the first application has a class file format.
69. 69. The integrated circuit card of claim 67, wherein the second application has a class file format.
70. 70. The integrated circuit card of claim 67, wherein the first instructions comprise byte codes.
71. 71. The integrated circuit card of claim 67, wherein the second instructions comprise byte codes.
72. 72. The integrated circuit card of claim 67, wherein the first instructions comprise Java byte codes.
73. 73. The integrated circuit card of claim 67. Where the second instructions comprise Java byte codes.
74. 74. The integrated circuit card of claim 67, wherein the first instructions comprise generalized versions of the second instructions.
75. 75. The integrated circuit card of claim 67, wherein the first instructions comprise renumbered versions of the second instructions.
76. 76. The integrated circuit card of claim 67, wherein the second instructions include constant references, and the first instructions include constants that replace the constant references of the second instructions.
77. 77. The integrated circuit card of claim 67, where the second instructions include references, the references change location during the conversion of the second instructions to the first instructions, and the first instructions are re-linked with the references after the displacement.
78. 78. The integrated circuit card of claim 67, wherein the first instructions comprise byte codes for a first type of virtual machine, and the second instructions comprise byte codes for a second type of virtual machine, the first type is different from the second type.
79. 79. A method for use with an integrated circuit card, comprising: converting the second instructions of a second application into first instructions of a first application; storing the first instructions in a memory of the integrated circuit card; and the use of an integrated circuit card interpreter to execute the first instructions.
80. 80. The method of claim 79, wherein the first application has a class file format.
81. 81. The method of claim 79, wherein the second application has a class file format.
82. 82. The method of claim 79, wherein the first instructions comprise byte codes.
83. 83. The method of claim 79, wherein the second instructions comprise byte codes.
84. 84. The method of claim 79, wherein the first instructions comprise Java byte codes.
85. 85. The method of claim 79, wherein the second instructions comprise Java byte codes.
86. 86. The method of claim 79, wherein the first instructions are generalized versions of the second instructions.
87. 87. The method of claim 79, wherein the conversion includes the renumbering of the second instructions to form the first instructions.
88. 88. The method of claim 79, wherein the second instructions include constant references, and the conversion includes the replacement of the constant references of the second instructions with constants.
89. 89. The method of claim 79, wherein the second instructions include references and the conversion includes the change of location of the references, which further comprises: the re-link of the first instructions to the references after the conversion.
90. 90. The method of claim 79, wherein the first instructions comprise byte codes for a first type of virtual machine, and the second instructions comprise byte codes for a second type of virtual machine, the first type is different from the second type.
91. 91. An integrated circuit for use with a terminal comprising: a communicator configured to communicate with the terminal; a memory that stores a first application that has been processed from a second application that has a character string, the character string is represented in the first application by means of an identifier; a processor connected to the memory, the processor is configured to use the interpreter to interpret the first application for execution and to use the communicator to communicate with the terminal.
92. 92. The integrated circuit card of claim 91, wherein the identifier comprises an integer.
93. 93. A method for use with an integrated circuit card and a terminal, comprising: processing a second application to create a first application, the second application has a character string; the representation of the character string of the first application by an identifier in the second application; the storage of an interpreter and the first application in a memory of the integrated circuit card; and the use of an integrated circuit card processor to use an interpreter to interpret the first application for execution.
94. 94. The method of claim 93, wherein the identifier includes an integer.
95. 95. A microcontroller comprising: a memory that stores: an application that has a class file format, an interpreter; and a processor connected to the memory the processor is configured to use the interpreter to interpret the application for execution.
96. 96. The microcontroller of claim 95, further comprising: a communicator configured to communicate with a terminal.
97. 97. The microcontroller of claim 96, wherein the terminal has a card reader and the communicator comprises a contact to communicate with the card reader.
98. 98. The microcontroller of claim 96, wherein the terminal has a wireless communication device and the communicator a wireless transsector to communicate with the wireless communication device.
99. 99. The microcontroller of claim 96, wherein the terminal has a wireless communication device and the communicator comprises a wireless transmitter for communicating with the wireless communication device.
100. 100. The microcontroller of claim 95, wherein the class file format comprises a Java class file format.
101. 101. A method for use with an integrated circuit card, comprising: storing a first application in a memory of the integrated circuit card; storing a second application in the memory of the integrated circuit card; and the creation of a firewall that isolates the first application and the second application in such a way that the second application can not access either the first application or data associated with the first application.
102. 102. The method of claim 101, wherein the first application and the second application comprise Java byte codes.
103. 103. The method of claim 100, wherein the creation includes the use of a Java interpreter.
104. 104. The method of claim 101, wherein storing the first application is carried out in association with the manufacture of an integrated circuit card; the storage of the second application is carried out at a later time after finishing the manufacturing.
105. 105. An integrated circuit card for use with a terminal, comprising: a communicator configured to communicate with the terminal; a memory that stores: applications, each application has a high-level programming language format, and an interpreter; a processor coupled to the memory, the processor is configured to: a) use the interpreter to interpret the applications for execution, b) use the interpreter to create a firewall to isolate the applications among them, c) use the communicator to communicate with the terminal.