An IC card is currently becoming a focus of attention as a secure device. There are IC cards that simply store data and ones that actually come with an OS (Operating System). As examples of use of an IC card, there are various types of IC cards, such as a contact type IC card represented by a credit card and ETC (Electronic Toll Collection System) card, non-contact type IC card represented by a traffic system card and electronic money card, and it is expected that the development of new application fields and expansion in scale of application fields will be further promoted in the future.
On the other hand, the development of a multi-application card capable of downloading an application after card issuance is being carried forward aiming at improving convenience for users and reducing barriers to entering into the market by new service providers of IC cards.
Furthermore, a technology for mounting a secure device such as an IC card on a mobile device such as a portable terminal and downloading an application or using an application through the mobile device is proceeding toward practical utilization.
Here, the hardware configuration of an IC card will be explained using FIG. 1. FIG. 1 is a functional block diagram about the hardware of an IC card.
IC card 10 is provided with CPU (Central Processing Unit) 11, ROM (Read Only Memory) 12, volatile memory (example: RAM: Random Access Memory) 13, volatile memory (example: EEPROM: Electrically Erasable Programmable Read Only Memory) 14 and I/O IF 15.
CPU 11 carries out operations. ROM 12 is a read-only memory which is not rewritable. The contents stored in ROM 12 are determined at the time of manufacturing the IC card and cannot be changed later. RAM 13 is a readable/writable memory. EEPROM 14 is designed to maintain its contents even when power is turned off. I/O IF 15 is responsible for data exchange between IC card 10 and the outside. A program executed by CPU 11 is usually called an “application.” Codes for executing the application are stored in ROM 12 and EEPROM 14. When IC card 10 is subjected to encryption operation, IC card 10 is further provided with an encryption coprocessor in addition to the configuration shown in FIG. 1.
Between the application installed in IC card 10 and the outside (reader), data is exchanged using, for example, an APDU (Application Protocol Data Unit) which is a format defined by ISO/IEC7816-4. The APDU is made up of two components; a command message given from the reader to the IC card and a response message returned from the IC card to the reader.
The format of an APDU command will be explained using FIG. 2. FIG. 2 illustrates an example of the format of an APDU command.
APDU command 20 in FIG. 2 is made up of header 21 and body 22. Header 21 is made up of a class (CLA), instruction (INS) and parameters (P1, P2). Body 22 is made up of a field length of command data (Lc: Length of Command Data), data section and field length of response data (Le: Length of Expected Data). The capacity of the APDU command 20 is 1 byte for CLA, INS, P1, P2, Lc, Le each and 255 bytes for the data section, a total of 261 bytes at maximum.
A scheme for creating an APDU will be explained using FIG. 3. FIG. 3 is a conceptual diagram showing a scheme to divide data and create an APDU.
As described above, the capacity of one APDU command 20 is as small as 261 bytes, and therefore in order to send data that amounts to several K bytes when downloading an application, the sending data needs to be divided into a plurality of APDU blocks. The parameters (P1, P2) of each APDU block indicate a block number and whether or not there is any block that follows, and can thereby allow the IC card side to check consistency in the order of commands sent and the necessity for final processing.
Furthermore, an expansion whereby Lc is expressed in 3 bytes with the first byte indicating 3-byte notation and second byte and third byte indicating a data length is proposed, but there are extremely few examples of such mounting from the standpoint of memory capacity of an IC card.
For a device having a small memory capacity such as an IC card, an input buffer for storing received commands generally cannot have a large size. When an explanation is made using multi-application card, a certain area is permanently designated as an input buffer and shared among applications, and the memory capacity secured is thereby limited. The multi-application card updates “current AP information indicating a currently selected application” when an application is selected, refers to the current AP information when the next command is received, and can thereby reliably pass the command to the selected application.
The application is downloaded through a card manager. The card manager is an application in the multi-application card that manages the card and applications inside the card. “Management of card” refers to card issuance that stores IDs and keys necessary for a card issuer to manage the card in the card and causing the card after issuance to transition to locked state or terminated state. Furthermore, “management of application” refers to downloading and deleting of the application.
Furthermore, there is recently a proposal of a device which can use a large capacity memory from an IC chip as an IC card extended memory protection area (hereinafter referred to as “secure memory card”) and meet the need for an increase in capacity of IC card application data. Since the secure memory card can be adapted to the size of a mobile device, there is an expectation for its development into use in EC (Electronic Commerce) services using a mobile device with the secure memory card directly inserted into a slotted mobile device.
When a mobile device is used, communication is interrupted when located outside a radio wave range, which results in an increase in the likelihood of affecting the behavior of the card. Thus, when communication is interrupted, repetition processing such as doing downloading over again from the beginning or performing resending in mid-flow is proposed.
An example of such an IC card application program loading technology is disclosed in Patent Document 1. FIG. 4 is a block diagram of an IC card application program loading apparatus disclosed in Patent Document 1.
In FIG. 4, host computer 30 stores an application program, applies predetermined encryption processing (RSA: Rivest-Shamir-Adleman) to an application program and provides the application program as a divided component to IC card 50 through terminal apparatus 40. When the communication with host computer 30 is interrupted and exchange of data such as an application program is interrupted, IC card 50 sends a resending request for data other than the successfully received part to host computer 30. Then, when all components are received, these components are integrated, subjected to decoding processing and error detection processing. On the other hand, if the request is not successfully received even when a resending request is sent a predetermined number of times, sending of the resending request is stopped and the data successfully received and stored so far is erased.    Patent Document 1: Unexamined Japanese Patent Publication No. 2003-108384