|
|
The topics in this chapter complement the requirements specified in the Application Programming Interface for the Java Card™ Platform, Version 2.2.1.
Unless specified in the Application Programming Interface for the Java Card™ Platform, Version 2.2.1, the implementation shall support the invocation of API instance methods, even when the owner of the object instance is not the currently selected applet. In other words, unless specifically called out, the implementation shall not use resources such as transient objects of CLEAR_ON_DESELECT type.
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 Section 6.2.1).
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 descriptions, updates to internal implementation state within the API objects must be conditional. In other words, internal state updates must participate in any ongoing transaction.
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.
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:
ISO 7816-4 CASE 1:Not applicable. Assume Case 2ISO 7816-4 CASE 2:P3 (If P3=0, 256)ISO 7816-4 CASE 3:Not applicable. Assume Case 4ISO 7816-4 CASE 4: 256
For compatibility with legacy CAD/terminals that do not support block chained mechanisms, the APDU class allows a non-chained transfer mode selection via the setOutgoingNoChaining method. The related behaviors are discussed in the following sections.
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 setOutgoingNoChaining method), calls to the waitExtension method shall throw an APDUException with reason code ILLEGAL_USE.
Le = CAD expected length.
Lr = Applet response length set via setOutgoingLength method.
<INS> = the protocol byte equal to the incoming header INS byte, which indicates that all data bytes will be transferred next.
<~INS> = the protocol byte that is the complement of the incoming header INS byte, which indicates that 1 data byte will be transferred next.
<SW1,SW2> = the response status bytes as in ISO7816-4.
Applet.process method.Applet.process method.Applet.process method.In Case 4, Le is determined after the following initial exchange:
The rest of the protocol sequence is identical to CASE 2 described above.
If the applet aborts early and sends less than Le bytes, zeros shall be sent instead to fill out the length of the transfer expected by the CAD.
When the no chaining mode of output transfer is not requested by the applet (that is, the setOutgoing method is used), any ISO-7816-3/4 compliant T=0 protocol transfer sequence may be used.
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 <0x61, xx> 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 sendBytes or the sendBytesLong methods shall throw an APDUException with reason code NO_T0_GETRESPONSE.
At any time, when the T=0 output transfer protocol is in use, and the APDU class is awaiting a command reissue from the CAD in reaction to a response status of <0x6C, xx> 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 sendBytes or the sendBytesLong methods shall throw an APDUException with reason code NO_T0_REISSUE.
Calls to sendBytes or sendBytesLong methods after the NO_T0_GETRESPONSE exception or the NO_T0_REISSUE exception has been thrown, shall result in an APDUException with reason code ILLEGAL_USE. If an ISOException is thrown by the applet after the NO_T0_GETRESPONSE exception or the NO_T0_REISSUE exception has been thrown, the Java Card RE shall discard the response status in its reason code. The Java Card RE shall restart APDU processing with the newly received command and resume APDU dispatching.
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 the no chaining mode of output transfer is requested by the applet by calling the setOutgoingNoChaining method, the following protocol specifics shall be followed:
Le = CAD expected length.
Lr = Applet response length set via setOutgoingLength method.
The transport protocol sequence shall not use block chaining. Specifically, the M-bit (more data bit) shall not be set in the PCB of the I-blocks during the transfers (ISO 7816-3). In other words, the entire outgoing data (Lr bytes) shall be transferred in one I-block.
If the applet aborts early and sends less than Lr bytes, zeros shall be sent instead to fill out the remaining length of the block.
setOutgoingNoChaining method), calls to the waitExtension method shall throw an APDUException with reason code ILLEGAL_USE.
When the no chaining mode of output transfer is not requested by the applet (i.e. the setOutgoing method is used) any ISO-7816-3/4 compliant T=1 protocol transfer sequence may be used.
waitExtension method may be invoked by the applet at any time. The waitExtension method shall send an S-block command with WTX request of INF units, which is equivalent to a request of 1 additional work waiting time in T=0 mode. (See ISO 7816-3).
If the CAD aborts a chained outbound transfer using an S-block ABORT request (see ISO 7816-3), the sendBytes or sendBytesLong method shall throw an APDUException with reason code T1_IFD_ABORT.
Calls to sendBytes or sendBytesLong methods from this point on shall result in an APDUException with reason code ILLEGAL_USE. If an ISOException is thrown by the applet after the T1_IFD_ABORT exception has been thrown, the Java Card RE shall discard the response status in its reason code. The Java Card RE shall restart APDU processing with the newly received command, and resume APDU dispatching.
If the CAD aborts a chained inbound transfer using an S-block ABORT request (see ISO 7816-3), the setIncomingAndReceive or receiveBytes method shall throw an APDUException with reason code T1_IFD_ABORT.
Calls to receiveBytes, sendBytes or sendBytesLong methods from this point on shall result in an APDUException with reason code ILLEGAL_USE. If an ISOException is thrown by the applet after the T1_IFD_ABORT exception has been thrown, the Java Card RE shall discard the response status in its reason code. The Java Card RE shall restart APDU processing with the newly received command, and resume APDU dispatching.
The getInstance method in the following classes return an implementation instance in the context of the calling applet of the requested algorithm:
javacard.security.MessageDigest javacard.security.Signature javacard.security.RandomData javacard.security.KeyAgreement javacard.security.Checksum javacardx.crypto.Cipher
An implementation of the Java Card RE may implement 0 or more of the algorithms listed in the Application Programming Interface for the Java Card™ Platform, Version 2.2.1. When an algorithm that is not implemented is requested this method shall throw a CryptoException with reason code NO_SUCH_ALGORITHM.
Implementations of the above classes shall extend the corresponding base class and implement all the abstract methods. All data allocation associated with the implementation instance shall be performed at the time of instance construction to ensure that any lack of required resources can be flagged early during the installation of the applet.
Similarly, the buildKey method of the javacard.security.KeyBuilder class returns an implementation instance of the requested Key type. The Java Card RE may implement 0 or more types of keys. When a key type that is not implemented is requested, the method shall throw a CryptoException with reason code NO_SUCH_ALGORITHM.
In the same fashion, the constructor for the javacard.security.KeyPair class creates a KeyPair instance for the specified key type. The Java Card RE may implement 0 or more types of keys. When a key type that is not implemented is requested, the method shall throw a CryptoException with reason code NO_SUCH_ALGORITHM.
Implementations of key types shall implement the associated interface. All data allocation associated with the key implementation instance shall be performed at the time of instance construction to ensure that any lack of required resources can be flagged early during the installation of the applet.
The MessageDigest object uses temporary storage for intermediate results when the update() method is invoked. This intermediate state need not be preserved across power up and reset. The object is reset to the state it was in when previously initialized via a call to reset().
The Signature and Cipher objects use temporary storage for intermediate results when the update() method is invoked. This intermediate state need not be preserved across power up and reset. The object is reset to the state it was in when previously initialized via a call to init().
The Checksum object uses temporary storage for intermediate results when the update() method is invoked. This intermediate state need not be preserved across power up and reset. The object is reset to the state it was in when previously initialized upon a tear or card reset event.
In the Java Card platform, version 2.2.1, the getVersion method returns (short) 0x0202.
|
|
Runtime Environment Specification for the Java Card Platform Specification, 2.2.1 |
Copyright © 2003 Sun Microsystems, Inc. All rights reserved.