wiki javacard:jcre

javacard:jcre:1._introduction

2017-05-13T04:05:59+00:00

1. Introduction The runtime environment (RE) for the Java Card Platform, Version 2.2.2, contains the Java Card virtual machine (VM), the Java Card Application Programming Interface (API) classes (and industry-specific extensions), and support services.

javacard:jcre:2._lifetime_of_the_java_card_virtual_machine

2017-05-13T04:08:22+00:00

2. Lifetime of the Java Card Virtual Machine In a PC or workstation, the Java virtual machine^[1] runs as an operating system process. When the OS process is terminated, the Java programming language applications and their objects are automatically destroyed.

javacard:jcre:3.1_install_method

2017-05-13T04:08:24+00:00

3.1 install Method When the install(byte[], short, byte) method is called, the applet instance does not yet exist. The main task of the install method within the applet is to create an instance of the Applet subclass using its constructor, and to register the instance. All other objects that the applet needs during its lifetime can be created as is feasible. Any other preparations necessary for the applet to be selected and accessed by a CAD also can be done as is feasible. The

javacard:jcre:3.2_select_method

2017-05-13T04:08:24+00:00

3.2 select Method Applets remain in a suspended state until they are explicitly selected. Selection occurs when the Java Card RE receives a SELECT FILE APDU command in which the name data matches the AID of the applet. Applet selection can also occur on a MANAGE CHANNEL OPEN command. Selection causes an applet to become the currently selected applet. For more details, see

javacard:jcre:3.3_process_method

2017-05-13T04:08:25+00:00

3.3 process Method All APDUs are received by the Java Card RE and preprocessed. All commands, except for the MANAGE CHANNEL command result in an instance of the APDU class containing the command being passed to the process(APDU) method of the currently selected applet.

javacard:jcre:3.4_deselect_method_s

2017-05-13T04:08:25+00:00

3.4 deselect Method(s) When the Java Card RE receives a SELECT FILE APDU command in which the name matches the AID of an applet, the Java Card RE calls the Applet.deselect method of the currently selected applet or, if concurrently selected on more than one logical channel, its

javacard:jcre:3.5_uninstall_method

2017-05-13T04:08:27+00:00

3.5 uninstall Method This method is defined in the javacard.framework.AppletEvent interface. When the Java Card RE is preparing to delete the applet instance, the Java Card RE calls this method, if implemented by the applet, to inform it of the deletion request. Upon return from this method, the Java Card RE checks for reference dependencies before deleting the applet instance.

javacard:jcre:3.6.1_concurrent_operations_over_multiple_interfaces

2017-05-13T04:08:27+00:00

3.6.1 Concurrent Operations Over Multiple Interfaces A Java Card technology compliant proximity contactless card operates in the ACTIVE state and processes commands defined in the ISO 14443 Specification Parts 1-4. The Supervisory block (S-block) DESELECT command results in the proximity card entering the HALT state.

javacard:jcre:3.6_power_loss_and_reset

2017-05-13T04:08:28+00:00

3.6 Power Loss and Reset Power loss occurs under one of the following conditions: * The card is withdrawn from the CAD. * When operating in contactless-only mode, the card loses carrier energy from the radio frequency (RF) field and enters the POWER OFF state as defined in the

javacard:jcre:3._java_card_applet_lifetime

2017-05-13T04:08:29+00:00

3. Java Card Applet Lifetime For the purposes of this specification, applet refers to an applet written for the Java Card platform. An applet instance's lifetime begins when it is successfully registered with the Java Card RE via the Applet.register

javacard:jcre:4.1.1_card_reset_behavior

2017-05-13T04:07:04+00:00

4.1.1 Card Reset Behavior The following describes card reset behavior: 1. After card reset (or power on, which is a form of reset) on the contacted I/O interface, the Java Card RE performs its initialization and checks to see if its internal state indicates that a particular applet instance is the default applet instance for the basic logical channel. If so, the Java Card RE makes this applet instance the currently selected applet instance on the basic logical channel, and the applet's

javacard:jcre:4.1.2_proximity_card_picc_activation_behavior

2017-05-13T04:07:09+00:00

4.1.2 Proximity Card (PICC) Activation Behavior The following describes the PICC activation behavior: 1. After the successful completion of the PICC activation sequence on the contactless interface, the Java Card RE performs its initialization, if the contacted interface is not already active, and then checks to see if its internal state indicates that a particular applet instance is the default applet instance for the basic logical channel on the contactless I/O interface. If the default app…

javacard:jcre:4.1.3_default_applet_selection_behavior_on_opening_a_new_channel

2017-05-13T04:07:11+00:00

4.1.3 Default Applet Selection Behavior on Opening a New Channel The following default applet selection behavior occurs on opening a new logical channel. When a MANAGE CHANNEL command is issued on the basic logical channel and a new logical channel is opened, the Java Card RE checks if there is a designated default applet instance for the newly opened logical channel. If so, the Java Card RE makes this applet instance the currently selected applet instance on the new logical channel, and the …

javacard:jcre:4.1_default_applets

2017-05-13T04:07:11+00:00

4.1 Default Applets Normally, applet instances become selected only via a successful SELECT FILE command. However, some smart card CAD applications require a default card applet instance to become implicitly selected after every card reset. In addition, some CAD applications may also require a default applet selection when a new logical channel is opened.

javacard:jcre:4.2_multiselectable_applets

2017-05-13T04:07:13+00:00

4.2 Multiselectable Applets Applets having the capability of being selected on multiple logical channels at the same time, or accepting other applets belonging to the same package being selected simultaneously, are referred to as multiselectable applets.

javacard:jcre:4.3_forwarding_apdu_commands_to_a_logical_channel

2017-05-13T04:07:13+00:00

4.3 Forwarding APDU Commands To a Logical Channel According to Section 5.4 of the ISO 7816-4:2005 Specification specification, the interindustry values of the CLA byte equal to 0x0X and 0x1X in the APDU command encode channel numbers in the range 0-3, whereas interindustry values of the CLA byte equal to 0x4Y, 0x5Y, 0x6Y and 0x7Y in the APDU command encode channel numbers in the range 4-19.

javacard:jcre:4.4.1_manage_channel_command_processing

2017-05-13T04:07:14+00:00

4.4.1 MANAGE CHANNEL Command Processing The Java Card RE shall intercept all APDU messages coming into the card, perform card management functions (such as selecting or deselecting applet instances), and shall forward APDU messages to the appropriate applet instance. As part of its card management functions, the Java Card RE notifies applet instances about selection events (a function it performs by calling the applet instances'

javacard:jcre:4.4_opening_and_closing_logical_channels

2017-05-13T04:07:15+00:00

4.4 Opening and Closing Logical Channels According to Section 5.5.2 of the ISO 7816-4 Specification, the following two ways to open a logical channel in the smart card exist: 1. By selecting an applet instance on a new logical channel. This is accomplished by issuing an Applet SELECT FILE APDU command, and specifying the logical channel number in the CLA byte of the command. If this logical channel is currently closed, it shall be opened, and the specified applet instance shall be selected. S…

javacard:jcre:4.5.1_applet_selection_with_manage_channel_open

2017-05-13T04:07:17+00:00

4.5.1 Applet Selection with MANAGE CHANNEL OPEN Upon receiving a MANAGE CHANNEL OPEN command on an I/O interface, the Java Card RE shall run the following procedure: 1. The MANAGE CHANNEL OPEN command uses: CLA=%b000000cc* (where cc in the bits (b2,b1) denotes the origin logical channel: 0-3), or CLA=

javacard:jcre:4.5.2_applet_selection_with_select_file

2017-05-13T04:07:16+00:00

4.5.2 Applet Selection with SELECT FILE Upon receiving a SELECT FILE command on an I/O interface, the Java Card RE shall run the following procedure: 1. The Applet SELECT FILE command uses: CLA=%b000000cc* (where cc in the bits (b2,b1*) specifies the logical channel to be selected: 0-3), or CLA=

javacard:jcre:4.5_applet_selection

2017-05-13T04:07:18+00:00

4.5 Applet Selection There are two ways to select an applet instance in the Java Card platform: with a MANAGE CHANNEL OPEN command ( Section 4.5.1, Applet Selection with MANAGE CHANNEL OPEN), or with a SELECT FILE command ( Section 4.5.2, Applet Selection with SELECT FILE). The Java Card RE shall guarantee that an applet that is designed to run on any logical channel can be selected on any of the available logical channels on the card. The resources accessed by the applet instance must be the…

javacard:jcre:4.6.1_manage_channel_close_command

2017-05-13T04:07:19+00:00

4.6.1 MANAGE CHANNEL CLOSE Command Upon receiving a MANAGE CHANNEL CLOSE command on an I/O interface, the Java Card RE shall run the following procedure: 1. The MANAGE CHANNEL CLOSE command uses: CLA=%b000000cc* (where cc in the bits (b2,b1) denotes the origin logical channel: 0-3) or CLA=

javacard:jcre:4.6_applet_deselection

2017-05-13T04:07:20+00:00

4.6 Applet Deselection An applet instance is deselected either upon receipt of a MANAGE CHANNEL CLOSE command, or as a result of a SELECT FILE command that selects a different (or the same) applet instance on the specified logical channel. In either case, when an applet instance is deselected the following procedure shall be followed by the Java Card RE:

javacard:jcre:4.7_other_command_processing

2017-05-13T04:07:20+00:00

4.7 Other Command Processing When an APDU other than a SELECT FILE or MANAGE CHANNEL command is received, the logical channel to be used for dispatching the command is based on the CLA byte as described in Section 4.3, Forwarding APDU Commands To a Logical Channel. When the Java Card RE receives an APDU other than a SELECT FILE or MANAGE CHANNEL command with either of the following:

javacard:jcre:4._logical_channels_and_applet_selection

2017-05-13T04:07:22+00:00

4. Logical Channels and Applet Selection Java Card platform, version 2.2.2, provides support for logical channels: The ability to allow a terminal to open up to twenty sessions into the smart card over any I/O interface, one session per logical channel. Logical channels functionality is described in detail in the

javacard:jcre:5.1_events_that_clear_transient_objects

2017-05-13T04:07:22+00:00

5.1 Events That Clear Transient Objects Persistent objects are used for maintaining states that shall be preserved across card resets. When a transient object is created, one of two events is specified that causes its fields to be cleared. CLEAR_ON_RESET

javacard:jcre:5._transient_objects

2017-05-13T04:07:24+00:00

5. Transient Objects Applets sometimes require objects that contain temporary (transient) data that need not be persistent across CAD sessions. The Java Card platform does not support the Java programming language keyword transient. However, Java Card technology provides methods to create transient arrays with primitive components or references to

javacard:jcre:6.1.1_firewall_protection

2017-05-13T04:07:24+00:00

6.1.1 Firewall Protection The Java Card technology-based firewall (Java Card firewall) provides protection against the most frequently anticipated security concern: developer mistakes and design oversights that might allow sensitive data to be “leaked

javacard:jcre:6.1.2.1_active_contexts_in_the_vm

2017-05-13T04:07:26+00:00

6.1.2.1 Active Contexts in the VM At any point in time, there is only one active context within the VM. This is called the currently active context. This can be either the Java Card RE context or an applet's context. All bytecodes that access objects are checked at runtime against the currently active context in order to determine if the access is allowed. A

javacard:jcre:6.1.2.2_context_switching_in_the_vm

2017-05-13T04:07:26+00:00

6.1.2.2 Context Switching in the VM If access is allowed, the VM determines if a context switch is required. A context switch occurs when certain well-defined conditions, as described in Section 6.2.8, Class and Object Access Behavior, are met during the execution of invoke-type bytecodes. For example, a context switch may be caused by an attempt to access a shareable object that belongs to an applet instance that resides in a different package. The result of a context switch is a new currentl…

javacard:jcre:6.1.2_contexts_and_context_switching

2017-05-13T04:07:27+00:00

6.1.2 Contexts and Context Switching Firewalls essentially partition the Java Card platform's object system into separate protected object spaces called contexts. These are illustrated in FIGURE 6-1. The firewall is the boundary between one context and another. The Java Card RE shall allocate and manage a context for each Java

javacard:jcre:6.1.3_object_ownership

2017-05-13T04:07:28+00:00

6.1.3 Object Ownership Any given object in the Java Card platform's object space has a context and an owner associated with it. When a new object is created, it is associated with the currently active context, but the object is owned by the applet instance within the currently active context when the object is instantiated. An object can be owned by an applet instance, or by the Java Card RE.

javacard:jcre:6.1.4_object_access

2017-05-13T04:07:29+00:00

6.1.4 Object Access In general, an object can only be accessed by its owning context, that is, when the owning context is the currently active context. The firewall prevents an object from being accessed by another applet in a different context. In implementation terms, each time an object is accessed, the object's owner context is compared to the currently active context. If these do not match, the access is not performed and a

javacard:jcre:6.1.5_transient_objects_and_contexts

2017-05-13T04:07:30+00:00

6.1.5 Transient Objects and Contexts Transient objects of CLEAR_ON_RESET type behave like persistent objects in that they can be accessed only when the currently active context is the object's owning context (the currently active context at the time when the object was created).

javacard:jcre:6.1.6.1_optional_static_access_checks

2017-05-13T04:07:31+00:00

6.1.6.1 Optional Static Access Checks The Java Card RE may perform optional runtime checks that are redundant with the constraints enforced by a verifier. A Java Card VM may detect when code violates fundamental language restrictions, such as invoking a private method in another class, and report or otherwise address the violation.

javacard:jcre:6.1.6_static_fields_and_methods

2017-05-13T04:07:32+00:00

6.1.6 Static Fields and Methods Instances of classes (objects) are owned by contexts. Classes themselves are not. There is no runtime context check that can be performed when a class static field is accessed. Neither is there a context switch when a static method is invoked. Similarly,

javacard:jcre:6.1_applet_firewall

2017-05-13T04:07:06+00:00

6.1 Applet Firewall The applet firewall within Java Card technology is runtime-enforced protection and is separate from the Java technology protections. The Java programming language protections still apply to Java Card applets. The Java programming language ensures that strong typing and protection attributes are enforced.

javacard:jcre:6.2.1_java_card_re_entry_point_objects

2017-05-13T04:06:13+00:00

6.2.1 Java Card RE Entry Point Objects Secure computer systems must have a way for non-privileged user processes (that are restricted to a subset of resources) to request system services performed by privileged “system” routines. In the Java Card

javacard:jcre:6.2.2_global_arrays

2017-05-13T04:06:14+00:00

6.2.2 Global Arrays The global nature of some objects requires that they be accessible from any context. The firewall would ordinarily prevent these objects from being used in a flexible manner. The Java Card VM allows an object to be designated as global.

javacard:jcre:6.2.3_java_card_re_privileges

2017-05-13T04:06:15+00:00

6.2.3 Java Card RE Privileges Because it is the “system” context, the Java Card RE context has a special privilege. It can invoke a method of any object on the card. For example, assume that object X is owned by applet A. Normally, only the context of A can access the fields and methods of X. But the Java Card RE context is allowed to invoke any of the methods of X. During such an invocation, a context switch occurs from the Java Card RE context to the context of the applet that owns X.

javacard:jcre:6.2.4.1_server_applet_a_builds_a_shareable_interface_object

2017-05-13T04:06:17+00:00

6.2.4.1 Server Applet A Builds a Shareable Interface Object 1. To make an object available for sharing with another applet in a different context, applet A first defines a shareable interface, SI. A shareable interface extends the interface javacard.framework.Shareable

javacard:jcre:6.2.4.2_client_applet_b_obtains_the_shareable_interface_object

2017-05-13T04:06:17+00:00

6.2.4.2 Client Applet B Obtains the Shareable Interface Object 1. To access applet A's object O, applet B creates an object reference SIO of type SI. 2. Applet B invokes a special method (JCSystem.getAppletShareableInterfaceObject, described in Section 6.2.7.2, JCSystem.getAppletShareableInterfaceObject Method) to request a shared interface object reference from applet A.

javacard:jcre:6.2.4.3_client_applet_b_requests_services_from_applet_a

2017-05-13T04:06:19+00:00

6.2.4.3 Client Applet B Requests Services from Applet A 1. Applet B can request service from applet A by invoking one of the shareable interface methods of SIO. During the invocation the Java Card VM performs a context switch. The original currently active context (B) is saved on a stack and the context of the owner (A) of the actual object (O) becomes the new currently active context. A's implementation of the shareable interface method (SI method) executes in A's context.

javacard:jcre:6.2.4_shareable_interfaces

2017-05-13T04:06:19+00:00

6.2.4 Shareable Interfaces Shareable interfaces are a feature in the Java Card API to enable applet interaction. A shareable interface defines a set of shared interface methods. These interface methods can be invoked from one context even if the object implementing them is owned by an applet in another context.

javacard:jcre:6.2.5.1_java_card_re_context

2017-05-13T04:06:20+00:00

6.2.5.1 Java Card RE Context The Java Card RE context does not have an AID. If an applet calls the getPreviousContextAID method when the context of the applet was entered directly from the Java Card RE context, this method returns null. If the applet calls

javacard:jcre:6.2.5_determining_the_previous_context

2017-05-13T04:06:21+00:00

6.2.5 Determining the Previous Context When an applet calls JCSystem.getPreviousContextAID, the Java Card RE shall return the instance AID of the applet instance active at the time of the last context switch.

javacard:jcre:6.2.6.1_java_card_api_shareable_interface

2017-05-13T04:06:22+00:00

6.2.6.1 Java Card API Shareable Interface Interfaces extending the Shareable tagging interface have this special property: Calls to the interface methods take place across Java Card platform's applet firewall boundary by means of a context switch.

javacard:jcre:6.2.6_shareable_interface_details

2017-05-13T04:06:23+00:00

6.2.6 Shareable Interface Details A shareable interface is simply one that extends (either directly or indirectly) the tagging interface javacard.framework.Shareable. This Shareable interface is similar in concept to the Remote interface used by the RMI facility, in which calls to the interface methods take place across a local/remote boundary.

javacard:jcre:6.2.7.1_applet.getshareableinterfaceobject_aid_byte_method

2017-05-13T04:06:23+00:00

6.2.7.1 Applet.getShareableInterfaceObject(AID, byte) Method This method is implemented by the server applet instance. It shall be called by the Java Card RE to mediate between a client applet that requests to use an object belonging to another applet, and the server applet that makes its objects available for sharing.

javacard:jcre:6.2.7.2_jcsystem.getappletshareableinterfaceobject_method

2017-05-13T04:06:25+00:00

6.2.7.2 JCSystem.getAppletShareableInterfaceObject Method The JCSystem class contains the method getAppletShareableInterfaceObject, which is invoked by a client applet to communicate with a server applet. The Java Card RE shall implement this method to behave as follows:

javacard:jcre:6.2.7_obtaining_shareable_interface_objects

2017-05-13T04:06:25+00:00

6.2.7 Obtaining Shareable Interface Objects Inter-applet communication is accomplished when a client applet invokes a shareable interface method of a SIO belonging to a server applet. For this to work, there must be a way for the client applet to obtain the SIO from the server applet in the first place. The Java Card RE provides a mechanism to make this possible. The

javacard:jcre:6.2.8.1_accessing_static_class_fields

2017-05-13T04:08:30+00:00

6.2.8.1 Accessing Static Class Fields Bytecodes: getstatic, putstatic * If the Java Card RE is the currently active context, access is allowed. * Otherwise, if the bytecode is putstatic and the field being stored is a reference type and the reference being stored is a reference to a temporary Java Card RE Entry Point Object or a global array, access is denied.

javacard:jcre:6.2.8.2_accessing_array_objects

2017-05-13T04:08:32+00:00

6.2.8.2 Accessing Array Objects Bytecodes: aload, astore, arraylength, checkcast, instanceof * If the Java Card RE is the currently active context, access is allowed. * Otherwise, if the bytecode is aastore and the component being stored is a reference type and the reference being stored is a reference to a temporary Java Card RE Entry Point Object or a global array, access is denied.

javacard:jcre:6.2.8.3_accessing_class_instance_object_fields

2017-05-13T04:08:32+00:00

6.2.8.3 Accessing Class Instance Object Fields Bytecodes: getfield, putfield * If the Java Card RE is the currently active context, access is allowed. * Otherwise, if the bytecode is putfield and the field being stored is a reference type and the reference being stored is a reference to a temporary Java Card RE Entry Point Object or a global array, access is denied.

javacard:jcre:6.2.8.4_accessing_class_instance_object_methods

2017-05-13T04:08:33+00:00

6.2.8.4 Accessing Class Instance Object Methods Bytecodes: invokevirtual * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is designated a Java Card RE Entry Point Object, access is allowed. Context is switched to the object owner's context (shall be Java Card RE).

javacard:jcre:6.2.8.5_accessing_standard_interface_methods

2017-05-13T04:08:33+00:00

6.2.8.5 Accessing Standard Interface Methods Bytecodes: invokeinterface * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is designated a Java Card RE Entry Point Object, access is allowed. Context is switched to the object owner's context (shall be Java Card RE).

javacard:jcre:6.2.8.6_accessing_shareable_interface_methods

2017-05-13T04:08:35+00:00

6.2.8.6 Accessing Shareable Interface Methods Bytecodes: invokeinterface * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is owned by a non-multiselectable applet instance that is not in the context of the currently selected applet instance, and that is active on another logical channel, access is denied. See

javacard:jcre:6.2.8.7_throwing_exception_objects

2017-05-13T04:08:35+00:00

6.2.8.7 Throwing Exception Objects Bytecodes: athrow * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is designated a Java Card RE Entry Point Object, access is allowed.

javacard:jcre:6.2.8.8_accessing_classes

2017-05-13T04:08:36+00:00

6.2.8.8 Accessing Classes Bytecodes: checkcast, instanceof * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is designated a Java Card RE Entry Point Object, access is allowed.

javacard:jcre:6.2.8.9_accessing_standard_interfaces

2017-05-13T04:08:36+00:00

6.2.8.9 Accessing Standard Interfaces Bytecodes: checkcast, instanceof * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object is designated a Java Card RE Entry Point Object, access is allowed.

javacard:jcre:6.2.8.10_accessing_shareable_interfaces

2017-05-13T04:07:06+00:00

6.2.8.10 Accessing Shareable Interfaces Bytecodes: checkcast, instanceof * If the object is owned by an applet in the currently active context, access is allowed. * Otherwise, if the object's class implements a Shareable interface, and if the object is being cast into (

javacard:jcre:6.2.8.11_accessing_array_object_methods

2017-05-13T04:08:30+00:00

6.2.8.11 Accessing Array Object Methods Note - The method access behavior of global arrays is identical to that of Java Card RE Entry Point Objects. Bytecodes: invokevirtual * If the array is owned by an applet in the currently active context, access is allowed.

javacard:jcre:6.2.8_class_and_object_access_behavior

2017-05-13T04:07:08+00:00

6.2.8 Class and Object Access Behavior A static class field is accessed when one of the following Java programming language bytecodes is executed: getstatic, putstatic An object is accessed when one of the following Java programming language bytecodes is executed using the object's reference:

javacard:jcre:6.2_object_access_across_contexts

2017-05-13T04:07:51+00:00

6.2 Object Access Across Contexts The applet firewall confines an applets actions to its designated context. To enable applets to interact with each other and with the Java Card RE, some well-defined yet secure mechanisms are provided so one context can access an object belonging to another context.

javacard:jcre:6._applet_isolation_and_object_sharing

2017-05-13T04:07:52+00:00

6. Applet Isolation and Object Sharing Any implementation of the Java Card RE shall support isolation of contexts and applets. Isolation means that one applet cannot access the fields or objects of an applet in another context unless the other applet explicitly provides an interface for access. The Java Card RE mechanisms for applet isolation and object sharing are detailed in the following sections.

javacard:jcre:7.1_atomicity

2017-05-13T04:07:53+00:00

7.1 Atomicity Atomicity defines how the card handles the contents of persistent storage after a stop, failure, or fatal exception during an update of a single object or class field or array component. If power is lost during the update, the applet developer shall be able to rely on what the field or array component contains when power is restored.

javacard:jcre:7.2_transactions

2017-05-13T04:07:54+00:00

7.2 Transactions An applet might need to atomically update several different fields or array components in several different objects. Either all updates take place correctly and consistently, or else all fields or components are restored to their previous values.

javacard:jcre:7.3_transaction_duration

2017-05-13T04:07:54+00:00

7.3 Transaction Duration A transaction always ends when the Java Card RE regains programmatic control upon return from the applet's select, deselect, process, uninstall, or install methods. This is true whether a transaction ends normally, with an applet's call to

javacard:jcre:7.4_nested_transactions

2017-05-13T04:07:55+00:00

7.4 Nested Transactions The model currently assumes that nested transactions are not possible. There can be only one transaction in progress at a time. If JCSystem.beginTransaction is called while a transaction is already in progress, a TransactionException

javacard:jcre:7.5_tear_or_reset_transaction_failure

2017-05-13T04:07:56+00:00

7.5 Tear or Reset Transaction Failure If power is lost (tear) or the card is reset or some other system failure occurs while a transaction is in progress, the Java Card RE shall restore to their previous values all fields and array components conditionally updated since the previous call to

javacard:jcre:7.6.1_programmatic_abortion

2017-05-13T04:07:57+00:00

7.6.1 Programmatic Abortion If an applet encounters an internal problem or decides to cancel the transaction, it can programmatically undo conditional updates by calling JCSystem.abortTransaction. If this method is called, all conditionally updated fields and array components since the previous call to

javacard:jcre:7.6.2_abortion_by_the_java_card_re

2017-05-13T04:07:58+00:00

7.6.2 Abortion by the Java Card RE If an applet returns from the select, deselect, process, or install methods when an applet initiated transaction is in progress, the Java Card RE automatically aborts the transaction and proceeds as if an uncaught exception was thrown.

javacard:jcre:7.6.3_cleanup_responsibilities_of_the_java_card_re

2017-05-13T04:07:58+00:00

7.6.3 Cleanup Responsibilities of the Java Card RE Object instances created during the transaction that is being aborted can be deleted only if references to these deleted objects can no longer be used to access these objects. The Java Card RE shall ensure that a reference to an object created during the aborted transaction is equivalent to a

javacard:jcre:7.6_aborting_a_transaction

2017-05-13T04:07:59+00:00

7.6 Aborting a Transaction Transactions can be aborted either by an applet or by the Java Card RE. Note - The contents of an array component that is updated using the Util.arrayCopyNonAtomic method or the Util.arrayFillNonAtomic method while a transaction is in progress are not predictable following the abortion of the transaction.

javacard:jcre:7.7_transient_objects_and_global_arrays

2017-05-13T04:08:00+00:00

7.7 Transient Objects and Global Arrays Only updates to persistent objects participate in the transaction. Updates to transient objects and global arrays are never undone, regardless of whether or not they were “inside a transaction.”

javacard:jcre:7.8_commit_capacity

2017-05-13T04:08:01+00:00

7.8 Commit Capacity Because platform resources are limited, the number of bytes of conditionally updated data that can be accumulated during a transaction is limited. The Java Card technology provides methods to determine how much commit capacity is available on the implementation. The commit capacity represents an upper bound on the number of conditional byte updates available. The actual number of conditional byte updates available may be lower due to management overhead.

javacard:jcre:7.9_context_switching

2017-05-13T04:08:01+00:00

7.9 Context Switching Context switches shall not alter the state of a transaction in progress. If a transaction is in progress at the time of a context switch (see Section 6.1.2, Contexts and Context Switching), updates to persistent data continue to be conditional in the new context until the transaction is committed or aborted.

javacard:jcre:7._transactions_and_atomicity

2017-05-13T04:08:03+00:00

7. Transactions and Atomicity A transaction is a logical set of updates of persistent data. For example, transferring some amount of money from one account to another is a banking transaction. It is important for transactions to be atomic: Either all of the data fields are updated, or none are. The Java Card RE provides robust support for atomic transactions, so that card data is restored to its original pre-transaction state if the transaction does not complete normally. This mechanism protect…

javacard:jcre:8.1.1.1_parameters_and_return_values

2017-05-13T04:07:08+00:00

8.1.1.1 Parameters and Return Values The parameters of a remote method must only include parameters of the following types: * Any supported primitive data types * Any single-dimension array of a supported primitive data type The return value of a remote method must only be one of the following types:

javacard:jcre:8.1.1.2_exceptions

2017-05-13T04:06:40+00:00

8.1.1.2 Exceptions Java Card RMI uses the following simplified model for returning exceptions thrown by remote methods: * When an exception defined in the Java Card API is thrown by a remote method, the exact exception type and the embedded reason code is transmitted to the client application. In essence, the exception object is transmitted by value.

javacard:jcre:8.1.1.3_functional_limitations

2017-05-13T04:06:41+00:00

8.1.1.3 Functional Limitations The definition of the supported subset of Java Card RMI for the Java Card Platform, Version 2.2.2, implies functional limitations during the execution of Java Card API remote methods: * CAD client application remote objects cannot be passed as arguments to remote methods.

javacard:jcre:8.1.1_remote_objects

2017-05-13T04:06:42+00:00

8.1.1 Remote Objects A remote object is one whose remote methods can be invoked remotely from the CAD client. A remote object is described by one or more remote interfaces. A remote interface is an interface that extends, directly or indirectly, the interface

javacard:jcre:8.1_java_card_platform_rmi

2017-05-13T04:06:43+00:00

8.1 Java Card Platform RMI This section defines the subset of the RMI system that is supported by Java Card platform RMI.

javacard:jcre:8.2.1_applet_selection

2017-05-13T04:06:44+00:00

8.2.1 Applet Selection The selection command used to retrieve the initial reference is the ISO 7816-4 SELECT FILE command, with the following options in the header: * Direct selection by DF Name, that is, selection by AID. This is the normal option used to select all applet instances in the Java Card platform.

javacard:jcre:8.2.2_method_invocation

2017-05-13T04:06:45+00:00

8.2.2 Method Invocation To request a method invocation, the CAD client provides the following information: * The remote object identifier. This identifier is used to uniquely identify the object on the card. * The invoked method identifier. This designator uniquely identifies the remote method within the remote object class or superclass.

javacard:jcre:8.2_rmi_messages

2017-05-13T04:06:45+00:00

8.2 RMI Messages The Java Card RMI message protocol consists of two commands that are used to: * Get the initial remote object reference for the Java Card RMI based applet. The initial remote object reference is the seed remote object that the CAD client application needs to begin remote method invocations.

javacard:jcre:8.3.1_remote_object_identifier

2017-05-13T04:06:46+00:00

8.3.1 Remote Object Identifier A remote object identifier is a 16-bit unsigned number that uniquely identifies a remote object on the card.

javacard:jcre:8.3.2_remote_object_reference_descriptor

2017-05-13T04:06:47+00:00

8.3.2 Remote Object Reference Descriptor The remote object reference descriptor includes the remote object identifier, as well as information to instantiate the proxy class on the CAD client. The remote object reference descriptor uses one of two alternate formats. The representation based on the name of the class uses the

javacard:jcre:8.3.3_method_identifier

2017-05-13T04:06:48+00:00

8.3.3 Method Identifier A method identifier is always used in association with a remote object reference. A method identifier is defined as follows: u2 method_id The method_id is a unique 16-bit hashcode identifier of the remote method within the remote class. This 16-bit hashcode consists of the first two bytes of the SHA-1 message digest function performed on a class specific hash modifier string, followed by the name of the method, followed by the method descriptor representation in UTF-8…

javacard:jcre:8.3.4.1_primitive_data_type_parameter_encoding

2017-05-13T04:06:49+00:00

8.3.4.1 Primitive Data Type Parameter Encoding Primitive data types void, boolean, byte, short and int are respectively encoded as follows: The boolean_value field may only take the values 0 (for false) and 1 (for true). All the other fields can take any value in their range.

javacard:jcre:8.3.4.2_array_parameter_encoding

2017-05-13T04:06:50+00:00

8.3.4.2 Array Parameter Encoding The representation of the null array parameter and arrays of the boolean, byte, short and int component types include the length information and are respectively encoded as follows: Note - The length field in each of this array data structure represents the number of elements of the array, not its size in bytes.

javacard:jcre:8.3.4_parameter_encoding

2017-05-13T04:06:51+00:00

8.3.4 Parameter Encoding Every parameter has the following generic format:

javacard:jcre:8.3.5.1_normal_response_encoding

2017-05-13T04:06:52+00:00

8.3.5.1 Normal Response Encoding A normal response encapsulates primitive return types, arrays of primitive data types using the same format for the param item, as described in Section 8.3.4, Parameter Encoding, using the following format: The null_array_param format described in

javacard:jcre:8.3.5.2_exception_response_encoding

2017-05-13T04:06:53+00:00

8.3.5.2 Exception Response Encoding Following is the encoding when an API defined exception is thrown by the remote method. It may be returned during any remote method invocation. The reason item is the Java Card platform exception reason code, or 0

javacard:jcre:8.3.5.3_error_response_encoding

2017-05-13T04:06:53+00:00

8.3.5.3 Error Response Encoding The following encoding represents an error condition on the card. The error may occur due to marshalling, unmarshalling or resource-related problems. Following are the values of the error_detail item: * The Remote Object Identifier is invalid or ineligible for Java Card RMI

javacard:jcre:8.3.5_return_value_encoding

2017-05-13T04:06:55+00:00

8.3.5 Return Value Encoding A return value may be any of the parameter types described in the previous section encapsulated within a normal response format. In addition, the return value may represent a remote object reference type, a null return type, various exceptions and the error type.

javacard:jcre:8.3_data_formats

2017-05-13T04:06:55+00:00

8.3 Data Formats This section describes the formats used to encapsulate the following: * A remote object identifier that identifies the remote object on the card. * A remote object reference descriptor that describes the remote object on the card for the CAD client.

javacard:jcre:8.4.1_select_file_command

2017-05-13T04:06:57+00:00

8.4.1 SELECT FILE Command TABLE 8-1 lists the formats required for the Select command for an RMI-based applet. Note - (%b) indicates binary notation using bit numbering as in the ISO 7816 specification. The most significant bit is b8. The least significant bit is b1. An

javacard:jcre:8.4.2_invoke_command

2017-05-13T04:06:57+00:00

8.4.2 INVOKE Command TABLE 8-2 lists the format required for the Invoke command for a remote method invocation request. Field Value Description CLA %b1000 yycc or %b1010 yycc or %b11y0 dddd The cc in bits (b2,b1) denotes the origin logical channel number in the range 1-3. The

javacard:jcre:8.4_apdu_command_formats

2017-05-13T04:06:59+00:00

8.4 APDU Command Formats Section 8.3, Data Formats described the various elements included in the data portion of the Java Card RMI messages. This section describes the complete format of the APDU commands: the header as well as the data portion containing the message elements described earlier.

javacard:jcre:8.5.1_setinvokeinstructionbyte_method

2017-05-13T04:06:59+00:00

8.5.1 setInvokeInstructionByte Method This method sets the value of invoke_ins described in Section 8.4.1, SELECT FILE Command, which is returned in the response to the SELECT FILE command. The change in the Java Card RMI protocol only goes into effect the next time this RMIService instance processes the SELECT FILE command. If this method is not called, the default instruction byte value (

javacard:jcre:8.5.2_processcommand_method

2017-05-13T04:07:00+00:00

8.5.2 processCommand Method The processCommand method of the RMIService class is invoked by the applet to process an incoming RMI message. RMIService collaborates with other services by using the common service format (CSF) in the APDU buffer. It processes only the incoming Java Card RMI APDU commands and produces output as described in the previous sections.

javacard:jcre:8.5_rmiservice_class

2017-05-13T04:07:01+00:00

8.5 RMIService Class The RMIService class implements the Java Card RMI protocol and processes the RMI access commands described earlier: SELECT FILE and INVOKE. It performs the function of the transport layer for Java Card RMI commands on the card.

javacard:jcre:8._remote_method_invocation_service

2017-05-13T04:07:09+00:00

8. Remote Method Invocation Service Java Card platform Remote Method Invocation (Java Card RMI) is a subset of the Java platform Remote Method Invocation (RMI) system. It provides a mechanism for a client application running on the CAD platform to invoke a method on a remote object on the card. The on-card transport layer for Java Card RMI is provided in the package

javacard:jcre:9.1_resource_use_within_the_api

2017-05-13T04:07:33+00:00

9.1 Resource Use Within the API Unless specified in the Application Programming Interface, Java Card Platform, Version 2.2.2, the implementation shall support the invocation of API instance methods, even when the owner of the object instance is not the currently selected applet. Unless specifically called out, the implementation shall not use resources such as transient objects of

javacard:jcre:9.2_exceptions_thrown_by_api_classes

2017-05-13T04:07:34+00:00

9.2 Exceptions Thrown by API Classes All exception objects thrown by the API implementation shall be temporary Java Card RE Entry Point Objects. Temporary Java Card RE Entry Point Objects cannot be stored in class variables, instance variables, or array components (see

javacard:jcre:9.3_transactions_within_the_api

2017-05-13T04:07:34+00:00

9.3 Transactions Within the API Unless explicitly called out in the API descriptions, implementation of the Java Card API methods shall not initiate or otherwise alter the state of a transaction in progress. Unless explicitly called out in the API

javacard:jcre:9.4.1.1_constrained_transfers_with_no_chaining

2017-05-13T04:07:36+00:00

9.4.1.1 Constrained Transfers With No Chaining When the no chaining mode of output transfer is requested by the applet by calling the setOutgoingNoChaining method, the following protocol sequence shall be followed: When the no chaining mode is used (that is, after the invocation of the

javacard:jcre:9.4.1.2_regular_output_transfers

2017-05-13T04:07:36+00:00

9.4.1.2 Regular Output Transfers When the no chaining mode of output transfer is not requested by the applet (that is, the setOutgoing method is used), any ISO/IEC 7816-3/4 compliant T=0 protocol transfer sequence may be used. Note - The waitExtension

javacard:jcre:9.4.1.3_additional_t_0_requirements

2017-05-13T04:07:37+00:00

9.4.1.3 Additional T=0 Requirements At any time, when the T=0 output transfer protocol is in use, and the APDU class is awaiting a GET RESPONSE command from the CAD in reaction to a response status of from the card, if the CAD sends in a different command on the same origin logical channel, or a command on a different origin logical channel, the

javacard:jcre:9.4.1_t_0_specifics_for_outgoing_data_transfers

2017-05-13T04:07:37+00:00

9.4.1 T=0 Specifics for Outgoing Data Transfers The setOutgoing and setOutgoingNoChaining methods in the APDU class are used to specify that data needs to be returned to the CAD. These methods return the expected length (Le) value as follows when extended length semantics are not enabled (see

javacard:jcre:9.4.2.1_constrained_transfers_with_no_chaining

2017-05-13T04:07:39+00:00

9.4.2.1 Constrained Transfers With No Chaining When the no chaining mode of output transfer is requested by the applet by calling the setOutgoingNoChaining method, the following protocol specifics shall be followed: Notation Le = CAD expected length.

javacard:jcre:9.4.2.2_regular_output_transfers

2017-05-13T04:07:39+00:00

9.4.2.2 Regular Output Transfers When the no chaining mode of output transfer is not requested by the applet (meaning, the setOutgoing method is used) any ISO/IEC 7816-3/4 compliant T=1 protocol transfer sequence may be used. Note - The waitExtension

javacard:jcre:9.4.2_t_1_specifics_for_outgoing_data_transfers

2017-05-13T04:07:40+00:00

9.4.2 T=1 Specifics for Outgoing Data Transfers The setOutgoing and setOutgoingNoChaining methods in the APDU class are used to specify that data needs to be returned to the CAD. These methods return the expected length (Le) value as follows when extended length semantics are not enabled (see

javacard:jcre:9.4.3.1_incoming_transfers_using_chaining

2017-05-13T04:07:41+00:00

9.4.3.1 Incoming Transfers Using Chaining Chain Abortion by the CAD If the CAD aborts a chained inbound transfer using an S-block ABORT request (see ISO/IEC 7816-3:2004), the setIncomingAndReceive or receiveBytes method shall throw an APDUException

javacard:jcre:9.4.3_t_1_specifics_for_incoming_data_transfers

2017-05-13T04:07:42+00:00

9.4.3 T=1 Specifics for Incoming Data Transfers

javacard:jcre:9.4.4.1_extended_length_api_semantics

2017-05-13T04:07:42+00:00

9.4.4.1 Extended Length API Semantics The following sections describe the semantics of the applet-visible API, which is enabled when the applet implements the javacardx.apdu.ExtendedLength interface. These semantics are presented at the API level to the extended length capable applet, only when the APDU received supports extended length format. Note that the maximum length that can be supported using extended length semantics by the Java Card technology

javacard:jcre:9.4.4_extended_length_apdu_specifics

2017-05-13T04:07:44+00:00

9.4.4 Extended Length APDU Specifics The card may support extended length APDU exchanges with the CAD as described in the ISO 7816-3 Specification. If the implementation does not support extended length APDU formats and an APDU with extended length is received by the card or an APDU with extended length value greater than 32767 is requested, the Java Card RE shall respond to the CAD with the error response status

javacard:jcre:9.4_apdu_class

2017-05-13T04:07:44+00:00

9.4 APDU Class The APDU class encapsulates access to the ISO 7816-4 based I/O across the card serial line. The APDU class is designed to be independent of the underlying I/O transport protocol. The Java Card RE may support T=0 or T=1 transport protocols or both.

javacard:jcre:9.5_security_and_crypto_packages

2017-05-13T04:07:46+00:00

9.5 Security and Crypto Packages The getInstance method in the following classes returns an implementation instance in the context of the calling applet of the requested algorithm: javacard.security.MessageDigest javacard.security.InitializedMessageDigest

javacard:jcre:9.6_jcsystem_class

2017-05-13T04:07:46+00:00

9.6 JCSystem Class In the Java Card platform, version 2.2.2, the getVersion method returns (short) 0x0202.

javacard:jcre:9.7_optional_extension_packages

2017-05-13T04:07:47+00:00

9.7 Optional Extension Packages Some API packages in the Java Card technology are designated as extension packages and may be optionally supported by an implementation. But, if supported, all the classes in the package and its subpackages must be implemented by the platform and reside on the card.

javacard:jcre:9._api_topics

2017-05-13T04:07:48+00:00

9. API Topics The topics in this chapter complement the requirements specified in the Application Programming Interface, Java Card Platform, Version 2.2.2.

javacard:jcre:10.1_resource_failures

2017-05-13T04:05:59+00:00

10.1 Resource Failures A lack of resources condition, such as heap space, that is recoverable shall result in a SystemException with reason code NO_RESOURCE. The factory methods in JCSystem used to create transient arrays throw a SystemException with reason code

javacard:jcre:10.2_security_violations

2017-05-13T04:06:00+00:00

10.2 Security Violations The Java Card RE throws a java.lang.SecurityException exception when it detects an attempt to illegally access an object belonging to another applet across the firewall boundary. A java.lang.SecurityException exception may optionally be thrown by a Java Card VM implementation to indicate a violation of fundamental language restrictions, such as attempting to invoke a private method in another class.

javacard:jcre:10._virtual_machine_topics

2017-05-13T04:06:01+00:00

10. Virtual Machine Topics This chapter details virtual machine resource failures and security violations.

javacard:jcre:11.1.1_installer_implementation

2017-05-13T04:06:02+00:00

11.1.1 Installer Implementation The Installer need not be implemented as an applet on the card. The requirement is only that the Installer functionality be SELECTable. The corollary to this requirement is that Installer component shall not be able to be invoked on a logical channel on which a non-Installer applet is an active applet instance nor when no applet is active.

javacard:jcre:11.1.2_installer_aid

2017-05-13T04:06:03+00:00

11.1.2 Installer AID Because the Installer is SELECTable, it shall have an AID. Java Card RE implementers are free to choose their own AIDs by which their Installer is selected. Multiple installers may be implemented.

javacard:jcre:11.1.3_installer_apdus

2017-05-13T04:06:04+00:00

11.1.3 Installer APDUs The Java Card specification does not specify any APDUs for the Installer. Java Card RE implementers are free to choose their own APDU commands to direct their Installer in its work. The model is that the Installer on the card is initiated by an installation program running on the CAD. For installation to succeed, this CAD installation program shall be able to do the following:

javacard:jcre:11.1.4_cap_file_versions

2017-05-13T04:06:05+00:00

11.1.4 CAP File Versions The Installer shall support the following CAP file versions: * Version 2.1 as specified in the Java Card 2.1.1 Virtual Machine Specification. * Version 2.2 as specified in the Virtual Machine Specification, Java Card Platform, Version 2.2.2

javacard:jcre:11.1.5_installer_behavior

2017-05-13T04:06:05+00:00

11.1.5 Installer Behavior Java Card RE implementers shall also define other behaviors of their Installer, including the following: * Whether or not installation can be aborted and how this is done * What happens if an exception, reset, or power fail occurs during installation

javacard:jcre:11.1.6_installer_privileges

2017-05-13T04:06:07+00:00

11.1.6 Installer Privileges Although an Installer may be implemented as an applet, an Installer typically requires access to features that are not available to other applets. For example, depending on the Java Card RE implementer's implementation, the Installer will need to do the following tasks:

javacard:jcre:11.1_the_installer

2017-05-13T04:06:07+00:00

11.1 The Installer The mechanisms necessary to install an applet on smart cards using Java Card technology are embodied in an on-card component called the Installer. To the CAD the Installer appears to be an applet. It has an AID, and it becomes the currently selected applet when this AID is successfully processed by a SELECT FILE command. Once selected on a logical channel, the Installer behaves in much the same way as any other applet, as follows:

javacard:jcre:11.2.1_installation_parameters

2017-05-13T04:06:09+00:00

11.2.1 Installation Parameters The format of the input data passed to the target applet's install method in the bArray parameter is as follows: bArray[offset] = length(Li) of instance AID bArray[offset+1..offset+Li] = instance AID bytes (5-16 bytes)

javacard:jcre:11.2_the_newly_installed_applet

2017-05-13T04:06:09+00:00

11.2 The Newly Installed Applet A single interface exists between the Installer and the applet that is being installed. After the Installer correctly prepares the applet for execution (performed steps such as loading and linking), the Installer shall invoke the applet's

javacard:jcre:11.3.1_applet_deletion_manager_implementation

2017-05-13T04:06:10+00:00

11.3.1 Applet Deletion Manager Implementation The Applet Deletion Manager need not be implemented as an applet on the card. The requirement is only that the Applet Deletion Manager functionality be SELECTable. The corollary to this requirement is that Applet Deletion Manager component shall not be able to be invoked on a logical channel where a non-Applet Deletion Manager applet is an active applet instance, nor when no applet is active.

javacard:jcre:11.3.2_applet_deletion_manager_aid

2017-05-13T04:06:11+00:00

11.3.2 Applet Deletion Manager AID Because the Applet Deletion Manager is SELECTable, it shall have an AID which may be the same as that of the Applet Installer. Java Card RE implementers are free to choose their own AIDs by which their Applet Deletion Manager is selected. Multiple Applet Deletion Managers may be implemented.

javacard:jcre:11.3.3_applet_deletion_manager_apdus

2017-05-13T04:06:12+00:00

11.3.3 Applet Deletion Manager APDUs The Java Card API does not specify any APDUs for the Applet Deletion Manager. Java Card RE implementers are entirely free to choose their own APDU commands to direct their Applet Deletion Manager in its work.

javacard:jcre:11.3.4.1_applet_instance_deletion

2017-05-13T04:07:03+00:00

11.3.4.1 Applet Instance Deletion The Java Card RE shall guarantee that applet instance deletion is not attempted and thereby deemed unsuccessful in the following cases: * An object owned by the applet instance is referenced from an object owned by another applet instance on the card.

javacard:jcre:11.3.4.2_applet_library_package_deletion

2017-05-13T04:08:04+00:00

11.3.4.2 Applet/Library Package Deletion The Java Card RE shall guarantee that applet/library package deletion is not attempted and thereby deemed unsuccessful in the following cases: * A reachable (non-garbage) instance of a class belonging to the package being deleted exists on the card.

javacard:jcre:11.3.4.3_applet_package_and_contained_instances_deletion

2017-05-13T04:08:05+00:00

11.3.4.3 Applet Package and Contained Instances Deletion The Java Card RE shall guarantee that deletion of the applet package and contained instances is not attempted and thereby deemed unsuccessful in the following cases: * Another package on the card depends on this package (as expressed in the CAP file's import component).

javacard:jcre:11.3.4_applet_deletion_manager_behavior

2017-05-13T04:08:09+00:00

11.3.4 Applet Deletion Manager Behavior Java Card RE implementers shall also define other behaviors of their Applet Deletion Manager, including the following: * Whether or not applet deletion can be aborted and how this is done * What happens if an exception, reset, or power fail occurs during applet deletion

javacard:jcre:11.3.5_applet_deletion_manager_privileges

2017-05-13T04:08:09+00:00

11.3.5 Applet Deletion Manager Privileges Although an Applet Deletion Manager may be implemented as an applet, an Applet Deletion Manager typically requires access to features that are not available to other applets. For example, depending on the Java Card RE implementer's implementation, the Applet Deletion Manager needs to do the following:

javacard:jcre:11.3_the_applet_deletion_manager

2017-05-13T04:08:10+00:00

11.3 The Applet Deletion Manager The mechanisms necessary to delete an applet on smart cards using Java Card technology are embodied in an on-card component called the Applet Deletion Manager. To the CAD, the Applet Deletion Manager appears to be an applet, and may be one and the same as the Applet Installer. It has an AID, and it becomes the currently selected applet instance when this AID is successfully processed by a SELECT FILE command. Once selected on a logical channel, the Applet Del…

javacard:jcre:11._applet_installation_and_deletion

2017-05-13T04:08:11+00:00

11. Applet Installation and Deletion Applet installation and deletion on smart cards using Java Card technology is a complex topic. The design of the Application Programming Interface, Java Card Platform, Version 2.2.2 is intended to give Java Card RE implementers as much freedom as possible in their implementations. However, some basic common specifications are required to allow Java Card applets to be installed and deleted without knowing the implementation details of a particular installer o…

javacard:jcre:12.1_class_javacard.framework.apdu

2017-05-13T04:07:03+00:00

12.1 Class javacard.framework.APDU public static final byte PROTOCOL_TYPE_MASK = (byte)0x0F; public static final byte PROTOCOL_T0 = 0; public static final byte PROTOCOL_T1 = 1; public static final byte PROTOCOL_MEDIA_MASK = (byte)0xF0; public static final byte PROTOCOL_MEDIA_DEFAULT = (byte)0x00;

javacard:jcre:12.2_class_javacard.framework.apduexception

2017-05-13T04:06:34+00:00

12.2 Class javacard.framework.APDUException public static final short ILLEGAL_USE = 1; public static final short BUFFER_BOUNDS = 2; public static final short BAD_LENGTH = 3; public static final short IO_ERROR = 4; public static final short NO_T0_GETRESPONSE = 0xAA;

javacard:jcre:12.3_interface_javacard.framework.iso7816

2017-05-13T04:06:35+00:00

12.3 Interface javacard.framework.ISO7816 public final static short SW_NO_ERROR = (short)0x9000; public final static short SW_BYTES_REMAINING_00 = 0x6100; public final static short SW_WARNING_STATE_UNCHANGED = 0x6200; public final static short SW_WRONG_LENGTH = 0x6700;

javacard:jcre:12.4_class_javacard.framework.jcsystem

2017-05-13T04:06:36+00:00

12.4 Class javacard.framework.JCSystem public static final byte NOT_A_TRANSIENT_OBJECT = 0; public static final byte CLEAR_ON_RESET = 1; public static final byte CLEAR_ON_DESELECT = 2; public static final byte MEMORY_TYPE_PERSISTENT = 0; public static final byte MEMORY_TYPE_TRANSIENT_RESET = 1;

javacard:jcre:12.5_class_javacard.framework.pinexception

2017-05-13T04:06:37+00:00

12.5 Class javacard.framework.PINException public static final short ILLEGAL_VALUE = 1;

javacard:jcre:12.6_class_javacard.framework.systemexception

2017-05-13T04:06:38+00:00

12.6 Class javacard.framework.SystemException public static final short ILLEGAL_VALUE = 1; public static final short NO_TRANSIENT_SPACE = 2; public static final short ILLEGAL_TRANSIENT = 3; public static final short ILLEGAL_AID = 4; public static final short NO_RESOURCE = 5;

javacard:jcre:12.7_class_javacard.framework.transactionexception

2017-05-13T04:06:40+00:00

12.7 Class javacard.framework.TransactionException public static final short IN_PROGRESS = 1; public static final short NOT_IN_PROGRESS = 2; public static final short BUFFER_FULL = 3; public static final short INTERNAL_FAILURE = 4;

javacard:jcre:12.8_class_javacard.framework.service.dispatcher

2017-05-13T04:07:04+00:00

12.8 Class javacard.framework.service.Dispatcher public static final byte PROCESS_NONE = (byte)0; public static final byte PROCESS_INPUT_DATA = (byte)1; public static final byte PROCESS_COMMAND= (byte)2; public static final byte PROCESS_OUTPUT_DATA = (byte)3;

javacard:jcre:12.9_class_javacard.framework.service.rmiservice

2017-05-13T04:08:21+00:00

12.9 Class javacard.framework.service.RMIService public static final byte DEFAULT_RMI_INVOKE_INSTRUCTION = 0x38;

javacard:jcre:12.10_class_javacard.framework.service.serviceexception

2017-05-13T04:08:12+00:00

12.10 Class javacard.framework.service.ServiceException public static final short ILLEGAL_PARAM = 1; public static final short DISPATCH_TABLE_FULL = 2; public static final short COMMAND_DATA_TOO_LONG = 3; public static final short CANNOT_ACCESS_IN_COMMAND = 4 ;

javacard:jcre:12.11_class_javacard.security.checksum

2017-05-13T04:08:13+00:00

12.11 Class javacard.security.Checksum public static final byte ALG_ISO3309_CRC16 = 1; public static final byte ALG_ISO3309_CRC32 = 2;

javacard:jcre:12.12_class_javacard.security.cryptoexception

2017-05-13T04:08:14+00:00

12.12 Class javacard.security.CryptoException public static final short ILLEGAL_VALUE = 1; public static final short UNINITIALIZED_KEY = 2; public static final short NO_SUCH_ALGORITHM = 3; public static final short INVALID_INIT = 4; public static final short ILLEGAL_USE = 5;

javacard:jcre:12.13_class_javacard.security.keyagreement

2017-05-13T04:08:14+00:00

12.13 Class javacard.security.KeyAgreement public static final byte ALG_EC_SVDP_DH = 1; public static final byte ALG_EC_SVDP_DHC = 2;

javacard:jcre:12.14_class_javacard.security.keybuilder

2017-05-13T04:08:15+00:00

12.14 Class javacard.security.KeyBuilder public static final byte TYPE_DES_TRANSIENT_RESET = 1; public static final byte TYPE_DES_TRANSIENT_DESELECT = 2; public static final byte TYPE_DES = 3; public static final byte TYPE_RSA_PUBLIC = 4; public static final byte TYPE_RSA_PRIVATE = 5;

javacard:jcre:12.15_class_javacard.security.keypair

2017-05-13T04:08:16+00:00

12.15 Class javacard.security.KeyPair public static final byte ALG_RSA = 1; public static final byte ALG_RSA_CRT = 2; public static final byte ALG_DSA = 3; public static final byte ALG_EC_F2M = 4; public static final byte ALG_EC_FP = 5;

javacard:jcre:12.16_class_javacard.security.messagedigest

2017-05-13T04:08:17+00:00

12.16 Class javacard.security.MessageDigest public static final byte ALG_SHA = 1; public static final byte ALG_MD5 = 2; public static final byte ALG_RIPEMD160 = 3; public static final byte ALG_SHA_256 = 4; public static final byte ALG_SHA_384 = 5;

javacard:jcre:12.17_class_javacard.security.randomdata

2017-05-13T04:08:18+00:00

12.17 Class javacard.security.RandomData public static final byte ALG_PSEUDO_RANDOM = 1; public static final byte ALG_SECURE_RANDOM = 2;

javacard:jcre:12.18_class_javacard.security.signature

2017-05-13T04:08:19+00:00

12.18 Class javacard.security.Signature public static final byte ALG_DES_MAC4_NOPAD = 1; public static final byte ALG_DES_MAC8_NOPAD = 2; public static final byte ALG_DES_MAC4_ISO9797_M1 = 3; public static final byte ALG_DES_MAC8_ISO9797_M1 = 4;

javacard:jcre:12.19_class_javacardx.biometry.biobuilder

2017-05-13T04:08:20+00:00

12.19 Class javacardx.biometry.BioBuilder public static final byte FACIAL_FEATURE=(byte)1; public static final byte VOICE_PRINT = (byte)2; public static final byte FINGERPRINT = (byte)3; public static final byte IRIS_SCAN= (byte)4; public static final byte RETINA_SCAN = (byte)5;

javacard:jcre:12.20_class_javacardx.biometry.bioexception

2017-05-13T04:06:26+00:00

12.20 Class javacardx.biometry.BioException public static final short ILLEGAL_VALUE = (short)1; public static final short INVALID_DATA = (short)2; public static final short NO_SUCH_BIO_TEMPLATE = (short)3; public static final short NO_TEMPLATES_ENROLLED = (short)4;

javacard:jcre:12.21_class_javacardx.biometry.biotemplate

2017-05-13T04:06:27+00:00

12.21 Class javacardx.biometry.BioTemplate public static final short MINIMUM_SUCCESSFUL_MATCH_SCORE =(short)16384; public static final short MATCH_NEEDS_MORE_DATA =(short)-1;

javacard:jcre:12.22_class_javacardx.crypto.cipher

2017-05-13T04:06:28+00:00

12.22 Class javacardx.crypto.Cipher public static final byte ALG_DES_CBC_NOPAD = 1; public static final byte ALG_DES_CBC_ISO9797_M1 = 2; public static final byte ALG_DES_CBC_ISO9797_M2 = 3; public static final byte ALG_DES_CBC_PKCS5 = 4; public static final byte ALG_DES_ECB_NOPAD = 5;

javacard:jcre:12.23_class_javacardx.external.externalexeption

2017-05-13T04:06:29+00:00

12.23 Class javacardx.external.ExternalExeption public static final short NO_SUCH_SUBSYSTEM = 1; public static final short INVALID_PARAM = 2; public static final short INTERNAL_ERROR = 3;

javacard:jcre:12.24_class_javacardx.external.memory

2017-05-13T04:06:30+00:00

12.24 Class javacardx.external.Memory public static final short MEMORY_TYPE_MIFARE = (short) 1; public static final short MEMORY_TYPE_EXTENDED_STORE = (short) 2;

javacard:jcre:12.25_class_javacardx.framework.math.bignumber

2017-05-13T04:06:30+00:00

12.25 Class javacardx.framework.math.BigNumber public static final byte FORMAT_BCD = (byte)1; public static final byte FORMAT_HEX = (byte)2;

javacard:jcre:12.26_class_javacardx.framework.tlv.bertag

2017-05-13T04:06:32+00:00

12.26 Class javacardx.framework.tlv.BERTag public static final byte BER_TAG_CLASS_UNIVERSAL = (byte)0; public static final byte BER_TAG_CLASS_APPLICATION = (byte)1; public static final byte BER_TAG_CLASS_CONTEXT_SPECIFIC = (byte)2; public static final byte BER_TAG_CLASS_PRIVATE = (byte)3;

javacard:jcre:12.27_class_javacardx.framework.tlv.tlvexception

2017-05-13T04:06:32+00:00

12.27 Class javacardx.framework.tlv.TLVException public static final short INVALID_PARAM = 1; public static final short ILLEGAL_SIZE = 2; public static final short EMPTY_TAG = 3; public static final short EMPTY_TLV = 4; public static final short MALFORMED_TAG = 5;

javacard:jcre:12.28_class_javacardx.framework.util.utilexception

2017-05-13T04:06:33+00:00

12.28 Class javacardx.framework.util.UtilException public static final short ILLEGAL_VALUE = 1; public static final short TYPE_MISMATCHED = 2; Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.

javacard:jcre:12._api_constants

2017-05-13T04:08:22+00:00

12. API Constants Some of the API classes do not have values specified for their constants in Application Programming Interface, Java Card Platform, Version 2.2.2. If constant values are not specified consistently by implementers of this Runtime Environment Specification, Java Card Platform, Version 2.2.2

javacard:jcre:glossary

2017-05-13T04:07:49+00:00

Glossary active applet instance an applet instance that is selected on at least one of the logical channels. AID (application identifier) defined by ISO 7816, a string used to uniquely identify card applications and certain types of files in card file systems. An AID consists of two distinct pieces: a 5-byte RID (resource identifier) and a 0 to 11-byte PIX (proprietary identifier extension). The RID is a resource identifier assigned to companies by ISO. The PIX identifiers are assigned b…

javacard:jcre:index

2017-05-13T04:07:50+00:00

Index A accessing array object methods, 1 array objects, 1 class instance object fields, 1 class instance object methods, 1 class instance objects, 1 objects, 1 across contexts, 1 shareable interface, 1 methods, 1 standard interface methods, 1 standard interfaces,

javacard:jcre:preface

2017-05-13T04:07:51+00:00

Preface Java Card technology combines a portion of the Java programming language with a runtime environment optimized for smart cards and related, small-memory embedded devices. The goal of Java Card technology is to bring many of the benefits of the Java programming language to the resource-constrained world of smart cards.