WO2008148278A1

WO2008148278A1 - Method for exchanging large-capacity data between mobile terminal and smart card

Info

Publication number: WO2008148278A1
Application number: PCT/CN2007/070890
Authority: WO
Inventors: Zhengquan Huang; Yanhui Yang; Su Zhang; Zhiyong Pan
Original assignee: Phoenix Microelectronics (China) Co., Ltd.
Priority date: 2007-06-06
Filing date: 2007-10-12
Publication date: 2008-12-11
Also published as: CN101321336A; CN101321336B

Abstract

A method for exchanging the large-capacity data between the mobile terminal and the smart card comprises: establishing the transmission channel between the mobile terminal and the smart card by using the APDU command, establishing the special logical channel by using the protocol token corresponding to the mobile terminal application and the file of smart card, and transmitting the large-capacity data that the blocking size meets the standard ordain. The problem of transmitting the large-capacity data by using the standard ISO/IEC 7816 interface is settled by this method.

Description

Large-capacity data exchange method between mobile terminal and smart card

The present invention relates to a mobile terminal and a smart card application, and in particular to a large-capacity data exchange method between a mobile terminal and a smart card.

Background technique

( ) With the rapid development and wide application of wireless communication technologies, various mobile value-added services/applications have emerged. There are two typical types: mobile terminal-based applications and smart card-based applications. Although the former has developed to a certain extent, it is rarely supported by operators, so it is not supported by operators. The smart card-based application is completely monitored by operators because it is integrated in the smart card. It is easier to get support from operators than mobile terminal-based applications, and thus it can be widely promoted.

However, due to the limitations of many technical conditions including the processing power, communication means and capacity of the smart card, the current smart card-based application can only provide applications with simple functions and single mode, such as: SIM card application toolbox ( The SIM Application Toolkit (referred to as SAT or STK) can only provide a plain text menu display. This is in sharp contrast to the development of mobile terminal-based applications and is out of sync with the rapid development of the entire mobile communications industry.

In response to this situation, a variety of smart cards with very large capacity have appeared, and their capacity is usually measured in units of megabytes, which is much larger than the conventional smart cards currently on the market, and the maximum capacity is 256 kbytes. This makes it possible to develop and deploy a large number of new applications on smart cards. However, due to the fact that ISO/IEC 7816 and mobile communication protocols are still used between mobile terminals and smart cards, the communication methods and modes are still single, and it is difficult to meet the communication requirements of these applications.

(2) At present, the method for the mobile terminal to access the data in the smart card is as shown in FIG. 1. The communication between the mobile terminal and the smart card is completely completed by the baseband processor of the mobile terminal, and the underlying physical transmission channel conforms to ISO/IEC 7816-3. -4 standard.

(1) In actual operation, the upper layer application of the mobile terminal or other terminal, such as a personal computer PC, sends an AT command to the baseband processor, and the baseband processor converts it into an ISO/IEC 7816 standard. The Application Protocol Data Unit (APDU) command sends the command to the smart card to implement command execution and data transmission.

Third Generation Mobile Partner Program Technical Specification The AT command set for mobile terminals is defined in the 3GPP TS 07.07 specification. In addition to some dedicated commands for specific applications, such as selecting a phonebook storage space, there are two general AT commands that can be used to send APDU commands directly to the subscriber identity module, a SIM card. The two commands are: CSIM and CRSM. The CSIM is a generic SIM access command (Generic SIM access), by which the mobile terminal can send and return all APDU commands in accordance with the GSM 11.11 specification to the SIM; and the CRSM is a restricted SIM access command (Restricted SIM access). It can transfer six commands specified in the GSM11.11 specification, including read/update binary READ/UPDATE BINARY, read/update record READ/UPDATE RECORD, response GET RESPONSE, get status STATUS, etc.

(2) Since the above AT commands for directly transmitting APDUs to smart cards are optional commands, not all baseband processors provide support for them. Even if provided, if the operating system or human interface MMI of the mobile terminal does not provide a corresponding Application Programming Interface (API) for the upper application software, the application software of the mobile terminal cannot use the AT command to establish a unified Universal, universal access to data within the smart card. The current situation is that both possibilities exist. That is, some baseband processors do not support the AT command to send APDUs directly to the smart card. 2 Some mobile terminal operating systems do not open the interface of the command to the upper layer application software. Based on this, from the perspective of versatility and compatibility, the upper layer application software of the mobile terminal cannot access the smart card by directly transmitting the AT command of the optional APDU to the smart card, and can only access the smart card by the mobile terminal currently provided by the mobile terminal. A function or interface to implement data/file transfer to create various smart card-based mobile value-added applications on the mobile terminal.

In addition, due to the limitation of the APDU command format itself, the maximum capacity of the smart card file does not exceed 64k bytes, and the data transmitted by the APDU does not exceed 256 bytes or 64K bytes at a time. Such a small file capacity and data transmission amount cannot be caused. Implement complex applications on smart cards, such as graphical applications. Therefore, it is necessary to expand the data capacity that smart cards can accommodate and transmit, especially to address how to transfer large amounts of data using the standard ISO/IEC 7816 interface.

BISO/IEC 7816-4 is a master-slave structure, command-responsive protocol. The APDU is classified into two types: command APDU and response APDU. The host sends a command APDU to the smart card; the smart card accepts After the command APDU, execute the command and return the response APDIL

The command APDU consists of a mandatory 4-byte command header (CLA, INS, Pl, P2) and an optional variable-length command body (Lc, Data, Le) as follows:

The command header is the encoding of the command, Lc is the length of the in-vivo data Data; Data is the transmitted data; Le is the maximum number of bytes expected to answer the APDU data field. When Le=0, it indicates that the request returns the maximum number of response data bytes. If Le is 1 byte length, the maximum number of data bytes is 256.

The meaning of each byte in the command header of the APDU is:

CLA: Instruction category, GSM 11.11 specifies that OxAO is used for GSM applications;

INS: instruction code;

Pl, P2: The parameters of the instruction, the meaning of Pl and P2 are related to the specific instruction.

In the GSM application, the command APDU format of ISO/IEC 7816-4 has been simplified, and the format of the command APDU is as follows:

P3 represents the length of the data sent to the SIM card in the command, or the maximum length of the data waiting for the response from the card.

The response APDU consists of a variable-length data body and a 2-byte trailer, where the data body is optional and the tail is mandatory, as shown in the following table:

The number of bytes of the data body is indicated by Le of the command APDU. Data is the receiving device, such as a smart card, that receives the command APDU and processes it and sends it back to the sending device, such as the interface device. The tails SW1 and SW2 are status codes, one byte each, indicating whether the result of the command execution is correct or not.

Whether it is a command APDU or a response APDU, the data body Data can be used to transfer customized data. However, due to the APDU format and definition, its length is determined by Le, Lc or P3. Set. Lc and Le have both short and extended types, and their lengths are 1 byte and 3 bytes respectively, and the first byte value of 3 bytes is 0. Therefore, the data length that each APDU can transmit is up to 64k bytes. In the GSM protocol, the length of P3 is fixed to 1 byte, which means that the length of data that can be transmitted by each APDU is up to 256 bytes. Therefore, to transfer larger amounts of data, multiple APDUs and/or multiple files must be used.

In the mobile communication protocol, multiple APDU commands can be automatically sent through the values of the status bytes SW1, SW2. When SWl/SW2=0x9FXX, the mobile terminal needs to send a GET RESPONSE command to obtain the output data. When using the ENVELOPE command for smart card data download, if SW1/SW2 = 0x9EXX, the mobile terminal also needs to send a GET RESPONSE command to obtain the response data. In the active command mobile terminal, when SWl/SW2=0x91XX, the mobile terminal needs to send a FETCH command to acquire the data that the smart card needs to send. In this way, through the status byte, multiple APDU commands or large-capacity data can be automatically transferred between the mobile terminal and the smart card.

Although both the mobile terminal and the smart card support the above mechanism, since these commands or mechanisms belong to the underlying hardware commands, they are not completely open to the upper layer application. Therefore, the upper layer application software of the mobile terminal cannot utilize this data transmission mechanism. In particular, proactive commands are required when both smart cards and mobile terminals are supported. Summary of the invention

The technical problem to be solved by the present invention is to provide a large-capacity data exchange method between a mobile terminal and a smart card, which enables the mobile terminal application to directly exchange large-capacity data with the smart card, and further ensures the integrity and validity of the data transmission.

The above technical problem of the present invention is solved by the present invention to provide a large-capacity data exchange method between a mobile terminal and a smart card, comprising the following steps:

1.1) Using a general APDU command to establish a data transmission channel between the mobile terminal and the smart card; solving the consistency and compatibility problems; establishing a specific logical channel for the protocol token of the card file; 1.3) Using the data transmission channel and the specific logical channel to block the large-capacity data whose block size meets the standard requirements.

According to the data exchange method provided by the present invention, the universal APDU command includes an update binary UPDATE BINARY APDU command and its response and a read binary READ BINARY APDU command and its response open to the mobile terminal application; the update binary UPDATE BINARY APDU command and The read binary READ BINARY APDU command response carries the transmitted data.

According to the data exchange method provided by the present invention, the partition includes a partition block unit of the large-capacity data and a corresponding protocol token unit; wherein the last block includes an end flag.

According to the data exchange method provided by the present invention, the partition further includes a next data block length unit, and a value of 0 of the next data block length unit is a transmission end flag, and the transmission end flag includes but is not limited to the the way.

According to the data exchange method provided by the present invention, the block may further include a data check unit, the step 1.3) includes a calculated check value of the sender, and the check value is encapsulated into the check unit, and The receiving side performs a process of receiving data verification according to the data verification unit.

According to the data exchange method provided by the present invention, when the mobile terminal application performs data transmission to the smart card, the step 1.3) includes the smart card transmitting the command execution and verification success/failure to the mobile terminal application by using the status byte SW1/SW2 of the APDU command response. . According to the data exchange method provided by the present invention, the step 1.3) may further include performing retransmission after the command execution or the verification failure; the retransmission includes acquiring the error status record file by using the read binary READ BINARY APDU command and the response thereof. And analyze the error status record to decide whether to retransmit.

According to the data exchange method provided by the present invention, each of said blocks includes a data check unit corresponding to its own data.

According to the data exchange method provided by the present invention, each of the plurality of segments includes a data check unit corresponding to the plurality of the blocks, which saves the data check unit and transmits the valid data.

According to the data exchange method provided by the present invention, each of the partitions includes a data check unit corresponding to the block and the previous block existing therein, that is, the data check unit of the first block corresponds to its own data. Others correspond to the data of the two blocks, and the checksum is combined with the previous block to verify the correctness of the data link. According to the data exchange method provided by the present invention, each of the plurality of blocks includes a data check unit corresponding to the plurality of blocks and a previous block existing therein, that is, data of a plurality of blocks transmitted first. The check unit corresponds to a plurality of block data of the plurality of blocks, and the data check unit of the plurality of other blocks corresponds to the data of the plurality of blocks and the previous block, and the checksum is combined with the check of the previous block. In this way, not only the correctness of the data link is further ensured, but also the verification unit can be saved.

According to the data exchange method provided by the present invention, the standard is the ISO/IEC 7816 standard, which specifies that the maximum transmission data per APDU may be 256 bytes or 64 kbytes.

According to the data exchange method provided by the present invention, in the GSM protocol, the standard specifies that the maximum transmission data per APDU is 256 bytes.

The large-capacity data exchange method between the mobile terminal and the smart card provided by the invention establishes a unified data transmission channel between the mobile terminal and the smart card by using the general APDU command, and further adopts a data encapsulation and tunneling protocol method to solve the utilization standard. The ISO/IEC 7816 interface for large-capacity data transmission problems, using the method of the present invention, has the following significant effects:

1) The mobile terminal can directly access any data in the smart card without considering whether there is a problem of hardware compatibility;

2) Large-capacity data can be reliably transmitted between the mobile terminal and the smart card to implement various smart card-based applications;

3) The mobile terminal can directly access the smart card data by using the operation mode of the file system, which greatly facilitates the implementation of the application. DRAWINGS

The invention will be further described in detail below with reference to the drawings and specific embodiments.

FIG. 1 is a schematic structural diagram of a conventional mobile terminal application accessing smart card data;

2 is a schematic diagram of an access model of a mobile terminal application accessing smart card data according to the present invention; FIG. 3 is a description of a data packet format of the present invention;

4 is a schematic diagram of a data encapsulation process of the present invention;

5 is a schematic flowchart of a mobile terminal transmitting large-capacity data to a smart card according to the present invention; 6 is a schematic flowchart of an error processing process when a mobile terminal transmits large-capacity data to a smart card according to the present invention;

7 is a schematic flowchart of a mobile terminal acquiring large-capacity data from a smart card according to the present invention; and FIG. 8 is a schematic diagram showing an error processing flow when the mobile terminal acquires large-capacity data from a smart card according to the present invention.

detailed description

First, the difference between the method for accessing the smart card data by the mobile terminal application in the large-capacity data exchange method between the mobile terminal and the smart card of the present invention is compared with the current mode. The model of the present invention is shown in FIG. 2, and is utilized on the basis of the current mode (FIG. 1). The universal APDU command establishes a common data transmission channel between the mobile terminal and the smart card. The upper layer of the mobile terminal uses the general APDU command to directly access the smart card for large data transmission without using STK commands or AT commands; to avoid the possibility of software (such as STK virtual machine) interface or hardware interface (such as AT) in Figure 1. Command) caused incompatibility.

The second step illustrates the idea and main means of the invention:

( ) Use the generic APDU command that is open to the upper application: For example, read the binary READ BINARY and update the binary UPDATE BINARY command to achieve large-capacity data transfer.

(2) Establishing a logical channel: Since both the mobile terminal and the smart card can support multiple applications, a mechanism for simultaneously transmitting data with multiple applications is also required between the mobile terminal and the smart card. A token that represents a different application or file.

(≡) Use "Next Data Block Length Identifier": Due to the mobile terminal's shielding of the underlying commands, it is often impossible to use status words such as 0x9FXX, 0x9EXX, and 0x91XX to tell the receiver whether the data has been transferred. Therefore, the present invention uses the "next data block length identifier" in the transmission identifier of each data packet to indicate whether the current data transmission is completed, to indicate whether it is necessary to continue to transmit the APDU command. The receiving end can decide whether to continue the APDU transmission according to the "next data block length identifier". When the value of "Next Data Block Length Identifier" is 0x00, it means that no data can be transmitted, and this transfer ends; when the "Next Data Block Length Identifier" value is non-zero, it means The number of bytes that need to be transferred by the next APDU command. Through this mechanism, it is possible to automate the transfer of large-capacity data.

(4) Verification: Since large-capacity data needs to be transmitted using multiple APDUs, the amount of data transmitted each time is relatively large. Therefore, in order to ensure the integrity and reliability of the data, a data verification mechanism needs to be added: that is, each n (n > 1) APDU command is sent, and after n pieces of data are transmitted, the n pieces of data are verified, when the check is performed. When data is found to be incorrect, n blocks of data are retransmitted. The number of data blocks transmitted last k n . When n=l, each piece of data is checked once. When a check error is found, the sender resends the APDU command and corrects the erroneous data in time. When n is all the data blocks to be transmitted, all the data needs to be verified once after the transfer is completed, but once the data error is found, all the data blocks need to be retransmitted.

Ω cascading check: Since large files need to be decomposed into multiple data blocks for transmission, in order to prevent data merging errors, the present invention further uses cascading verification methods: except for the first transmitted η ( η > 1 ) block data When the corresponding data check value is generated, the check value is calculated together with the piece of data of the previous transmission and the η block data. In this way, the check value of the first transmitted n block data is calculated by using the n block data, and the check value of the subsequently transmitted n block data is obtained by using the previous piece of data and the transmitted _n block data. The η+1 block data is used to calculate the check value, and when the check value is calculated for the last transmitted k η block data, the check value is calculated by using the block data of the previous transmission and the k block data of the transmission to be k+1 block data. During verification, it is necessary to combine the n-block or k-block data of this transmission with the data of the previous transmission to calculate the check value, thereby preventing data link errors. (6) State byte SW1/SW2 redefinition: When the mobile terminal is used as the receiver, it can directly judge whether the transmission is successful by verifying the success or not, but when the mobile terminal is used as the sender, it is performed by using the APDU. During the data transmission, the status byte SW1/SW2 of the APDU command response can only indicate whether the APDU command is successfully executed. It cannot indicate to the mobile terminal that the transmission of the update binary file is successful, that is, the data verification cannot be determined successfully. Therefore, the present invention still uses the status byte to indicate the update status of the binary file APDU command. When the 0x9000 status byte is returned, it indicates that both the transmission and the verification are successful; when other values are returned, the transmission or verification error occurs, and the data is suspended. Transfer, and write the error status or information to a file that records the error status, then return the status byte of the transmission failure, wait for the sender to send an instruction to query the operation status, and then according to the situation Decide whether to resend the data or abort the transfer. Similarly, instructions for querying the operational status are also implemented by reading a specific error status log file using a common APDU command.

The third step is a detailed description of a data packet format and a corresponding data encapsulation process that can be applied to the large-capacity data exchange method between the mobile terminal and the smart card of the present invention:

( ) Packet format, as shown in Figure 3, the packet DATA is up to 256 bytes, encapsulated in the APDU command, including 2 bytes of transmission identification, up to 250 bytes of data block and 4 bytes of CRC32 check Value, where the transmission identifier includes a 1-byte logical channel and a 1-byte next data block length. When the next data block length is 00, this is the last transmission.

(2) The data encapsulation process, as shown in Figure 4, includes the following steps:

401) Data blocking and calculating check value: performing block processing on all data to be transmitted, decomposing into a size suitable for APDU command transmission, and generating a cascading check code for the transmitted data;

402) - 407) The data block to which the cascading check code is added is tagged with the corresponding transport identifier, and finally the encapsulated data packet is transmitted as the data body Data in the APDU command until all the data packets are transmitted.

When n=l, a cascading check code is generated for each piece of data transmitted, and the check code, the transmission identifier, and the transmitted block data are encapsulated; when 11>1, n pieces of data are transmitted. Generating a cascading check code, and encapsulating the check code, the transmission identifier, and a data block of n pieces of data, for example, the last data block of the n pieces of data, and encapsulating the transmission identifier and the remaining n-1 pieces of data The last transmitted data block kn, generates a cascode check code for the transmitted k block data, and encapsulates the check code, the transmission identifier and a data block of the k block data, for example, the last data of the k block data. The block encapsulates the transport identifier and the remaining k-1 block data.

Finally, the method of the present invention is described in detail by using an intelligent mobile terminal using the Windows Mobile operating system as an example:

(1) Windows Mobile Foundation

1 In the Windows Mobile operating system, it provides the SIM Manager API to achieve

SIM card data interaction. Part of the function is defined in the simmgr.h header file, which is used to obtain information from the SIM card and classify by function. These functions mainly include security, phone book, short message, file and so on. The functions that can exchange data with the SIM card are mainly phone book, text message, record/file Three types of operation functions. Two types of functions, phonebook and SMS, are mainly provided for specific data structures, such as phone book and text message, and are not applicable to custom data structures. If you need to transfer a custom data structure, use the record/file class. The operation function is more appropriate.

2 In Windows Mobile, support a variety of basic file structures specified by ISO/IEC 7816-4 and GSM 11.11:

1, transparent file: The file seen from the interface is a sequence of data units;

2, linear fixed length record file: a linear file with a fixed length record;

3, linear variable length record file: a linear file with variable length records;

4. A loop file with a fixed length record;

The specific file type encoding is as follows:

(2) Other foundations

The present invention implements data exchange by means of reading/writing/updating transparent files, and realizes exchange of large-capacity data by successive operations. The corresponding APDU commands in GSM11.11 are READ BINARY and UPDATE BINARY. The corresponding format is as follows:

The response parameters / data are as follows:

Bit bit description length

In the Windows Mobile system, the above-mentioned transparent file read and write function is completed by two functions SimReadRecord and SimWriteRecord. Since these two functions correspond to the APDU command described above, for the sake of brevity, the following uses the APDU command in the GSM protocol as an example.

1 Hardware requirements: Since the file size of the SIM card conforming to the ISO/IEC 7816 specification does not exceed 64 kbytes, the file size to be transmitted by the present invention should not be subject to any limitation. Therefore, the file system that requires the SIM card supports files larger than 64 kbytes, which can be achieved by using a common file system such as FAT16/32. The implementation problem of the SIM card operating system and its file system is not discussed in the present invention. Therefore, unless otherwise stated, the SIM card referred to in the present invention refers to a file access function having such a large capacity (more than 64 kbytes). SIM card. At present, the file system of the mobile terminal supports files exceeding 64 kbytes. Therefore, the present invention has no special requirements for mobile terminals.

2 APDU command: The data exchange between the mobile terminal and the SIM card may be bidirectional, and the data may be transmitted by the mobile terminal to the SIM card, or may be transmitted by the SIM card to the mobile terminal. However, since the APDU command is a master-slave structure, usually the mobile terminal actively sends an APDU command, and the SIM card passively receives and executes the APDU command, and returns the execution result. Therefore, in this embodiment, in order to maintain compatibility and adaptability to the prior art, the mobile terminal is still the active party, and the APDU command is sent; the SIM card acts as the slave, and receives the APDIL. When the mobile terminal needs to transmit to the SIM card, When the data is received, the mobile terminal actively sends an APDU command. When it is necessary to read data from the SIM card, it is also an APDU command that the mobile terminal actively initiates reading data. For mobile terminals and SIM cards that support active commands, the same design principle can be used. By extending the functions of ENVELOPE and FETCH, it is also possible to transfer and exchange large amounts of arbitrary data. Considering the limitation of active command support and openness of the upper layer application of the mobile terminal, in order to maximize the scope of use and improve compatibility, this embodiment uses a conventional (defined in the GSM 11.11 protocol) APDU command to implement an arbitrary format. Data transmission and exchange.

3 data checksum retransmission: In the embodiment of the present invention, if the data transmission error occurs, the last data transmitted may be retransmitted; and it is also required to tell the receiving end whether the data has been transmitted after each APDU transmission is completed. , Do you need to continue the transfer. To this end, for each piece of data that needs to be transmitted with the corresponding transmission identification and check value, the data packet format is shown in Figure 3, the first two bytes are transmission Identification, the last 4 bytes are the CRC32 check value, and the middle is the variable length data block to be transmitted, up to 250 bytes. The transmission identifier consists of two bytes, the first byte being a logical channel, indicating the protocol token of this transmission. The second byte is the next data block length identifier, which is used to indicate the number of bytes that the next APDU needs to transmit, and the maximum is 250 bytes. When the value is 0x00, it means that no data can be transmitted. This data transmission The process ends; when its value is non-zero (not exceeding OxFA), it indicates that there is still data to continue to transmit, and also indicates how many bytes need to be transferred by the next APDU command. The data block is verified by the CRC32 algorithm, and the cascading mode is used. Except that the check value of the first block is its own check value, the check value of other blocks is the block and the previous block. The check value of the cascaded result.

(≡) Specifically, the method for large-capacity data exchange between the mobile terminal and the smart card of the present invention specifically includes the mobile terminal transmitting large-capacity data to the SIM card and the SIM card to the mobile terminal in two directions, and there are four specific cases, which are respectively described as follows:

Case 1: As shown in FIG. 5, when the mobile terminal transmits large-capacity data to the SIM card, the UPDATE BINARY command is sent multiple times in succession to realize large-capacity data transmission, and when the SIM card receives the data packet sent by the mobile terminal, The data packet is unpacked, the corresponding data block is obtained, and the data block is verified; after the verification succeeds, the status byte of the successful execution is returned, and after receiving the successfully executed response APDU, the mobile terminal continues to send the remaining data. Until all packets are sent in the afternoon.

Case 2: As shown in FIG. 6, when the mobile terminal transmits large-capacity data to the SIM card, the UPDATE BINARY command is sent multiple times in succession to realize large-capacity data transmission, and when the SIM card receives the data packet sent by the mobile terminal, The data packet is unpacked, the corresponding data block is obtained, and the data block is verified; after the verification fails, the status byte of the execution failure is returned, and the reason for the failure is written to the file 0x2FA2 for recording the error status. When the mobile terminal receives the failed response APDU, it suspends sending the next APDU command, and reads the file 0x2FA2 of the recording error state, and determines whether to resend or stop after analyzing the cause.

In case 1 and case 2, each time the SIM card receives an APDU command, the received data block is written to the large-capacity data file and saved until the data is finally transmitted.

Case 3 and Case 4: Since the SIM card can only passively accept the APDU command, when the data needs to be read from the SIM card, the APDU command READ still needs to be actively sent by the mobile terminal. BINARY is implemented by reading a specific file multiple times (forming a dedicated APDU command). Since the maximum data capacity transmitted by each APDU command is 256 bytes, it is necessary for the SIM card operating system to update the data in the APDU command in time after the 256 bytes are transmitted, so that the mobile terminal can read the latter. data. The operation of data update is completely done by the SIM card operating system. This can be done either through the file system or by updating the transparent file in the GSM protocol. In this way, after each APDU command is executed, the APDU data to be transmitted is updated in time, and the update and the read are repeated multiple times, so that large-capacity data can be transmitted. The process is as shown in FIG. 6. After the mobile terminal fails to verify the data, it needs to write the error information to the error status record file in the SIM card to notify the SIM card to perform corresponding processing. After the SIM card is processed, a successful response APDU is returned. After that, the mobile terminal can re-send the APDU command READ BINARY of the read binary file to the SIM card to obtain data from the SIM card, as shown in FIG.

Claims

Rights request

A large-capacity data exchange method between a mobile terminal and a smart card, comprising the steps of:

1.1) using a general APDU command to establish a data transmission channel between the mobile terminal and the smart card; the protocol token of the smart card file establishes a specific logical channel; ⁵ '" 1.3) using the data transmission channel and the specific logical channel to block each of its transmission The block size conforms to the large-capacity data specified by the standard.

2. The data exchange method according to claim 1, wherein said universal APDU command comprises an open read binary READ BINART APDU command to the mobile terminal application, and a response and update binary UPDATE BINARY APDU command and response thereof.

The data exchange method according to claim 1, wherein the partition includes a divided block unit of the large-capacity data and a corresponding protocol token unit; wherein the last block includes an end flag.

The data exchange method according to claim 3, wherein the partition further includes a next data block length unit, and the value of the next data block length unit indicates 0, and the end flag is indicated.

The data exchange method according to claim 3 or 4, wherein the block further comprises a data check unit, wherein the step 1.3) comprises the sender calculating the check value, and encapsulating the check value into The verification unit, and the receiving party perform a process of receiving data verification according to the data verification unit.

The data exchange method according to claim 5, wherein when the mobile terminal application performs data transmission to the smart card, the step 1.3) includes the smart card transmitting a command execution and a calibration to the mobile terminal application by using a status byte of the APDU command response. Success/failure.

The data exchange method according to claim 6, wherein the step 1.3) may further include re-transmission after command execution or verification failure; and the retransmission includes using the read binary The READ BINARY APDU command and its response get the error status log file.

The data exchange method according to claim 5, characterized in that each of said blocks includes a data check unit corresponding to its own data.

The data exchange method according to claim 5, characterized in that each of said plurality of said blocks comprises a data check unit corresponding to data of said plurality of said blocks.

The data exchange method according to claim 5, characterized in that each of said blocks includes a data check unit corresponding to the data of the block and the previous block in which it exists.

The data exchange method according to claim 5, characterized in that each of said plurality of said blocks includes a data check unit corresponding to data of said plurality of blocks and a previous block thereof.