C H A P T E R 4 - Logical Channels and Applet Selection

C H A P T E R 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 ISO 7816-4:2005 Specification.

Cards receive requests for service from the CAD in the form of APDUs. The SELECT FILE APDU and MANAGE CHANNEL OPEN APDU are used by the Java Card RE to designate the active applet instance for a logical channel session. Once selected, an applet instance receives all subsequent APDUs dispatched to that logical channel, until the applet instance becomes deselected.

Some cards support only the contacted I/O interface conforming to ISO 7816 specifications, and some support only the contactless I/O interface based on the ISO 14443 specifications. Yet others are able to support both types of I/O interfaces. Logical channel sessions as described in this chapter may be supported over either interface. In addition, a card may be able to sustain logical channel sessions over both interfaces simultaneously.

An implementation may support between 1 and 20 logical channels over the contacted I/O interface. Similarly, an implementation may support between 1 and 20 logical channels over the contactless I/O interface. When both I/O interfaces are concurrently active, the number of logical channels supported on each of the two interfaces is also implementation specific.

Note - To establish a card session over both contacted and contactless interfaces concurrently, the CAD must initiate the contacted session first. A power loss or card reset on the contacted interface results in a card tear and card reset event even if a contactless session is in progress. An RF signal loss on the contactless interface must not affect an ongoing contacted session.

The Java Card RE processes APDUs sequentially whether received over the same I/O interface or over two different I/O interfaces. The I/O subsystem must present concurrently received APDUs to the Java Card RE command dispatcher sequentially. The arbitration required to make concurrently received APDU commands sequential, as well as the mechanisms used to ensure proper synchronization with the CAD (for contact) and with the proximity coupling device, PCD (for contactless), are not specified in this specification. The I/O subsystem must ensure that APDU commands received over the contactless I/O interface are given higher priority, but without causing a timeout on any concurrently received APDU command over the contacted I/O interface. The algorithm used for this purpose is not specified in this specification.

A new applet written for version 2.2.* of the Java Card platform can be designed to take advantage of logical channel support. Such an applet can take advantage of multi-session functionality, can be concurrently selected alongside another applet on a different logical channel, and even be selected multiple times simultaneously on different logical channels. As shown in FIGURE 4-1, an implementation may support from one to twenty logical channels on each I/O interface, each with its own distinct CLEAR_ON_DESELECT memory segment.

Only one logical channel, logical channel number 0 (the basic logical channel) becomes active on the contacted I/O interface following a card reset. Similarly, only one logical channel, logical 0 (the basic logical channel) becomes active on the contactless I/O interface following a PICC activation sequence. A MANAGE CHANNEL APDU command may be issued on this logical channel to instruct the card to open a new logical channel. Applet instances can be selected on different logical channels using the SELECT FILE APDU command, just as they would in a single logical channel environment. The MANAGE CHANNEL APDU command is also used for closing a logical channel. Note that the basic logical channel is permanent and can never be closed as long as the I/O interface remains activated.

On a card that is able to sustain logical channel sessions over both interfaces simultaneously, there are two sets of twenty logical channels possible. A logical channel number 0 on the contacted I/O interface is not the same as the logical channel number 0 on the contactless I/O interface. An applet instance selected on a logical channel on the contacted I/O interface would normally receive APDUs only from the contacted I/O interface. However, it can receive APDUs from the contactless I/O interface also, only if the applet instance is concurrently selected on a logical channel on the contactless I/O interface. Rules of multiselection apply as described in Section 4.2, Multiselectable Applets.

Legacy applets (written for version 2.1 of the Java Card platform) running on version 2.2.*, need not be aware of logical channel support to work correctly. The Java Card RE must guarantee that an applet that was not designed to be aware of multiple sessions is not selected more than once or concurrently with another applet from the same package.

FIGURE 4-1 Logical Channels for Distinct Applets

Support for multiple logical channels (with multiple selected applet instances) requires a change to the Java Card platform version 2.1.* concept of selected applet. Because more than one applet instance can be selected at the same time, and one applet instance can be selected on different logical channels simultaneously, it is necessary to differentiate the state of the applet instances in more detail.

An applet instance is be considered an active applet instance if it is currently selected in at least one logical channel, up to a maximum of forty. Each active applet instance from a distinct package executes with a distinct CLEAR_ON_DESELECT transient memory segment, see FIGURE 4-1. An applet instance is the currently selected applet instance only if it is processing the current command. There can only be one currently selected applet instance at a given time.

Applets with 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. (Refer to FIGURE 4-2 below.)

No applet is active on the new (or only) logical channel when one of the following occurs:

The card is reset and no applet is designated as the default applet instance for the basic channel on the contacted I/O interface, or the default applet instance for the basic channel on the contacted I/O interface rejects selection.

The card successfully completes its PICC activation sequence and no applet is designated as the default applet instance for the basic channel on the contactless I/O interface, or the default applet instance for the basic channel on the contactless I/O interface rejects selection.

A MANAGE CHANNEL OPEN command on the basic channel opens a new channel, and no applet is designated as the default applet instance for that logical channel.

A new logical channel is opened when a MANAGE CHANNEL OPEN command is issued on a logical channel other than the basic channel, on which there is no active applet.

A SELECT FILE command fails when attempting to select an applet instance.

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.

In a similar manner, smart card proximity coupling device (PCD) applications require a default card applet instance to become implicitly selected after the proximity card (PICC) activation sequence successfully completes. In addition, default applet selection may also be required on each new logical channel opened during the contactless session.

The Java Card platform allows the card implementer to designate a default applet instance for each of the logical channels supported by the card. For any logical channel, the card implementation may designate an applet instance as the default applet instance for that logical channel. Alternatively, for any logical channel, the implementation may choose to designate no default applet instance at all. Logical channels may share the same applet instance as the default applet instance for more than one channel.

Upon card reset on the contacted interface and upon the completion of the PICC activation sequence on the contactless interface, only the basic logical channel (channel 0) is automatically opened. The default card applet instance for the contacted interface, if any, is therefore the default applet instance for logical channel 0 on the contacted interface. Similarly, the default card applet instance for the contactless interface, if any, is therefore the default applet instance for logical channel 0 on the contactless interface. A card that supports both I/O interfaces could designate a different applet instance as default for each interface.

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 select method is called. If this method throws an exception or returns false, the Java Card RE sets its state to indicate that no applet is active on the basic logical channel.

When a default card applet instance becomes active upon card reset, it shall not require its process method to be called. The applet instance's process method is not called during default applet selection because there is no SELECT FILE APDU.

2. The Java Card RE ensures that the Answer to Reset (ATR) was sent and the card is now ready to accept APDU commands.

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 applet is not a multiselectable applet (see Section 4.2, Multiselectable Applets) and either an instance of the default applet is already active on the contacted interface, or another applet instance from the same package is active on the contacted interface, the Java Card RE sets its state to indicate that no applet is active on the basic logical channel. Otherwise, the Java Card RE makes this applet instance the currently selected applet instance on the basic logical channel on the contactless I/O interface, and the applet's select method is called. If this method throws an exception or returns false, the Java Card RE sets its state to indicate that no applet is active on the basic logical channel on the contactless I/O interface.

When a default card applet instance becomes active after the successful completion of the PICC activation sequence on the contactless interface, it shall not require its process method to be called. The applet instance's process method is not called during default applet selection because there is no SELECT FILE APDU.

2. The Java Card RE ensures that the Answer to Select (ATS) was sent and the card is now ready to accept APDU commands.

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 applet's select method (MultiSelectable.select method if required) is called. If this method throws an exception or returns false, then the Java Card RE closes the new logical channel. (The applet instance's process method is not called during default applet selection, because there is no SELECT FILE APDU). A default applet instance shall not require its process method to be called.

If a default applet instance is successfully selected, then APDU commands can be sent directly to the applet instance on that logical channel. If no applet is active, then only SELECT FILE commands for applet selection or MANAGE CHANNEL commands can be processed on that logical channel.

A MANAGE CHANNEL command issued over an I/O interface shall open a new logical channel only on the same I/O interface. Similarly a SELECT FILE command issued over an I/O interface to open a new logical channel shall open a new logical channel only on the same I/O interface.

The mechanism for specifying the default applet instance for a logical channel is not defined in the Java Card API. It is a Java Card RE implementation detail and is left to the individual implementers.

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.

Note - All applets within a package shall be multiselectable or none shall be.

An applet's context is active when either an instance of the applet is already active, or when another applet instance from the same package is active. For more information about contexts see Section 6.1.2, Contexts and Context Switching. An attempt to select an applet instance when the applet's context is active, is referred to as a multiselection attempt. If successful, multiselection occurs, and the applet instance becomes multiselected.

Multiselectable applets shall implement the javacard.framework.MultiSelectable interface. In case of multiselection, the applet instance is informed by invoking its methods MultiSelectable.select and MultiSelectable.deselect during selection and deselection respectively.

When an applet instance not currently active is the first one selected in its package, its Applet.select method is called. Subsequent multiselections to this applet instance or selection of other applet instances in the same package shall result in a call to MultiSelectable.select method. This method is defined in the MultiSelectable interface. Its only purpose is to inform the applet instance that it will be multiselected. The applet instance may accept or reject a multiselection attempt.

If a multiselection attempt is made on an applet which does not implement the MultiSelectable interface, the selection shall be rejected by the Java Card RE.

When a multiselected applet instance is deselected from one of the logical channels, the method MultiSelectable.deselect is called. Only when the multiselected applet instance is the last active applet instance in the applet's context, is its regular method Applet.deselect called.

The following list describes the two cases of multiselection:

1. When two distinct applet instances from within the same package are multiselected, each applet instance shares the same CLEAR_ON_DESELECT memory transient segment. The applet instances share objects within the context firewall as well as their transient data. The Java Card RE shall not reset this CLEAR_ON_DESELECT transient objects until all applet instances within the package are deselected, see FIGURE 4-2.

FIGURE 4-2 Different Applet Instances in Same Package

2. When the same applet instance is multiselected on two different logical channels simultaneously, it shares the CLEAR_ON_DESELECT memory segment space across logical channels. The Java Card RE shall not reset the CLEAR_ON_DESELECT transient objects until all applet instances within the package are deselected, see FIGURE 4-3.

FIGURE 4-3 Same Applet Instance Selected on Multiple Logical Channels

In both cases of multiselection, the applets must implement the MultiSelectable interface. If the applets do not support this feature, the selection must be rejected by the Java Card RE.

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.

In addition, cards compliant with Java Card platform specification v2.2.2 must also support proprietary class values of the CLA byte equal to 0x8X, 0x9X, 0xAx and 0xBX for channel numbers in the range 0-3 and proprietary class values of the CLA byte equal to 0xCY, 0xDY, 0xEY and 0xFY for channel numbers 4-19 (using 0 origin notation). The bit encoding of the proprietary class values of the CLA byte mirror that of the ISO 7816-4:2005 Specification defined interindustry values with the most significant bit b8 set to 1. TABLE 4-1 and TABLE 4-2 show the supported encodings of the CLA byte.

The two least significant bits (b2,b1*) of the X nibble encodes the logical channels numbers 0-3, whereas the Y nibble (b4-b1*) encodes logical channel numbers in the range 4-19 (using 0 origin notation). When an APDU command is received, the Java Card RE shall process it and determine whether or not the command has logical channel information. If logical channel information is encoded, the card dispatches the APDU command to the appropriate logical channel on that I/O interface. All other APDU commands are forwarded to the basic logical channel (logical channel 0) on that I/O interface.

TABLE 4-1 ISO 7816-4:2005 Specification Interindustry CLA Semantics

CLA byte encoding		Semantic details
%b0000 00zz		(Type 4) last or only command in chain, no SM
%b0001 00zz		(Type 4) not last command in chain, no SM
%b0000 yyzz		(Type 4) last or only command in chain, with SM
%b0001 yyzz		(Type 4) not last command in chain, with SM
%b0010 uuuu		RFU
%b0011 uuuu		RFU
%b0100 zzzz		(Type 16) last or only command in chain, no SM
%b0101 zzzz		(Type 16) not last command in chain, no SM
%b01y0 zzzz		(Type 16) last or only command in chain, with SM
%b01y1 zzzz		(Type 16) not last command in chain, with SM
	NOTATION
	u y z	undefined Secure Messaging (SM) indicator See ISO 7816-4:2005 Specification Section 6 for further information. Logical channel indicator Type 4 supports logical channels [0..3] Type 16 supports logical channels [4..19]

TABLE 4-2 Java Card Technology Proprietary CLA Semantics

CLA byte encoding		Semantic details
%b1000 00zz		(Type 4) last or only command in chain, no SM
%b1001 00zz		(Type 4) not last command in chain, no SM
%b1000 yyzz		(Type 4) last or only command in chain, with SM
%b1001 yyzz		(Type 4) not last command in chain, with SM
%b1010 00zz		(Type 4) last or only command in chain, no SM
%b1011 00zz		(Type 4) not last command in chain, no SM
%b1010 yyzz		((Type 4) last or only command in chain, with SM
%b1011 yyzz		(Type 4) not last command in chain, with SM
%b1100 zzzz		(Type 16) last or only command in chain. no SM
%b1101 zzzz		(Type 16) not last command in chain, no SM
%b11y0 zzzz		(Type 16) last or only command in chain, with SM
%b11y1 zzzz		(Type 16) not last command in chain, with SM
	NOTATION
	u y z	undefined Secure Messaging indicator See ISO 7816-4:2005 Specification Section 6 for further information. Logical channel indicator Type 4 supports logical channels [0..3] Type 16 supports logical channels [4..19]

Note - CLA byte 0xFX cannot encode logical channel 19 because CLA = 0xFF is a reserved value for Protocol Type Selection. In compliance with ISO 7816-4:2005 Specification, logical channel number 19 is not available when using this CLA byte.

The Java Card RE always forwards the command "as is" to the appropriate applet instance. In particular, the Java Card RE does not clear the logical channel encoding bits of the CLA byte.

To avoid the complexity of the transport information encoded in the CLA byte of the APDU command header, the application programmer is advised not to parse the CLA byte directly. The following methods in the javacard.framework.APDU class may be used to extract application specific information:

APDU.isISOInterindustryCLA

APDU.isSecureMessagingCLA

APDU.isCommandChainingCLA

APDU.getCLAChannel

Note - An asterisk indicates binary notation (%b) using bit numbering as in the ISO7816 specification. Most significant bit is b8. Least significant bit is b1.

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. See Section 4.5.2, Applet Selection with SELECT FILE.

2. By issuing a MANAGE CHANNEL OPEN APDU command. MANAGE CHANNEL commands are provided to open a logical channel from another logical channel, or to close a logical channel from another logical channel. See Section 4.4.1, MANAGE CHANNEL Command Processing.

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' select and deselect methods).

With the addition of logical channels in Java Card platform, the Java Card RE includes a multichannel dispatching mechanism, as well as checks to ensure applet integrity during multi-channel operations. The Java Card RE must ensure that applets written to operate in a single logical channel environment operate consistently on a multiple logical channel smart card.

Java Card platform defines a class of APDU commands, called MANAGE CHANNEL commands. The functions the Java Card RE must perform by using MANAGE CHANNEL command processing are:

MANAGE CHANNEL OPEN: Open a new logical channel from an already-open logical channel. Two variations of this command are supported:

The Java Card RE selects the new logical channel specified in the command

The Java Card RE automatically assigns a new logical channel.

MANAGE CHANNEL CLOSE: Close a specified logical channel from another open logical channel.

In addition, the SELECT FILE APDU command to select an applet instance is extended to specify a new or already opened logical channel on which the specified applet instance is to be selected.

The term origin logical channel refers to the logical channel on which the command is received based on the logical channel number encoding within the CLA byte, as described in Section 4.3, Forwarding APDU Commands To a Logical Channel.

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 same, irrespective of the logical channel on which it is selected.

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=%0100dddd* (where dddd in the bits (b4-b1) denote the origin logical channel: 4-19), INS=0x70 and P1=0. Two variants of this command are supported:

P2=0 when the Java Card RE shall assign a new logical channel number.

P2= the logical channel number specified.

If the MANAGE CHANNEL OPEN command has non-zero secure messaging bits (b4,b3*) in the CLA byte when the origin logical channel is 0-3 or non-zero bit (b6*) when the origin logical channel is 4-19, the Java Card RE responds with status code 0x6882 (SW_SECURE_MESSAGING_NOT_SUPPORTED).

If the MANAGE CHANNEL command is issued with P1 not equal to 0 or 0x80, or if the unsigned value of P2 is greater than 19, the Java Card RE responds with status code 0x6A81 (SW_FUNC_NOT_SUPPORTED).

2. If the origin logical channel on that I/O interface is not open, the Java Card RE responds with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

3. If the Java Card RE supports only the basic logical channel on that I/O interface, the Java Card RE responds with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

4. If the P2=0 variant is used:

If the expected length value (Le) is not equal to 1, the Java Card RE responds with status code 0x6C01 (SW_CORRECT_LENGTH_00+0x01).

If resources for the new logical channel are not available, the Java Card RE responds with status code 0x6A81 (SW_FUNC_NOT_SUPPORTED).

5. If the P2 != 0 variant is used:

If resources for the specified logical channel are not available or the logical channel is already open, the Java Card RE responds with status code 0x6A86 (SW_INCORRECT_P1P2).

6. The new logical channel on the I/O interface that received the MANAGE CHANNEL OPEN command is now open. This logical channel will be the assigned channel for the applet instance that will be selected on it.

7. Determine the applet instance to be selected on the new logical channel.

If the origin logical channel is the basic logical channel (logical channel 0), then:

If a default applet instance for the new logical channel on the I/O interface is defined, pick the default applet instance for that logical channel as the candidate for selection on the new logical channel.

Otherwise, set the Java Card RE state so that no applet is active on the new logical channel. The Java Card RE responds with status code 0x9000 and if the P2=0 variant is used, one data byte containing the newly assigned logical channel number.

If the origin logical channel is not the basic logical channel:

If an applet instance is active on the origin logical channel, pick the applet instance as the candidate for selection on the new logical channel.

Otherwise, set the Java Card RE state so that no applet is active on the new logical channel. The Java Card RE responds with status code 0x9000 and if the P2=0 variant is used, one data byte containing the newly assigned logical channel number.

8. If the candidate applet instance is not a multiselectable applet (as defined in Section 4.2, Multiselectable Applets) and the candidate applet's context is active, the Java Card RE shall close the new logical channel. The Java Card RE responds with status code 0x6985 (SW_CONDITIONS_NOT_SATISFIED).

9. Assign the CLEAR_ON_DESELECT transient memory segment for the new logical channel:

If the applet's context is active, assign the CLEAR_ON_DESELECT transient memory segment associated with that context to this logical channel.

Otherwise, assign a new (zero-filled) CLEAR_ON_DESELECT transient memory segment to this new logical channel.

10. Check whether the candidate applet instance accepts selection:

If the candidate applet's context is active, the Java Card RE shall set the candidate applet instance as the currently selected applet instance and call the MultiSelectable.select method, where the parameter appInstAlreadyActive is set to true if the same applet instance is already active on another logical channel. A context switch into the candidate applet instance's context occurs at this point. For more details on contexts, see Section 6.1.2, Contexts and Context Switching.

Otherwise, if the candidate applet's context is not active, the Java Card RE shall set the candidate applet instance as the currently selected applet instance and call the Applet.select method. A context switch into the candidate applet instance's context occurs at this point.

If the applet instance's select method throws an exception or returns false, then the Java Card RE closes the new logical channel. The Java Card RE responds with status code 0x6999 (SW_APPLET_SELECT_FAILED).

11. The Java Card RE responds with status code 0x9000 (and if the P2=0 variant is used, 1 data byte containing the newly assigned logical channel number.)

Note - Unlike the SELECT FILE commands to select an applet instance, the MANAGE CHANNEL command is never forwarded to the applet instance.

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=%0100dddd* (where dddd in the bits (b4-b1) denote the origin logical channel: 4-19) and INS=0xA4.

If the SELECT FILE command has non-zero secure messaging bits (b4,b3*) in the CLA byte when the origin logical channel is 0-3 or non-zero bit (b6*) when the origin logical channel is 4-19, it is deemed not to be an Applet SELECT FILE command. The Java Card RE simply forwards the command to the active applet on the specified logical channel.

The Applet SELECT FILE command uses "Selection by DF name" with P1=0x04.

The Java Card RE shall support both of the following:

Selection by "exact DF name(AID)" with P2=%b0000xx00 (b4,b3* are don't care) and

The RFU variant described in ISO 7816-4 Specification with P2=%b0001xx00 (b4,b3* are don't care).

All other partial DF name SELECT FILE options (b2,b1* variants) are Java Card RE implementation dependent.

All file control information options codes (b4,b3*) of the P2 parameter shall be supported by the Java Card RE and interpreted and processed by the applet instance itself.

2. If resources for the specified logical channel (in bits cc of the CLA) are not available, the Java Card RE responds with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

3. If the specified logical channel is not open on the I/O interface that received the SELECT FILE command, it is now opened and the Java Card RE state is set so that no applet is active on this new logical channel. The specified logical channel will be the assigned channel for the applet instance that will be active on it.

4. The Java Card RE searches the internal applet table which lists all successfully installed applet instances on the card for an applet instance with a matching AID. If a matching applet instance is found, it is picked as the candidate applet instance. Otherwise, if no AID match is found:

If there is no active applet instance on the specified logical channel, the Java Card RE responds with status code 0x6999 (SW_APPLET_SELECT_FAILED).

Otherwise, the active applet instance on this logical channel is set as the currently selected applet instance and the SELECT FILE command is forwarded to that applet instance's process method. A context switch into the applet instance's context occurs at this point, see Section 6.1.1, Firewall Protection. Applets may use the SELECT FILE command for their own internal processing. Upon return from the applet's process method, the Java Card RE sends the applet instance's response as the response to the SELECT FILE command.

5. If the candidate applet instance is not a multiselectable applet, and the candidate applet's context is active, the logical channel remains open and the Java Card RE records an error response status code of 0x6985 (SW_CONDITIONS_NOT_SATISFIED). Prior to sending the response code, if there is an active applet instance on the logical channel, then the Java Card RE may optionally deselect the applet instance, as described in Section 4.6, Applet Deselection, and set the state so that no applet is active on the specified logical channel.

6. Assign the CLEAR_ON_DESELECT transient memory segment for the new logical channel in the following cases:

If any applet instance from the same package as that of the candidate applet instance is active on another logical channel, assign the same CLEAR_ON_DESELECT transient memory segment to this logical channel.

Otherwise, assign a different (zero-filled) CLEAR_ON_DESELECT transient memory segment to this new logical channel.

7. Check whether the candidate applet instance accepts selection:

If the candidate applet's context is active, the Java Card RE shall set the candidate applet instance as the currently selected applet instance and call the MultiSelectable.select(appInstAlreadyActive) method, where the parameter appInstAlreadyActive is set to true if the same applet instance is already active on another logical channel. A context switch into the candidate applet instance's context occurs at this point, see Section 6.1.2, Contexts and Context Switching.

Otherwise, if the candidate applet's context is not active, the Java Card RE shall set the candidate applet instance as the currently selected applet instance and call the Applet.select method. A context switch into the candidate applet instance's context occurs at this point.

If the applet instance's select method throws an exception or returns false, then the Java Card RE state is set so that no applet is active on the specified logical channel. The logical channel remains open, and the Java Card RE responds with status code 0x6999 (SW_APPLET_SELECT_FAILED).

8. The Java Card RE shall set the candidate applet instance as the currently selected applet instance and call the Applet.process method with the SELECT FILE APDU as the input parameter. A context switch occurs into the applet instance's context at this point. Upon return from the applet instance's process method, the Java Card RE sends the applet instance's response as the response to the SELECT FILE command.

Note - If the SELECT FILE command does not conform to the exact format of an Applet SELECT FILE command described in item 1 above or if there is no matching AID, the SELECT FILE command is forwarded to the active applet instance (if any) on that logical channel for processing as a normal applet APDU command.

If there is a matching AID and the SELECT FILE command fails, the Java Card RE always sets the state in which no applet is active on that logical channel.

If the matching AID is the same as the active applet instance on the specified logical channel, the Java Card RE still goes through the process of deselecting the applet instance and then selecting it. Reselection could fail, leaving the card in a state in which no applet is active on that logical channel.

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:

If the applet instance to be deselected is active on more than one logical channel, or another applet instance from the same package is also active, the Java Card RE sets the currently selected applet instance to be the applet instance being deselected, and calls its MultiSelectable.deselect(appInstStillActive) method, where the appInstStillActive parameter is set to true if the same applet instance is still active on another logical channel. A context switch occurs into the applet instance's context at this point, see Section 6.1.2, Contexts and Context Switching.

Otherwise, the Java Card RE sets the currently selected applet instance to be the applet instance being deselected, and calls its Applet.deselect method. Upon return or uncaught exception, the Java Card RE clears the fields of all CLEAR_ON_DESELECT transient objects in the context of deselected applet instance.

Note - Note that the deselection is always successful even if the applet instance throws an exception from within the deselect method.

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=%0100dddd* (where dddd in the bits (b4-b1) denote the origin logical channel: 4-19), INS=0x70, P1=0x80 and P2 specifies the logical channel to be closed.

If the MANAGE CHANNEL CLOSE command has non-zero secure messaging bits (b4,b3) in the CLA byte when the origin logical channel is 0-3 or non-zero bit (b6*) when the origin logical channel is 4-19, the Java Card RE responds with status code 0x6882 (SW_SECURE_MESSAGING_NOT_SUPPORTED).

If the MANAGE CHANNEL command is issued with P1 not equal 0 or 0x80, the Java Card RE responds with status code 0x6A81 (SW_FUNC_NOT_SUPPORTED).

2. If the origin logical channel on the I/O interface that received the MANAGE CHANNEL CLOSE command is not open, the Java Card RE responds with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

3. If the Java Card RE supports only the basic logical channel on the I/O interface that received the MANAGE CHANNEL CLOSE command, the Java Card RE responds with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

4. If the specified logical channel to close is the basic logical channel (logical channel 0) or the specified logical channel number is greater than 19, the Java Card RE responds with status code 0x6A81 (SW_FUNC_NOT_SUPPORTED).

5. If the specified logical channel to close is currently open on the I/O interface that received the MANAGE CHANNEL CLOSE command, deselect the active applet instance (if any) on the specified logical channel as described above in Section 4.6, Applet Deselection. The specified logical channel is now closed. The Java Card RE responds with status code 0x9000.

6. Otherwise, if the specified logical channel is closed or not available on that I/O interface, the Java Card RE responds with warning status code 0x6200 (SW_WARNING_STATE_UNCHANGED).

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:

An unsupported logical channel number in the CLA byte

An unopened logical channel number in the CLA byte

It shall respond to the APDU with status code 0x6881 (SW_LOGICAL_CHANNEL_NOT_SUPPORTED).

If there is no active applet instance on the logical channel to be used for dispatching the command, the Java Card RE shall respond to the APDU with status code 0x6999 (SW_APPLET_SELECT_FAILED).

When an APDU other than a Applet SELECT FILE or a MANAGE CHANNEL command is received, and there is an active applet instance on the logical channel to be used for dispatching the command, the Java Card RE sets the active applet instance on the origin channel as the currently selected applet instance and invokes the process method passing the APDU as a parameter. This causes a context switch from the Java Card RE context into the currently selected applet instance's context (For more information on contexts see Section 6.1.2, Contexts and Context Switching.) When the process method exits, the VM switches back to the Java Card RE context. The Java Card RE sends the response APDU and waits for the next command APDU.

Note that the Java Card RE dispatches the APDU command "as is" to the applet instance for processing via the process method. Therefore, the CLA byte in the command header contains in its least significant bits the origin channel number. An applet designed to run on any logical channel needs to mask out these two bits before checking for specific values.