Java Card(cid:212)
` 2.1 Virtual
`Machine Specification
`
`Sun Microsystems, Inc.
`901 San Antonio Road
`Palo Alto, CA 94303 USA
`415 960-1300
`fax 415 969-9131
`
`Final Revision 1.0, March 3, 1999
`
`SAMSUNG 1012
`
`1
`
`

`

`Copyright © 1999 Sun Microsystems, Inc.
`
`901 San Antonio Road, Palo Alto, CA 94303 USA
`
`All rights reserved. Copyright in this document is owned by Sun Microsystems, Inc.
`
`Sun Microsystems, Inc. (SUN) hereby grants to you at no charge a nonexclusive, nontransferable,
`worldwide, limited license (without the right to sublicense) under SUN's intellectual property rights that are
`essential to practice the Java Card(cid:212)
` 2.1 Virtual Machine Specification ("Specification") to use the
`Specification for internal evaluation purposes only. Other than this limited license, you acquire no right,
`title, or interest in or to the Specification and you shall have no right to use the Specification for productive
`or commercial use.
`
`RESTRICTED RIGHTS LEGEND
`
`Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87)
`and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-1(a).
`
`SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE
`SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
`WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-
`INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A
`RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
`
`TRADEMARKS
`
`Sun, the Sun logo, Sun Microsystems, JavaSoft, JavaBeans, JDK, Java, Java Card, HotJava, HotJava Views,
`Visual Java, Solaris, NEO, Joe, Netra, NFS, ONC, ONC+, OpenWindows, PC-NFS, EmbeddedJava,
`PersonalJava, SNM, SunNet Manager, Solaris sunburst design, Solstice, SunCore, SolarNet, SunWeb, Sun
`Workstation, The Network Is The Computer, ToolTalk, Ultra, Ultracomputing, Ultraserver, Where The
`Network Is Going, Sun WorkShop, XView, Java WorkShop, the Java Coffee Cup logo, and Visual Java are
`trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
`
`THIS PUBLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
`IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
`FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
`
`THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
`CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE
`INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE
`IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED
`IN THIS PUBLICATION AT ANY TIME.
`
`Please
`Recycle
`
`2
`
`

`

`Contents
`
`Figures vii
`
`Tables ix
`
`1.
`
`Introduction 1
`
`1.1 Motivation 1
`
`1.2 The Java Card Virtual Machine
`
`2
`
`1.3
`
`1.4
`
`Java Language Security 4
`
`Java Card Runtime Environment Security 4
`
`2. A Subset of the Java Virtual Machine
`
`7
`
`2.1 Why a Subset is Needed 7
`
`2.2
`
`Java Card Language Subset
`
`2.2.1 Unsupported Items
`
`2.2.2
`
`Supported Items
`
`10
`
`7
`
`8
`
`2.2.3 Optionally Supported Items
`
`12
`
`2.2.4
`
`Limitations of the Java Card Virtual Machine
`
`12
`
`2.3
`
`Java Card VM Subset
`
`14
`
`2.3.1
`
`2.3.2
`
`2.3.3
`
`class File Subset
`
`Bytecode Subset
`
`15
`
`18
`
`Exceptions
`
`20
`
`Contents
`
`iii
`
`3
`
`

`

`3.
`
`Structure of the Java Card Virtual Machine
`
`25
`
`3.1 Data Types and Values
`
`25
`
`3.2 Words
`
`26
`
`3.3 Runtime Data Areas
`
`26
`
`3.4 Contexts
`
`26
`
`3.5
`
`Frames
`
`27
`
`3.6 Representation of Objects
`
`27
`
`3.7
`
`Special Initialization Methods
`
`27
`
`3.8 Exceptions
`
`28
`
`3.9 Binary File Formats
`
`28
`
`3.10 Instruction Set Summary 28
`
`3.10.1 Types and the Java Card Virtual Machine
`
`29
`
`4. Binary Representation 33
`
`4.1
`
`Java Card File Formats
`
`33
`
`4.1.1
`
`Export File Format
`
`34
`
`4.1.2 CAP File Format
`
`34
`
`4.1.3
`
`JAR File Container
`
`34
`
`4.2 AID-based Naming 35
`
`4.2.1
`
`The AID Format
`
`35
`
`4.2.2 AID Usage
`
`36
`
`4.3 Token-based Linking 37
`
`4.3.1
`
`4.3.2
`
`4.3.3
`
`4.3.4
`
`4.3.5
`
`4.3.6
`
`4.3.7
`
`Externally Visible Items
`
`37
`
`Private Tokens
`
`37
`
`The Export File and Conversion 38
`
`References – External and Internal
`
`38
`
`Installation and Linking 39
`
`Token Assignment
`
`39
`
`Token Details
`
`39
`
`4.4 Binary Compatibility 42
`
`iv
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`4
`
`

`

`4.5 Package Versions
`
`44
`
`4.5.1 Assigning 44
`
`4.5.2
`
`Linking 45
`
`5. The Export File Format
`
`47
`
`5.1 Export File Name
`
`48
`
`5.2 Containment in a Jar File
`
`48
`
`5.3 Export File
`
`48
`
`5.4 Constant Pool
`
`50
`
`5.4.1 CONSTANT_Package
`
`51
`
`5.4.2 CONSTANT_Interfaceref
`
`52
`
`5.4.3 CONSTANT_Integer
`
`53
`
`5.4.4 CONSTANT_Utf8
`
`53
`
`5.5 Classes and Interfaces
`
`54
`
`5.6
`
`Fields
`
`57
`
`5.7 Methods
`
`59
`
`5.8 Attributes
`
`61
`
`5.8.1 ConstantValue Attribute
`
`61
`
`6. The CAP File Format
`
`63
`
`6.1 Component Model
`
`64
`
`6.1.1 Containment in a JAR File
`
`65
`
`6.1.2 Defining New Components
`
`65
`
`6.2
`
`Installation 66
`
`6.3 Header Component
`
`67
`
`6.4 Directory Component
`
`69
`
`6.5 Applet Component
`
`6.6
`
`Import Component
`
`72
`
`74
`
`6.7 Constant Pool Component
`
`75
`
`6.7.1 CONSTANT_Classref
`
`77
`
`Contents
`
`v
`
`5
`
`

`

`6.7.2 CONSTANT_InstanceFieldref, CONSTANT_VirtualMethodref, and
`CONSTANT_SuperMethodref
`78
`
`6.7.3 CONSTANT_StaticFieldref and CONSTANT_StaticMethodref
`
`80
`
`6.8 Class Component
`
`82
`
`6.8.1
`
`interface_info and class_info 84
`
`6.9 Method Component
`
`90
`
`6.9.1
`
`exception_handler_info 91
`
`6.9.2 method_info 92
`
`6.10 Static Field Component
`
`95
`
`6.11 Reference Location Component
`
`98
`
`6.12 Export Component
`
`100
`
`6.13 Descriptor Component
`
`103
`
`6.13.1 class_descriptor_info 104
`
`6.13.2 field_descriptor_info 106
`
`6.13.3 method_descriptor_info 108
`
`6.13.4 type_descriptor_info 110
`
`7.
`
`Java Card Virtual Machine Instruction Set
`
`113
`
`7.1 Assumptions: The Meaning of “Must”
`
`113
`
`7.2 Reserved Opcodes
`
`114
`
`7.3 Virtual Machine Errors
`
`114
`
`7.4
`
`Security Exceptions
`
`115
`
`7.5 The Java Card Virtual Machine Instruction Set
`
`115
`
`8. Tables of Instructions
`
`245
`
`Glossary 249
`
`vi
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`6
`
`

`

`Figures
`
`FIGURE 1-1
`
`Java Card Applet Conversion 2
`
`FIGURE 1-2
`
`Java Card Applet Installation 3
`
`FIGURE 4-1
`
`AID Format
`
`36
`
`FIGURE 4-2
`
`Mapping package identifiers to AIDs
`
`36
`
`FIGURE 4-3
`
`Tokens for Instance Fields
`
`41
`
`FIGURE 4-4
`
`Binary compatibility example 43
`
`FIGURE 7-1
`
`An example instruction page 116
`
`Figures
`
`vii
`
`7
`
`

`

`viii
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`8
`
`

`

`Tables
`
`TABLE 2-1
`
`Unsupported Java constant pool tags
`
`15
`
`TABLE 2-2
`
`Supported Java constant pool tags.
`
`TABLE 2-3
`
`Support of Java checked exceptions
`
`TABLE 2-4
`
`Support of Java runtime exceptions
`
`16
`
`21
`
`22
`
`TABLE 2-5
`
`Support of Java errors
`
`23
`
`TABLE 3-1
`
`Type support in the Java Card Virtual Machine Instruction Set
`
`30
`
`TABLE 3-2
`
`Storage types and computational types
`
`31
`
`TABLE 4-1
`
`Token Range, Type and Scope 39
`
`TABLE 5-1
`
`Export file constant pool tags
`
`50
`
`TABLE 5-2
`
`Export file package flags
`
`51
`
`TABLE 5-3
`
`Export file class access and modifier flags
`
`55
`
`TABLE 5-4
`
`Export file field access and modifier flags
`
`58
`
`TABLE 5-5
`
`Export file method access and modifier flags
`
`60
`
`TABLE 6-1
`
`CAP file component tags
`
`64
`
`TABLE 6-2
`
`CAP file component file names
`
`65
`
`TABLE 6-3
`
`Reference component install order
`
`66
`
`TABLE 6-4
`
`CAP file package flags
`
`68
`
`TABLE 6-5
`
`CAP file constant pool tags 76
`
`Tables
`
`ix
`
`9
`
`

`

`TABLE 6-6
`
`CAP file interface and class flags
`
`84
`
`TABLE 6-7
`
`CAP file method flags
`
`93
`
`TABLE 6-8
`
`Segments of a static field image 95
`
`TABLE 6-9
`
`Static field sizes
`
`95
`
`TABLE 6-10
`
`Array types
`
`97
`
`TABLE 6-11
`
`One-byte reference location example 99
`
`TABLE 6-12
`
`CAP file class descriptor flags
`
`TABLE 6-13
`
`CAP file field descriptor flagss
`
`104
`
`106
`
`TABLE 6-14
`
`Primitive type descriptor values
`
`107
`
`TABLE 6-15
`
`CAP file method descriptor flags
`
`108
`
`TABLE 6-16
`
`Type descriptor values 111
`
`TABLE 6-17
`
`Encoded reference type p1.c1 111
`
`TABLE 6-18
`
`Encoded byte array type 111
`
`TABLE 6-19
`
`Encoded reference array type p1.c1 112
`
`TABLE 6-20
`
`Encoded method signature ()V 112
`
`TABLE 6-21
`
`Encoded method signature (Lp1.ci;)S 112
`
`TABLE 8-1
`
`Instructions by Opcode Value 245
`
`TABLE 8-2
`
`Instructions by Opcode Mnemonic
`
`247
`
`x
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`10
`
`

`

`Preface
`
`Java Card(cid:212)
` technology combines a subset of the Java programming language with a
`runtime environment optimized for smart cards and similar small-memory
`embedded devices. The goal of Java Card technology is to bring many of the benefits
`of Java software programming to the resource-constrained world of devices such as
`smart cards.
`The Java Card platform is defined by three specifications: this Java Card(cid:212)
` 2.1 Virtual
`Machine Specification, the Java Card(cid:212)
` 2.1 Application Programming Interface, and the
`Java Card(cid:212)
` 2.1 Runtime Environment (JCRE) Specification.
`
`This specification describes the required behavior of the Java Card 2.1 Virtual
`Machine (VM) that developers should adhere to when creating an implementation. An
`implementation within the context of this document refers to a licensee’s
`implementation of the Java Card Virtual Machine (VM), Application Programming
`Interface (API), Converter, or other component, based on the Java Card technology
`specifications. A Reference Implementation is an implementation produced by Sun
`Microsystems, Inc. Application software written for the Java Card platform is
`referred to as a Java Card applet.
`
`Who Should Use This Specification?
`
`This document is for licensees of the Java Card technology to assist them in creating
`an implementation, developing a specification to extend the Java Card technology
`specifications, or in creating an extension to the Java Card Runtime Environment
`(JCRE). This document is also intended for Java Card applet developers who want a
`more detailed understanding of the Java Card technology specifications.
`
`Preface
`
`xi
`
`11
`
`

`

`Before You Read This Specification
`
`Before reading this document, you should be familiar with the Java programming
`language, the Java Card technology specifications, and smart card technology. A
`good resource for becoming familiar with Java technology and Java Card technology
`is the Sun Microsystems, Inc. website, located at: http://java.sun.com.
`
`How This Book Is Organized
`
`Chapter 1, “Introduction,” provides an overview of the Java Card Virtual Machine
`architecture.
`
`Chapter 2, “A Subset of the Java Virtual Machine,” describes the subset of the Java
`programming language and Virtual Machine that is supported by the Java Card
`specification.
`
`Chapter 3, “Structure of the Java Card Virtual Machine,” describes the differences
`between the Java Virtual Machine and the Java Card Virtual Machine.
`
`Chapter 4, “Binary Representation,” provides information about how Java Card
`programs are represented in binary form.
`
`Chapter 5, “The Export File,” describes the Converter export file used to link code
`against another package.
`
`Chapter 6, “The CAP File Format,” describes the format of the CAP file.
`
`Chapter 7, “Instruction Set,” describes the byte codes (opcodes) that comprise the
`Java Card Virtual Machine instruction set.
`
`Chapter 8, “Tables of Instructions,” summarizes the Java Card Virtual Machine
`instructions in two different tables: one sorted by Opcode Value and the other sorted
`by Mnemonic.
`
`Glossary is a list of words and their definitions to assist you in using this book.
`
`Prerequisites
`
`This specification is not intended to stand on its own; rather it relies heavily on
`existing documentation of the Java platform. In particular, two books are required
`for the reader to understand the material presented here.
`
`[1] Gosling, James, Bill Joy, and Guy Steele. The Java™ Language Specification.
`Addison-Wesley, 1996, ISBN 0-201-63451-1 – contains the definitive definition of the
`Java programming language. The Java Card 2.1 language subset defined here is
`based on the language specified in this book.
`
`xii
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`12
`
`

`

`[2] Lindholm, Tim, and Frank Yellin. The Java™ Virtual Machine Specification.
`Addison-Wesley, 1996, ISBN 0-201-63452-X – defines the standard operation of the
`Java Virtual Machine. The Java Card virtual machine presented here is based on the
`definition specified in this book.
`
`Related Documents
`
` 2.1 Application Programming Interface, Sun Microsystems, Inc.
` 2.1 Runtime Environment (JCRE) 2.1 Specification, Sun Microsys-
`
`•
`•
`
`•
`•
`
`•
`
`References to various documents or products are made in this manual. You should
`have the following documents available:
`Java Card(cid:212)
`Java Card(cid:212)
`tems, Inc.
`Java Card(cid:212)
` 2.1 Applet Developer’s Guide, Sun Microsystems, Inc.
`The Java(cid:212)
` Language Specification by James Gosling, Bill Joy, and Guy L. Steele.
`Addison-Wesley, 1996, ISBN 0-201-63451-1.
`The Java(cid:212)
` Virtual Machine Specification (Java Series) by Tim Lindholm and
`Frank Yellin. Addison-Wesley, 1996, ISBN 0-201-63452-X.
`The Java(cid:212)
` Class Libraries: An Annotated Reference (Java Series) by Patrick Chan
`and Rosanna Lee. Addison-Wesley, ISBN: 0201634589.
`ISO 7816 International Standard, First Edition 1987-07-01.
`EMV ’96 Integrated Circuit Card Specification for Payment Systems, Version 3.0,
`June 30, 1996.
`
`•
`
`•
`•
`
`Ordering Sun Documents
`
`The SunDocs™ program provides more than 250 manuals from Sun Microsystems,
`Inc. If you live in the United States, Canada, Europe, or Japan, you can purchase
`documentation sets or individual manuals using this program.
`
`For a list of documents and how to order them, see the catalog section of the
`SunExpress™ Internet site at http://www.sun.com/sunexpress.
`
`xiii
`
`13
`
`

`

`What Typographic Changes Mean
`
`The following table describes the typographic changes used in this book.
`
`TABLE P-1 Typographic Conventions
`
`Typeface or
`Symbol
`
`AaBbCc123
`
`Meaning
`
`Example
`
`Java code, Java keywords or
`variables, or class files.
`
`The token item of a
`CONSTANT_StaticFieldref_info
`structure ...
`
`bytecode
`
`Java language bytecodes
`
`invokespecial
`
`AaBbCc123
`
`AaBbCc123
`
`Command-line placeholder:
`replace with a real name or
`value
`
`Book titles, new words or
`terms, or words to be
`emphasized
`
`Acknowledgements
`
`To delete a file, type rm filename.
`
`Read Chapter 6 in User’s Guide. These
`are called class options.
`You must be root to do this.
`
`Java Card technology is based on Java technology. This specification could not exist
`without all the hard work that went into the development of the Java platform
`specifications. In particular, this specification is based significantly on the Java™
`Virtual Machine Specification. In order to maintain consistency with that specification,
`as well as to make differences easier to notice, we have, where possible, used the
`words, the style, and even the visual design of that book. Many thanks to Tim
`Lindholm and Frank Yellin for providing a solid foundation for our work.
`
`xiv
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`14
`
`

`

`C HA PT ER 1
`
`Introduction
`
`1.1
`
`Motivation
`
`Java Card technology enables programs written in the Java programming language
`to be run on smart cards and other small, resource-constrained devices. Developers
`can build and test programs using standard software development tools and
`environments, then convert them into a form that can be installed onto a Java Card
`technology enabled device. Application software for the Java Card platform is called
`an applet, or more specifically, a Java Card applet or card applet (to distinguish it
`from browser applets).
`
`While Java Card technology enables programs written in the Java programming
`language to run on smart cards, such small devices are far too under-powered to
`support the full functionality of the Java platform. Therefore, the Java Card platform
`supports only a carefully chosen, customized subset of the features of the Java
`platform. This subset provides features that are well-suited for writing programs for
`small devices and preserves the object-oriented capabilities of the Java programming
`language.
`
`A simple approach to specifying a Java Card virtual machine would be to describe
`the subset of the features of the Java virtual machine that must be supported to
`allow for portability of source code across all Java Card technology enabled devices.
`Combining that subset specification and the information in the Java Virtual Machine
`Specification, smart card manufacturers could construct their own Java Card
`implementations. While that approach is feasible, it has a serious drawback. The
`resultant platform would be missing the important feature of binary portability of
`Java Card applets.
`
`The standards that define the Java platform allow for binary portability of Java
`programs across all Java platform implementations. This “write once, run anywhere”
`quality of Java programs is perhaps the most significant feature of the platform. Part
`
`1
`
`15
`
`

`

`of the motivation for the creation of the Java Card platform was to bring just this
`kind of binary portability to the smart card industry. In a world with hundreds of
`millions or perhaps even billions of smart cards with varying processors and
`configurations, the costs of supporting multiple binary formats for software
`distribution could be overwhelming.
`
`This Java Card 2.1 Virtual Machine Specification is the key to providing binary
`portability. One way of understanding what this specification does is to compare it
`to its counterpart in the Java platform. The Java Virtual Machine Specification defines a
`Java virtual machine as an engine that loads Java class files and executes them with
`a particular set of semantics. The class file is a central piece of the Java architecture,
`and it is the standard for the binary compatibility of the Java platform. The Java Card
`2.1 Virtual Machine Specification also defines a file format that is the standard for
`binary compatibility for the Java Card platform: the CAP file format is the form in
`which software is loaded onto devices which implement a Java Card virtual
`machine.
`
`1.2
`
`The Java Card Virtual Machine
`
`The role of the Java Card virtual machine is best understood in the context of the
`process for production and deployment of Java Card software. There are several
`components that make up a Java Card system, including the Java Card virtual
`machine, the Java Card Converter, a terminal installation tool, and an installation
`program that runs on the device, as shown in Figures 1-1 and 1-2.
`
`Development System
`
`class
`files
`
`export
`files
`
`Converter
`
`CAP file
`
`FIGURE 1-1
`
`Java Card Applet Conversion
`
`2
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`16
`
`

`

`Terminal
`
`Device
`
`CAP file
`
`Installation
`Tool
`
`Installer
`
`Virtual
`Machine
`
`Program Memory
`
`FIGURE 1-2
`
`Java Card Applet Installation
`
`Development of a Java Card applet begins as with any other Java program: a
`developer writes one or more Java classes, and compiles the source code with a Java
`compiler, producing one or more class files. The applet is run, tested and debugged
`on a workstation using simulation tools to emulate the device environment. Then,
`when an applet is ready to be downloaded to a device, the class files comprising
`the applet are converted to a CAP (converted applet) file using a Java Card Converter.
`
`The Java Card Converter takes as input not only the class files to be converted, but
`also one or more export files. An export file contains name and link information
`for the contents of other packages that are imported by the classes being converted.
`When an applet or library package is converted, the converter can also produce an
`export file for that package.
`
`After conversion, the CAP file is copied to a card terminal, such as a desktop
`computer with a card reader peripheral. Then an installation tool on the terminal
`loads the CAP file and transmits it to the Java Card technology enabled device. An
`installation program on the device receives the contents of the CAP file and prepares
`the applet to be run by the Java Card virtual machine. The virtual machine itself
`need not load or manipulate CAP files; it need only execute the applet code found in
`the CAP file that was loaded onto the device by the installation program.
`
`The division of functionality between the Java Card virtual machine and the
`installation program keeps both the virtual machine and the installation program
`small. The installation program may be implemented as a Java program and
`executed on top of the Java Card virtual machine. Since Java Card instructions are
`denser than typical machine code, this may reduce the size of the installer. The
`modularity may enable different installers to be used with a single Java Card virtual
`machine implementation.
`
`Chapter 1
`
`Introduction
`
`3
`
`17
`
`

`

`1.3
`
`Java Language Security
`
`One of the fundamental features of the Java virtual machine is the strong security
`provided in part by the class file verifier. Many devices that implement the Java
`Card platform may be too small to support verification of CAP files on the device
`itself. This consideration led to a design that enables verification on a device but
`does not rely on it. The data in a CAP file that is needed only for verification is
`packaged separately from the data needed for the actual execution of its applet. This
`allows for flexibility in how security is managed in an implementation.
`
`There are several options for providing language-level security on a Java Card
`technology enabled device. The conceptually simplest is to verify the contents of a
`CAP file on the device as it is downloaded or after it is downloaded. This option
`might only be feasible in the largest of devices. However, some subset of verification
`might be possible even on smaller devices. Other options rely on some combination
`of one or more of: physical security of the installation terminal, a cryptographically
`enforced chain of trust from the source of the CAP file, and pre-download verification
`of the contents of a CAP file.
`
`The Java Card platform standards say as little as possible about CAP file installation
`and security policies. Since smart cards must serve as secure processors in many
`different systems with different security requirements, it is necessary to allow a great
`deal of flexibility to meet the needs of smart card issuers and users.
`
`1.4
`
`Java Card Runtime Environment
`Security
`
`The standard runtime environment for the Java Card platform is the Java Card
`Runtime Environment (JCRE). The JCRE consists of an implementation of the Java
`Card virtual machine along with the Java Card API classes. While the Java Card
`virtual machine has responsibility for ensuring Java language-level security, the
`JCRE imposes additional runtime security requirements on devices that implement
`the JCRE, which results in a need for additional features on the Java Card virtual
`machine. Throughout this document, these additional features are designated as
`JCRE-specific.
`
`4
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`18
`
`

`

`The basic runtime security feature imposed by the JCRE enforces isolation of applets
`using what is called an applet firewall. The applet firewall prevents the objects that
`were created by one applet from being used by another applet. This prevents
`unauthorized access to both the fields and methods of class instances, as well as the
`length and contents of arrays.
`
`Isolation of applets is an important security feature, but it requires a mechanism to
`allow applets to share objects in situations where there is a need to interoperate. The
`JCRE allows such sharing using the concept of shareable interface objects. These
`objects provide the only way an applet can make its objects available for use by
`other applets. For more information about using sharable interface objects, see the
`description of the interface javacard.framework.Shareable in the Java Card 2.1
`Application Programming Interface specification. Some descriptions of firewall-related
`features will make reference to the Shareable interface.
`
`The applet firewall also protects from unauthorized use the objects owned by the
`JCRE itself. The JCRE can use mechanisms not reflected in the Java Card API to
`make its objects available for use by applets. A full description of the JCRE-related
`isolation and sharing features can be found in the Java Card 2.1 Runtime Environment
`Specification.
`
`Chapter 1
`
`Introduction
`
`5
`
`19
`
`

`

`6
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`20
`
`

`

`C HA PT ER 2
`
`A Subset of the Java Virtual Machine
`
`This chapter describes the subset of the Java virtual machine and language that is
`supported in the Java Card 2.1 platform.
`
`2.1
`
`Why a Subset is Needed
`
`It would be ideal if programs for smart cards could be written using all of the Java
`programming language, but a full implementation of the Java virtual machine is far
`too large to fit on even the most advanced resource-constrained devices available
`today.
`
`A typical resource-constrained device has on the order of 1K of RAM, 16K of non-
`volatile memory (EEPROM or flash) and 24K of ROM. The code for implementing
`string manipulation, single and double-precision floating point arithmetic, and
`thread management would be larger than the ROM space on such a device. Even if it
`could be made to fit, there would be no space left over for class libraries or
`application code. RAM resources are also very limited. The only workable option is
`to implement Java Card technology as a subset of the Java platform.
`
`2.2
`
`Java Card Language Subset
`
`Applets written for the Java Card platform are written in the Java programming
`language. They are compiled using Java compilers. Java Card technology uses a
`subset of the Java language, and familiarity with the Java platform is required to
`understand the Java Card platform.
`
`7
`
`21
`
`

`

`The items discussed in this section are not described to the level of a language
`specification. For complete documentation on the Java programming language, see
`The Java Language Specification (§1.1).
`
`2.2.1
`
`Unsupported Items
`The items listed in this section are elements of the Java programming language and
`platform that are not supported by the Java Card platform.
`
`2.2.1.1
`
`Unsupported Features
`
`Dynamic Class Loading
`
`Dynamic class loading is not supported in the Java Card platform. An
`implementation of the Java Card platform is not able to load classes dynamically.
`Classes are either masked into the card during manufacturing or downloaded
`through an installation process after the card has been issued. Programs executing
`on the card may only refer to classes that already exist on the card, since there is no
`way to download classes during the normal execution of application code.
`
`Security Manager
`
`Security management in the Java Card platform differs significantly from that of the
`Java platform. In the Java platform, there is a Security Manager class
`(java.lang.SecurityManager) responsible for implementing security features. In
`the Java Card platform, language security policies are implemented by the virtual
`machine. There is no Security Manager class that makes policy decisions on whether
`to allow operations.
`
`Garbage Collection & Finalization
`
`Java Card technology does not require a garbage collector. Nor does Java Card
`technology allow explicit deallocation of objects, since this would break the Java
`programming language’s required pointer-safety. Therefore, application
`programmers cannot assume that objects that are allocated are ever deallocated.
`Storage for unreachable objects will not necessarily be reclaimed.
`
`Finalization is also not required. finalize() will not necessarily be called
`automatically by the Java Card virtual machine, and programmers should not rely
`on this behavior.
`
`8
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`22
`
`

`

`Threads
`
`The Java Card virtual machine does not support multiple threads of control. Java
`Card programs cannot use class Thread or any of the thread-related keywords in the
`Java programming language.
`
`Cloning
`
`The Java Card platform does not support cloning of objects. Java Card API class
`Object does not implement a clone method, and there is no Cloneable interface
`provided.
`
`Access Control in Java Packages
`
`The Java Card language subset supports the package access control defined in the
`Java language. However, there are two cases that are not supported.
`n If a class implements a method with package access visibility, a subclass cannot
`override the method and change the access visibility of the method to protected
`or public.
`n An interface that is defined with package access visibility cannot be extended by
`an interface with public access visibility.
`
`2.2.1.2
`
`Keywords
`
`The following keywords indicate unsupported options related to native methods,
`threads and memory management.
`
`native
`
`synchronized
`
`transient
`
`volatile
`
`2.2.1.3
`
`Unsupported Types
`
`The Java Card platform does not support types char, double, float or long, or
`operations on those types. It also does not support arrays of more than one
`dimension.
`
`Chapter 2
`
`A Subset of the Java Virtual Machine
`
`9
`
`23
`
`

`

`2.2.1.4
`
`Classes
`
`In general, none of the Java core API classes are supported in the Java Card
`platform. Some classes from the java.lang package are supported (see §2.2.2.4), but
`none of the rest are. For example, classes that are not supported are String, Thread
`(and all thread-related classes), wrapper classes such as Boolean and Integer, and
`class Class.
`
`System
`
`Class java.lang.System is not supported. Java Card technology supplies a class
`javacard.framework.JCSystem, which provides an interface to system behavior.
`
`2.2.2
`
`Supported Items
`
`If a language feature is not explicitly described as unsupported, it is part of the
`supported subset. Notable supported features are described in this section.
`
`2.2.2.1
`
`Features
`
`Packages
`
`Software written for the Java Card platform follows the standard rules for the Java
`platform packages. Java Card API classes are written as Java source files, which
`include package designations. Package mechanisms are used to identify and control
`access to classes, static fields and static methods. Except as noted in “Access Control
`in Java Packages” (§2.2.1.1), packages in the Java Card platform are used exactly the
`way they are in the Java platform.
`
`Dynamic Object Creation
`
`The Java Card platform programs supports dynamically created objects, both class
`instances and arrays. This is done, as usual, by using the new operator. Objects are
`allocated out of the heap.
`
`As noted in “Garbage Collection & Finalization” (§2.2.1.1), a Java Card virtual
`machine will not necessarily garbage collect objects. Any object allocated by a virtual
`machine may continue to exist and consume resources even after it becomes
`unreachable.
`
`10
`
`Java Card 2.1 Virtual Machine Specification • March 3, 1999
`
`24
`
`

`

`Virtual Methods
`
`Since Java Card objects are Java programming language objects, invoking virtual
`methods on objects in a program written for the Java Card platform is exactly the
`same as in a program written for the Java platform. Inheritance is supported,
`including the use of the super keyword.
`
`Interfaces
`
`Java Card classes may define or implement interfaces as in the Java programming
`language. Invoking methods on interface types works as expected. Type checking
`and the instanceof operator also work correctly with interfaces.
`
`Exceptions
`
`Java Card programs may define, throw and catch exceptions, as in Java programs.
`Class Throwable and its relevant subclasses are supported. (Some Exception and
`Error subclasses are omitted, since those exceptions cannot occur in the Java Card
`platform. See §2.3.3 for specification of errors and exceptions.)
`
`2.2.2.2
`
`Keywords
`
`The following keywords are supported. Their use is the same as in the Java
`programming language.
`
`abstract
`boolean
`break
`byte
`case
`catch
`class
`continue
`
`default
`do
`else
`extends
`final
`finally
`for
`goto
`
`if
`implements
`import
`instanceof
`int
`interface
`new
`package
`
`private
`protected
`public
`return
`short
`static
`super
`switch
`
`this
`throw
`throws
`try
`void
`while
`
`2.2.2.3
`
`Types
`
`Java programming language types boolean, byte, short, and int are supported.
`Objects (class instances and single-dimensional arrays) are also supported. Arrays
`can contain the supported primitive data types, objects, and other arrays.
`
`Chapter 2
`
`A Subset of the Java Virtual Machine
`
`11
`
`25
`
`

`

`Some Java Card implementations might not support use of the int data type. (Refer
`to §2.2.3.1.)
`
`2.2.2.4
`
`Classes
`
`Most of the classes in the java.lang package are not support