JP4620418B2 - Real-time command processing method, IC card, and embedded terminal - Google Patents

Description

  The present invention relates to a technique for processing a plurality of commands in an IC card.

  In recent years, IC cards for incorporation into devices such as subscriber identification modules (SIM, UIM) in mobile phones have begun to become widespread.

  At present, the standard of an IC card such as UIM is defined in ISO 7816-4, and is operated by a mechanism based on this standard (see Non-Patent Document 1).

ISO7816 specification

  When an APDU (Application Protocol Data Unit) defined in ISO7816 receives a certain command, it does not accept the next command unless a response to that command is received. That is, the command is defined on the assumption that the command from the application B is not received during the execution of the command from the application A.

  On the other hand, an authentication specification “WLAN-SIM VO.1” for ensuring security in a wireless LAN by incorporating a UIM into a device such as a PDA is being examined by the industry group WLAN Smart Card Consortium. In the future, various home appliances and various control devices connected to the network are likely to adopt such UIMs as security modules. Then, even in the IC card, it becomes necessary to process a large number of commands. However, as described above, since the ISO 7816 standard is widely used for the command of the IC card, it is desired to correspond without changing the standard.

  SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a real-time command creation / processing method capable of processing a plurality of commands using a command of a conventional standard, an IC card, and an embedded terminal thereof. And

In order to solve the above problem, in the present invention, an ID and a priority are added before the original command to encapsulate it as a data part, and a part that plays the same role as the header part of the original command is encapsulated. Create a real-time command, which is a command added in front of the data part , and process the command according to the priority recorded in the processing waiting list on the IC card. If the received command is a real-time command, the original command encapsulated is extracted and processed together with the priority recorded in the real-time command. It is characterized in that it is recorded in a waiting list .

  According to the present invention, the original command normally used in the IC card is encapsulated as it is, the priority and ID information is added, and the same header as the original command is added to obtain a real-time command. It is possible to process a plurality of commands by using a command of a standard that assumes only one conventional command process.

DESCRIPTION OF EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.
(Configuration of IC card)
FIG. 1 is a functional block diagram of an IC card according to the present invention. In FIG. 1, 1 is an IC card, 2 is a communication I / F (interface), 3 is communication detection means, 4 is a CPU, 5 is an interrupt unit, 6 is an information storage area, and 10 is a terminal. The communication I / F 2 is an interface for communicating with an external terminal (device), and transmits and receives data corresponding to various methods such as a contact method such as a USB and a non-contact method via an antenna. It is. The communication detection unit 3 has a function of detecting data transmitted from an external terminal and transmitting it to the CPU 4. The CPU 4 has a function of executing an OS and performing data processing in the IC card 1. The interrupt unit 5 has a function of interrupting data processing being executed by the CPU 4 based on an instruction from the communication detection unit 3. The information storage area 6 is an area for storing information necessary for data processing, communication, and the like, and secures a process waiting list and an area as a transmission buffer, which will be described later. It has the function to transmit to the communication detection means 3 and CPU4 shown in FIG. The CPU 4, the interrupt unit 5, the information storage area 6, and a part of the communication I / F 2 are realized in an IC chip provided on the IC card. The terminal 10 is a terminal device that includes an input keyboard, buttons, and the like, and a display device such as a liquid crystal display, and is realized by a personal computer or a mobile terminal that has an IC card read / write function.

(Commands used in IC cards)
Here, the format of a command sent from the terminal to the IC card, which is defined in ISO-7816part-4, will be described. A command format defined in ISO-7816part-4 is shown in FIG. As shown in FIG. 2A, the command sent from the terminal to the IC card has a header composed of CLA, INS, P1, P2, and Lc added in front of the data portion. CLA, INS, P1, P2, and Lc are each recorded in 1 byte. CLA in the header means a class, and indicates a classification of a command such as whether the command conforms to ISO or has a security function. INS specifies a command. P1 and P2 are parameters for the command. Lc is the length of the data part. For example, when the password “0A 0B 0C 0D” is transmitted by the VERIFY command, it is as shown in FIG. The VERIFY command is a command used to send a password or the like from the terminal, collate it with the password in the IC card, and as a result, determine whether or not to perform subsequent processing, and is represented by “20”. In the present specification, unless otherwise specified, the data in the command is expressed in hexadecimal. That is, two numbers form one byte.

  Next, a method for creating a real-time command according to the present invention will be specifically described. When creating a real-time command in the terminal, first, a command conforming to ISO7816 is created and used as the original command. As described above, this original command has a configuration as shown in FIG. The terminal further creates a real-time command having a configuration as shown in FIG. That is, in the data part, the ID is stored in the first byte, the priority parameter is stored in the next byte, and the original command is stored in the third and subsequent bytes of the data part. Further, a header that plays the same role as the header of the original command is added to the header. However, in the real-time command, the CLA value is a fixed value of “D0” and the INS value is “00”, which indicates that this combination is a real-time command. The terminal transmits the created real-time command to the IC card 1.

  In the IC card 1, when the communication I / F 2 receives a command, the communication detection unit 3 detects the communication and transmits it to the interrupt unit 5 of the CPU 4. In this case, even if there is a command process being executed, the CPU 4 interrupts the command process and performs a command reception process. Subsequently, the CPU 4 determines whether or not the received command is a real-time command. Specifically, the values of CLA and INS at the head of the command are confirmed. If these values are “D0” and “00”, it is determined that the command is a real-time command, and if other than “D0” and “00”, It is determined that it is not a real-time command. If the command is not a real-time command, the priority of the command is set to a preset default value (eg, “80”), and a free ID number is assigned. If it is a real-time command, it is checked whether the ID of the command exists in the command processing waiting list, and if it exists, an error is returned. If the ID does not exist in the list, the ID is not duplicated on the processing waiting list, so the command is added to the processing waiting list according to the priority of the received command. This completes the interrupt process.

  When the interrupt process is completed, the CPU 4 checks and executes the command with the highest priority in the process waiting list. When the execution of one command is completed, the corresponding ID is added to the first byte, the result is transmitted, and the command is deleted from the processing wait list. If there is a command in the processing waiting list, the command is executed from the command with the highest priority in the list.

  Here, the flow of the entire processing of the CPU 4 in the IC card 1 will be described with reference to the flowchart of FIG. First, the IC card 1 is inserted into the terminal 10 and receives power supply from the terminal 10. Then, the OS activated by the CPU 4 returns an ATR (answer to reset: initial response) to the terminal (S1). The OS confirms whether there is a command waiting for processing (S2). Specifically, the processing waiting list is confirmed, and it is confirmed whether or not the command exists on the list.

  If there is a command waiting for processing, the command with the highest priority is executed (S3). When the execution of the command is completed, the processing result is set in the transmission buffer (S4). Further, the buffer contents are transmitted to the terminal via the communication I / F 2 (S5). Then, the command that transmitted the processing result in S5 is deleted from the processing waiting list (S6). The processing from S2 to S6 is looped unless an interrupt is entered.

  When the communication I / F 2 receives the command and the communication detection unit 3 notifies the CPU 4 of the start of communication via the interrupt unit 5, the OS activated by the CPU 4 interrupts the process being executed (S7). At this time, the interruption is performed in such a state that it can be resumed later. Subsequently, a command is received (S8). Further, the contents of the received command are analyzed (S9). As a result, it is determined whether or not the received command is a real-time command (S10). If the received command is not a real-time command, a priority set as a default and a free ID are assigned (S11). On the other hand, if the received command is a real-time command, it is determined whether or not the ID is duplicated (S12).

  If the IDs overlap, an NG message (error) is set in the transmission buffer (S13). Then, the contents of the transmission buffer are transmitted to the terminal 10 (S14), the process returns to S2, and the loop processing is repeated. On the other hand, if the IDs are not duplicated, the priority and the original command are extracted (S15). Then, it is added to the processing waiting list according to the priority (S16). Note that the processing of S16 is also performed for a command given a priority and a free ID. After the process in S16, the process returns to S2 to repeat the loop process.

(Specific example)
Next, with reference to a specific example, creation of a real-time command in the terminal and processing of the real-time command in the IC card will be described. FIG. 4 shows the data array of the original command defined in ISO-7816part-4 and the data array of the real-time command created by the terminal 10 for the VERIFY command for collating the password. FIG. 5 shows the data array of the original command defined by ISO-7816part-4 and the data array of the real-time command created by the terminal for the key generation command for generating the key.

  The original command shown in FIG. 4A indicates that the INS is “20” indicates the VERIFY command, and indicates that collation is performed on any 128-byte data indicated by “xx xx... Xx” in the drawing. . Lc is “80” because the data portion is 128 bytes, so “128” is expressed in hexadecimal. The real-time command shown in FIG. 4B is created by encapsulating the original command shown in FIG. As shown in FIG. 4B, the real-time command is a new data part obtained by adding an ID and priority to the original command. The combination of the leading CLA and INS being “D0” “00” indicates a real-time command as described above. Lc is “87” because the data part is 135 bytes (ID 1 byte + priority 1 byte + original command 133 bytes), so “135” is expressed in hexadecimal.

  The original command shown in FIG. 5A indicates that the key generation command indicates that INS is “46”, and indicates that key generation is performed using an arbitrary 1-byte data indicated by “xx” in the figure as a parameter. ing. Lc is “01” because “1” is expressed in hexadecimal since the data portion is 1 byte. The real-time command shown in FIG. 5B is created by encapsulating the original command shown in FIG. As shown in FIG. 5B, the real-time command is obtained by adding an ID and priority to the original command as a new data part. The combination of the leading CLA and INS being “D0” “00” indicates a real-time command as described above. Lc is “08” because the data part is 8 bytes (ID 1 byte + priority 1 byte + original command 6 bytes), so “8” is expressed in hexadecimal.

  From now on, a total of three cases will be described: the case of processing the VERIFY command shown in FIG. 4 and the case of transmitting the VERIFY command shown in FIG. 4 and the key generation command shown in FIG. In any of the following cases, the ID of the VERIFY command is “01”, the priority is “01”, the ID of the key generation command is “0A”, and the priority is “80”. As for the priority, “00” is the highest priority and “FF” is the lowest priority.

  First, a process in the case where the terminal 10 collates a password using the VERIFY command will be described. In this case, the terminal generates, as an original command, a VERIFY command as shown in FIG. 4A, in which the code number input from the terminal key is incorporated as data in the data part. Further, the terminal encapsulates the original command to create a real-time command as shown in FIG. At this time, the terminal determines the ID and priority, and sets them in the sixth and seventh bytes of the real-time command. The terminal determines and assigns an ID that does not overlap with other commands being issued according to a predetermined rule for the ID, and the priority is within a predetermined numerical range according to the command. Give something that doesn't overlap. The created real-time command is transmitted from the terminal to the IC card 1.

  Then, an interrupt occurs in the IC card 1, and the OS (CPU) receives a real time command. Subsequently, CLA and INS of the received real-time command are checked. In this case, since it is “D0” “00” as shown in FIG. 4A, it is determined to be a real-time command. Next, the 6th byte ID is read, and it is confirmed whether or not the read ID exists in the processing waiting list. At this time, since there is no command in the processing waiting list, and therefore there is no command with ID = “01”, the priority of the seventh byte is read and the original command after the eighth byte is taken out. . Then, the ID, priority, and original command are registered in the processing waiting list. As a result, the interruption ends, and the OS checks the processing waiting list. Then, the VERIFY command with the priority “01” is executed. The OS stores the processing result of the VERIFY command in the transmission buffer, transmits it to the terminal, and deletes it from the processing waiting list. Since there is no registered command in the processing waiting list, the loop processing is entered until an interrupt is received after receiving a command from the terminal. The terminal confirms that the received command ID is 1, and processes the response. The response is, for example, whether the result of VERIFY is OK or NG.

  Next, a case where a VERIFY command is issued during key generation will be described. For the key generation command, the terminal sets appropriate parameters and generates a key generation command as shown in FIG. 5A as the original command. Further, the terminal encapsulates this original command, creates a real-time command as shown in FIG. 5B, and transmits it to the IC card 1.

  Then, an interrupt occurs in the IC card 1, and the OS (CPU) receives a real time command. Subsequently, CLA and INS of the received real-time command are checked. In this case, since it is “D0” “00” as shown in FIG. 5A, it is determined to be a real-time command. Next, the 6th byte ID is read, and it is confirmed whether or not the read ID exists in the processing waiting list. At this time, there is no command in the processing waiting list, and therefore there is no command with ID = “0A”. Therefore, the priority of the seventh byte is read and the original command after the eighth byte is taken out. . Then, the ID, priority, and original command are registered in the processing waiting list. As a result, the interruption ends, and the OS checks the processing waiting list. Then, the key generation command having the highest priority in the processing waiting list is executed with the priority = “0A”.

  While the OS on the IC card 1 is processing the key generation command, the terminal creates a real-time command as shown in FIG. 4B and transmits it to the IC card 1 in the same manner as described above. In the IC card 1, an interrupt occurs, and the key generation command being executed is suspended in a resumable state. Then, the OS (CPU) receives a real time command. Subsequently, CLA and INS of the received real-time command are checked. In this case, since it is “D0” “00” as shown in FIG. 4A, it is determined to be a real-time command. Next, the 6th byte ID is read, and it is confirmed whether or not the read ID exists in the processing waiting list. Since there is no command with ID = “01”, the priority of the seventh byte is read and the original command after the eighth byte is taken out. Then, the ID, priority, and original command are registered in the processing waiting list. As a result, the interruption ends, and the OS checks the processing waiting list. FIG. 6 shows the state of the processing waiting list at this time. Then, the VERIFY command having the priority “01” and the highest priority in the processing waiting list is executed. The OS stores the processing result of the VERIFY command in the transmission buffer, transmits it to the terminal, and deletes it from the processing waiting list. On the other hand, the terminal confirms that the ID of the received command is “01” and processes the response. The OS further checks the processing waiting list. Then, the key generation command having the priority “80” and the highest priority in the processing waiting list is executed. At this time, it is performed from the continuation to the point of interruption. The OS stores the processing result of the key generation command in the transmission buffer, transmits it to the terminal, and deletes it from the processing waiting list. Since there is no registered command in the processing waiting list, a loop processing is entered until an interrupt is received after receiving a command from the terminal. The terminal confirms that the received command ID is “0A” and processes the response. This response is, for example, whether the result of key generation is OK or NG.

  Next, the case where a key generation command is issued during VERIFY will be described. The terminal creates a VERIFY real-time command as shown in FIG. 4B and transmits it to the IC card 1 in the same manner as described above. Then, an interrupt occurs in the IC card 1, and the OS (CPU) receives a real time command. Subsequently, CLA and INS of the received real-time command are checked. In this case, since it is “D0” “00” as shown in FIG. 4B, it is determined to be a real-time command. Next, the 6th byte ID is read, and it is confirmed whether or not the read ID exists in the processing waiting list. Since there is no command with ID = “01”, the priority of the seventh byte is read and the original command after the eighth byte is taken out. Then, the ID, priority, and original command are registered in the processing waiting list. As a result, the interruption ends, and the OS checks the processing waiting list. Then, the VERIFY command having the priority “01” and the highest priority in the processing waiting list is executed.

  While the OS on the IC card 1 is processing the VERIFY command, the terminal creates a key generation real-time command as shown in FIG. To do. In the IC card 1, an interrupt occurs, and the VERIFY command being executed is suspended in a state where it can be resumed. Then, the OS (CPU) receives a real time command. Subsequently, CLA and INS of the received real-time command are checked. In this case, since it is “D0” “00” as shown in FIG. 4A, it is determined to be a real-time command. Next, the 6th byte ID is read, and it is confirmed whether or not the read ID exists in the processing waiting list. Since there is no command with ID = “0A”, the priority of the seventh byte is read and the original command after the eighth byte is taken out. Then, the ID, priority, and original command are registered in the processing waiting list. As a result, the interruption ends, and the OS checks the processing waiting list. Then, the VERIFY command having the priority “01” and the highest priority in the processing waiting list is executed. At this time, it is performed from the continuation to the point of interruption. The OS stores the processing result of the VERIFY command in the transmission buffer, transmits it to the terminal, and deletes it from the processing waiting list. On the other hand, the terminal confirms that the ID of the received command is 1, and processes the response. The OS further checks the processing waiting list. Then, the key generation command having the priority “80” and the highest priority in the processing waiting list is executed. The OS stores the processing result of the key generation command in the transmission buffer, transmits it to the terminal, and deletes it from the processing waiting list. Since there is no registered command in the processing waiting list, the loop processing is entered until an interrupt is received after receiving a command from the terminal. The terminal confirms that the received command ID is “0A” and processes the response. This response is, for example, whether the result of key generation is OK or NG.

It is a functional block diagram of the IC card according to the present invention. It is a figure which shows the format of an original command and a real-time command. 4 is a flowchart showing the overall processing flow of a CPU 4 in the IC card 1. It is a figure which shows the data arrangement | sequence of the original command and real time command regarding a VERIFY command. It is a figure which shows the data arrangement | sequence of the original command and real-time command regarding a key generation command. It is a figure which shows an example of a process waiting list.

Explanation of symbols

1 ... IC card 2 ... Communication I / F
3 ... Communication detection means 4 ... CPU
5 ... Interrupt unit 6 ... Information storage area 10 ... Terminal

Claims (3)

In processing the command according to the priority recorded in the processing waiting list on the IC card,
When a command is received from the outside, the processing of the command is interrupted, the step of determining whether the received command is a real-time command, and if the result of the determination is a real-time command, the encapsulated source extracting the commands, have a, a step of recording the process waiting list with recorded priority real-time command,
The real-time command, the addition to encapsulating as data unit adds the ID and priority before the original command, prepended to the data unit that encapsulates the header portion of the same serving portion of Motoko command method of processing real-time commands, characterized in der Rukoto those created by. The OS on the CPU executes the command according to the priority recorded in the processing waiting list, and the CPU interrupts the processing of the command being executed and receives the command based on the instruction from the interrupt unit. Determine whether the received command is a real-time command, and if the result is a real-time command, extract the original encapsulated command and record it in the processing waiting list with the priority recorded in the real-time command A terminal that transmits a real-time command to an IC card having a function of:
With encapsulating adds the ID and priority as the data portion before Motoko command, it creates a command which is prepended to the data unit that encapsulates the header portion of the same serving portion of Motoko command , IC card embedded terminal, characterized by transmitting real-time commands the created in the IC card. In accordance with the priority recorded in the processing waiting list, the OS on the CPU is an IC card that executes commands,
Communication detection means for detecting communication from an IC card embedded terminal ;
An interrupt unit that generates an interrupt based on a signal from the communication detection unit;
An information storage area for recording a waiting list for processing,
Based on the instruction from the interrupt unit, the CPU interrupts the processing of the command being executed and receives the command, determines whether the received command is a real-time command, in some cases, to extract the original command encapsulated, have a function of recording the process waiting list with priority recorded in real time command,
The real-time command is encapsulated as a data part by adding an ID and priority in front of the original command by the IC card embedded terminal, and encapsulating a part that plays the same role as the header part of the original command IC card according to claim Oh Rukoto in appended command before the Department.

Images