Message model of javacard development tutorial

The message passing model described in Figure 1 is the basis for all Java card communications.Its core is application.ProgramThe Protocol Data Unit (APDU) is a logical data packet exchanged between the CAD and Java card frameworks.The javacard framework receives any APDU commands sent by CAD and sends them to corresponding small applications.The application processes The APDU command, and then returns a response to APDU.Those APDU comply with International Standard Specifications ISO/IEC 7816-3 and 7816-4.Figure 1 communication using the message passing ModelThe communication between the card reader and the card is usually based on one of the following two connection protocols, T = 0 for bytes, or T = 1 for data blocks.The replacement protocols, also known as t = USB and t = RF, may be used.The jcreapdu class hides some protocol details from the application, but not all of them, because the T = 0 Protocol is quite complicated.⒈ APDU commandThe structure of an APDU command is controlled by the value of its first byte. In most cases, it looks as follows:Figure 2 APDU commandAn APDU command has a required header and an optional body, including:· Linoleic (1 byte): a specific application class for this required field recognition command.The valid value of CFOs is defined in ISO 7816-4:Table 1. ISO 7816 levels

linoleic value	command class
0x0n, 0x1n	ISO 7816-4 card commands, such as file access and security operations
20 to 0x7f	retain
0x8n or 0x9n	you can use the ISO/IEC 7816-4 format for your specific application instructions. 'X' is interpreted according to the standard
0xan	specific application or supplier instructions
B0 to cf	you can use the ISO/IEC 7816-4 format for a specific application
D0 to Fe	specific application or supplier instructions
FF	retain to protocol type

· Theoretically, you can use all the c's 0x80 or higher values for specific application commands. However, in many current Java card implementations, only the ones shown in the black body are actually recognized.· Ins (1 byte): This required field specifies a specific instruction in the instruction class marked in the linoleic field.The ISO 7816-4 Standard specifies the basic commands used to access the data on the card when it is structured as the file system on the card defined in the standard.Additional features have been described elsewhere in this standard, some of which are security features.Table 2 contains a list of ISO 7816 instructions.You can define the INS value of your own specific application according to the standard only when you use a corresponding TLS byte value ,.Table 2. ISO 7816-4 ins values when the content of the request is calculated as follows:

INS Value	Command description
0e	Erase binary
20	Verify
70	Manage Channel
82	External Authenticate
84	GET CHALLENGE
88	Internal Authenticate
A4	Select File
B0	Read Binary
B2	Read record (s)
C0	Get Response
C2	Envelope
CA	Get Data
D0	Write binary
D2	Write record
D6	Update Binary
Da	Put data
DC	Update record
E2	Append record

· P1 (1 byte): This required field defines command parameter 1. You can use this field to check the INS field or input data. · P2 (1 byte): required field definition command parameter. You can use this field to check the INS field or input data. · LC (1 byte): This optional field is the number of bytes of the data field of the command. · Data Field (variable, number of bytes Lc): This optional field stores command data. · Le (1 byte): This optional field specifies the maximum number of bytes in the expected response data field. The command APDU has four changes depending on whether the command data exists and whether the data is required. Only when you use protocol T = 0 do you need to care about these changes: Figure 3. Four possible structures of the APDU command A typical application uses different APDU commands in different structures. 2. Response to APDU The response format to APDU is simple: Figure 4. Response to APDU Similar to an APDU command, the response to APDU has optional and necessary fields: · Data Field (variable length, determined by Le In The APDU command): This selectable field contains the data returned by the small application. · SW1 (1 byte): the required field is status word 1. · Sw2 (1 byte): the required field is status 2. The value of these State words is defined in ISO 7816-4: Figure 5. response status code The iso7816 Java interface in the Java card framework application programming interface defines many constants to help standardize the return of errorsCode. 3. Process APDU Every time a child application enters APDU for the selected small application, JRE calls the process () method of the Child application and transmits the child application into APDU as a parameter. This small application must parse the APDU command, process the data, generate a response to APDU, and then return the control to JRE. RMI (jcrmi) Communication Model The second communication model relies on a subset of the j2se RMI distributed object model. In the RMI model, a server application creates and generates accessible remote objects, and a client application obtains remote references to remote objects, and then calls their remote methods. In jcrmi, the Java card applet is a server, and the main application is a client. Jcrmi is provided by rmiservice to the javacardx. Rmi extension package. Jcrmi messages are encapsulated in the APDU object passed into the rmiservice method. In other words, jcrmi provides a Distributed Object Model Mechanism Based on The APDU message transmission model. Through this mechanism, the Server communicates with the client, sends back and forth method information, parameters, and returned values.