JP2008146343A - Ic card, and method for calling update program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an IC card that can eliminate effects of update programs on undesignated applications when the update programs are loaded in an EEPROM. <P>SOLUTION: A ROM 21 is loaded with a dedicated OS 3a where an OS and applications 3b are integrated, and the EEPROM 22 stores update programs 32 to function programs loaded in the ROM 21, and a function management table 31 describing application identifiers allowed to call the update programs 32 and call addresses in association with identification information about the function programs pertinent to the update programs 32. If the identification information about any function program called by the application 3b is described in the function management table 31 in the EEPROM 22, a kernel 3 of the dedicated OS 3a manages the call to the update program 32 with the use of the application identifier of the calling application 3b. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an IC card in which an IC chip is mounted on a credit card size card medium, and more particularly to a technique for replacing a function program mounted in a nonvolatile memory.

  An IC card in which an IC chip is mounted on a credit card size card medium is roughly classified into two types according to an operating system (OS) mounted on the IC chip. A multi-application IC card on which a multi-application OS is mounted, and a dedicated IC card on which a dedicated OS, also referred to as Native OS, is mounted.

  A multi-application type IC card has a platform type OS represented by Java (registered trademark) and MULTOS (registered trademark) mounted in ROM, and the application is stored in an electrically rewritable nonvolatile memory (for example, EEPROM). Implement.

  By mounting the application on the EEPROM, there is a merit that the application can be added / deleted after the IC card is issued. However, since the capacity of the EEPROM becomes large, there is a demerit that the IC chip is expensive.

  On the other hand, in the dedicated IC card, a dedicated OS in which the OS and application code are integrated is mounted on the ROM, and only data is stored in the EEPROM. With a dedicated IC card, a dedicated OS is mounted in the ROM, so there is a demerit that applications cannot be added / deleted after the IC card is issued, but a large-capacity EEPROM is not required, so the IC chip can be made inexpensive. There is.

  In such an IC card, as in the case of a personal computer, when a problem is found in the program installed on the IC card (for example, the vulnerability of the encryption algorithm), or when a program needs to be upgraded, It may be necessary to modify the program after issuing the IC card.

  In the multi-application type IC card, if the program that requires correction is an application, it can be dealt with by loading the corrected application into the EEPROM.

On the other hand, in the dedicated IC card, the program mounted in the ROM cannot be corrected. Therefore, when the IC chip on which the corrected program is mounted is remanufactured or the IC chip is not remanufactured. This is dealt with by adding an update program for replacing a part of the program installed in the ROM to the EEPROM using the technique disclosed in Patent Document 1.
JP 2003-132315 A

  However, if a function called from multiple applications is implemented in ROM and you want to change the function processing for only one of those applications, create an update program considering the effect on other applications that do not require modification. As a result, there is a problem that not only is it time-consuming to create the update program, but also the capacity of the update program increases.

  Therefore, according to the present invention, there is a problem in the function program installed in the ROM, and when the update program is installed in the EEPROM, the update implemented in the EEPROM is not applied to an application that does not require the function processing to be changed. An object of the present invention is to provide an IC card and an update program calling method that can eliminate the influence of the program.

  In a first invention for solving the above-described problem, a dedicated OS in which an operating system (OS) and an application are integrated is mounted on a non-rewritable first nonvolatile memory, and is mounted on the first nonvolatile memory. An IC card capable of mounting an update program for replacing a program of a function on a second electrically rewritable non-volatile memory, wherein the IC card is updated for each of the update program and the update program. A function management table in which the identification information of the application permitted to call the update program and the call address used when calling the update program are described in association with the program identification information of the function to be programmed In the second nonvolatile memory, and the dedicated OS When the identification information of the function program called from the application is described in the function management table, the identification information of the application calling the function program and the identification information of the function program The identification information of the application described in association is confirmed to match, and the update program is called only when they match.

  According to the first invention, a program of the function called from a plurality of the applications is mounted in the first nonvolatile memory, and the function processing is changed only for one of the applications. If only the identification information of the application to which the update program is applied is described in the first function management table stored in the second nonvolatile memory, the application to which the update program is not applied On the other hand, the influence of the update program mounted on the second nonvolatile memory can be eliminated.

  Further, the second invention is the IC card according to the first invention, wherein the IC card includes, for each function program mounted in the first nonvolatile memory, identification information of the function program. In association with the first nonvolatile memory, a second function management table in which identification information of the application permitted to call the function program and a call address used when calling the function program is described. And when the function program identification information called from the application is not described in the first function management table, the function program is called using the second function management table. Features.

  According to the second invention, it is possible to call the function program stored in the first nonvolatile memory for the application to which the update program is not applied.

  Furthermore, a third aspect of the invention relates to an electrically rewritable second IC card mounted on a non-rewritable first non-volatile memory with a dedicated OS in which an operating system (OS) and an application are integrated. An update program call management method for replacing a function program stored in a non-volatile memory and implemented in the first non-volatile memory, the update program, and for each update program, a target of the update program In association with function identification information that is information for identifying the program of the function, application identification information that identifies the application that is permitted to call the update program, and a call address that is used when calling the update program are described. The function management table stored in the second nonvolatile memory When the function management table describes the identification information of the function program that is stored and called from the application, the identification information of the application that called the function program and the identification of the function program. Whether the identification information of the application described in association with the information matches is confirmed, and the update program is called only when they match.

  Furthermore, a fourth invention relates to the update program call management method according to the third invention, wherein each function program implemented in the first nonvolatile memory is associated with identification information of the function program. A second function management table in which identification information of the application permitted to call the function program and a call address used when calling the function program are stored in the IC card. When the function program identification information stored in the non-volatile memory and called from the application is not described in the first function management table, the function program is stored using the second function management table. It is characterized by calling.

  According to the third to fourth inventions described above, the same effects as the first to second inventions described above can be obtained.

  According to the present invention described above, there is a problem in the function program installed in the ROM, and when the update program is installed in the EEPROM, it is installed in the EEPROM for an application that does not need to change the function processing. An IC card that can eliminate the influence of the update program and a method for calling the update program can be provided.

  A dedicated IC card (hereinafter abbreviated as IC card) to which the present invention is applied will be described in detail with reference to the drawings.

  FIG. 1 is an external view of an IC card 1 to which the present invention is applied. As shown in FIG. 1, the IC card 1 is a plastic card having the same size as a cash card or a credit card, and an IC module 1a in which an IC chip 2 is molded is mounted on the IC card 1.

  In FIG. 1, the IC card 1 is illustrated as a contact IC card, but the present invention does not depend on the communication method of the IC card 1, and is a non-contact IC card or contact data for wireless data communication. A dual interface IC card having two communication functions of communication and non-contact data communication may be used.

  In addition, regardless of the shape of the IC card 1, the IC card 1 is not the same shape as the cash card, but is a SIM (Subscriber Identity Module) having a shape obtained by cutting the vicinity of the IC module 1a into a strip shape. Also good.

  FIG. 2 is a hardware configuration diagram of the IC chip 2 embedded in the IC card. The IC chip 2 includes a central processing unit 20 (CPU: Central Processing Unit) having a calculation function and a function for controlling devices included in the IC chip 2, and a random access memory 23 (RAM: Random Access Memory) as a volatile memory. Read-only nonvolatile memory 21 (ROM: Read Only Memory), EEPROM 22 (EEPROM: Electrically Erasable Programmable Read-Only Memory) as electrically rewritable nonvolatile memory, and external terminal device and data An I / O circuit 24 for communication is connected to the BUS 25.

  The present invention does not limit the specifications of the IC chip 2 mounted on the IC card 1, and the IC chip 2 having specifications suitable for the application of the IC card 1 can be selected. For example, the capacities of the ROM 21 and the EEPROM 22 are not limited, and the rewritable nonvolatile memory may be a memory such as a flash memory. The IC chip 2 may include other circuits not shown such as a cryptographic operation circuit and a timer circuit.

  FIG. 3 is a diagram for explaining programs and data stored in the memory of the IC chip 2. As described above, since the IC card 1 is a dedicated IC card, the dedicated OS 3a in which the OS and the application 3b are integrated is mounted on the ROM 21, and the application 3b included in the dedicated OS 3a is identified to identify each application 3b. An application identifier (Application Identifier) which is information for specifying 3b is given to the application 3b.

  The dedicated OS 3a mounted on the ROM 21 includes a kernel 3 including a function group 30 that is a set of function programs called from the OS itself or the application 3b. The kernel 3 calls a function program from the application 3b. Is provided with a function management table 31.

  In the present invention, as shown in FIG. 3, the EEPROM 22 is provided with an update program area 22 a for storing the update program 32 in addition to the data area 22 b for storing data, and the update program 32 is mounted on the EEPROM 22. At the same time, the function management table 31 for the update program 32 is mounted in the update program area 22a of the EEPROM 22 together with the update program 32.

  In the future, when it is desired to clearly distinguish the function management table 31 mounted on the ROM 21 and the EEPROM 22, the memory mounted after the function management table 31 is described in parentheses. That is, the function management table 31 mounted on the ROM 21 is described as a function management table 31 (ROM), and the function management table 31 mounted on the EEPROM 22 is described as a function management table 31 (EEPROM).

  FIG. 4 is a diagram for explaining the structure of the function management table 31 (ROM). The function management table 31 (ROM) is composed of management records 310 in which information for managing calling of programs of functions included in the function group 30 is described.

  The management record 310 is a variable-length data record, and each function program included in the function group 30 is given function identification information that is information for identifying each function program. The application identifier of the application 3b that is permitted to call the function program specified by the function identification information in association with the function identification information, and a call that is an address when calling the function program specified by the function identification information The address is described in a TLV (type / length / value) format.

  Note that the application identifier included in the management record 310 is not limited to one, and the management record 310 corresponding to the function program called from the plurality of applications 3b includes a plurality of application identifiers.

  When a function program included in the function group 30 mounted on the ROM 21 is modified, an update program 32 that is a program for replacing the function program is stored in the EEPROM 22, and when the update program 32 is stored in the EEPROM 22, Along with the update program 32, a function management table 31 for managing calls to the update program 32 is stored in the EEPROM 22.

  The structure of the function management table 31 (EEPROM) is the same as the structure of the function management table 31 (ROM) illustrated in FIG. 4, but the function management table 31 (EEPROM) has a management record 310 that includes a function to be replaced. The application identifier of the application 3b permitted to call the update program 32 and the address when calling the update program 32 are described in association with the function identification information of the program.

  In this embodiment, since the management code 310 is added to the function management table 31 (EEPROM) every time the update program 32 is stored in the EEPROM 22, the order in which the management codes 310 are added is known. The function management table 31 (EEPROM) has a variable length sequential file structure.

  When a function program included in the function group 30 is called from the application 3b, the kernel 3 refers to the function management table 31 and manages the calling of the function program. The contents that the kernel 3 manages to call function programs will now be described. FIG. 5 is a flowchart showing an operation in which the kernel 3 manages the call of the replacement program 33.

  When the kernel 3 receives a function program call request from the application 3b (step S1), at least the function identification number of the function program stored in the register of the IC chip 2 and called from the application 3b to the kernel 3 is delivered. Furthermore, the kernel 3 obtains the application identifier of the application 3b that has requested to call the function program by obtaining the application identifier of the application 3b being executed.

  When the kernel 3 receives the function program call request, the kernel 3 checks whether the function management table 31 (EEPROM) is stored in the EEPROM 22 (step S2).

  If there is a function management table 31 (EEPROM), the process proceeds to step S3, where the function management table 31 for searching the management record 310 is set in the function management table 31 (EEPROM), and there is no function management table 31 (EEPORM). In step S7, the function management table 31 for searching for the management record 310 is set in the function management table 31 (ROM) (step S4).

  As described above, when the update program 32 is stored in the EEPROM 22, the function management table 31 (EEPROM) stored in the EEPROM 22 is prioritized, and the function of the ROM 21 is executed by executing the update program 32 with priority. The function program included in the group 30 can be replaced.

  After setting the function management table 31 for searching the management table 310 in the function management table 31 (EEPROM) in step S3, the kernel 3 identifies the function identification delivered in step S1 from the function management table 31 (EEPROM). The management record 310 including information is searched. (Step S4).

  When searching for the management record 310 from the function management table 31 (EEPROM), the search is performed in the newly registered order, and the kernel 3 searches for the management record 310 including the function identification information delivered to the kernel 3 in step S1. Each time, the application 3b that called the function program is allowed to call the function program specified by the function identification information (step S5).

  The kernel 3 compares the application identifier delivered to the kernel 3 in step S1 with the application identifier included in the searched management record, thereby allowing the application 3b that called the function program to know the function specified by the function identification information. Check if the call is allowed.

  When calling of the function program is permitted by the application 3b, the kernel 3 calls the function specified by the function identification information using the call address described in the searched management record 310 (step S6). .

  In step S3, the function management table 31 for retrieving the management record 310 is set in the function management table 31 (EEPROM). Therefore, the program called by the kernel 3 in this step S6 is an update program stored in the EEPROM 22. 32.

  In step S5, when the function call specified by the retrieved management record 310 is not permitted by the application 3b that requested the function program call, the process returns to step S4, and the kernel 3 stores the function management table. The management record 310 of 31 (EEPROM) that has not been searched is searched for the management record 310 that matches the function identification number delivered to the kernel 3 in step S1.

  In step S4, even if all the management records 310 included in the function management table 31 (EEPROM) are searched, the function program specified by the delivered function identification information cannot be called, that is, the function identification number. If the management record 310 with the same ID cannot be searched, or if only the management record 310 with the function identification number that matches but the application identifier does not match can be searched, the process proceeds to step S7, and the kernel 3 The function management table 31 to be searched 310 is set in the function management table 31 (ROM).

  After setting the function management table 31 for searching the management table 310 in the function management table 31 (ROM) in step S7, the kernel 3 is transferred from the function management table 31 (ROM) to the kernel 3 in step S1. The management record 310 including the function identification information of the program of the selected function searches the function management table 31 (ROM). (Step S8).

  The management record 310 included in the function management table 31 (ROM) is searched, and the kernel 3 calls the function program each time the management record 310 including the function identification information delivered to the kernel 3 is searched in step S1. It is confirmed whether the application 3b is permitted to call the function program specified by the function identification information (step S9).

  The kernel 3 compares the application identifier delivered to the kernel 3 in step S1 with the application identifier included in the searched management record, thereby allowing the application 3b that called the function program to know the function specified by the function identification information. Check if the program is allowed to be called.

  When calling of the function program is permitted by the application 3b, the kernel 3 uses the call address described in the searched management record 310 to call the function program specified by the function identification information (step S10). ).

  In step S7, the function management table 31 for retrieving the management record 310 is set in the function management table 31 (ROM). Therefore, the program called by the kernel 3 in this step S10 is an update program stored in the ROM 21. 32.

  As described above, the IC card 1 according to the present invention includes the function management table 31 as illustrated in FIG. 4, and manages the function program call from the application 3 b based on the function management table 31. It is possible to correct each function program installed in the ROM 21.

  Further, the function management table 31 is stored in the EEPROM 22, and the application identifier of the application 3b that is permitted to call the update program 32 in the function management table 31 (EEPROM) is described, so that the application that is not the target of the update program 32. The influence of the update program can be eliminated with respect to 3b.

  The above-described content will be described in detail with a specific example. 6 is a diagram showing an example of the function management table 31. FIG. 6A is a function management table 31a which is an example of the function management table 31 (ROM), and FIG. It is a function management table 31b which is an example of an EEPROM).

  As shown in FIG. 6A, three management records 310a are described in the function management table 31a, and the function identification information is “01” and “02”, respectively.

  Based on the management record 310a having the function identification information “01”, the application identifiers of the applications 3b that are permitted to call the function program having the function identification information “01” are “App1”, “App2”, and “App2”. In “App3”, the calling address is “address R1”.

  Further, based on the management record 310a having the function identification information “02”, the application identifiers of the applications 3b permitted to call the function program having the function identification information “02” are “App1” and “App2”. And “App3”, the calling address is “address R2”.

  As shown in FIG. 6B, two management records 310b are described in the function management table 31b, and the function identification information of the two management records 310 is “01”.

  If the registration order is based on the old management record 310b, the application identifier of the application 3b that is permitted to call the update program 32 is “App1”, “App2”, and “App3”, and the call address is “address E1”. is there.

  If the registered order is based on the new management record 310, the application identifier of the application 3b that is permitted to call the update program 32 is “App2” only, and the call address is “address E2”.

  According to the function management table 31b illustrated in FIG. 6B, the EEPROM 22 of the IC card 1 stores two update programs 32 of the function program having the function identification number “01” and is registered. The update program 32 having the oldest order is allowed to be called from the application 3b having the application identifiers “App1”, “App2”, and “App3”, and the update program 32 having the newest registered order has the application identifier “App2”. Calling is permitted only from the application 3b.

  Since the function management table 31b is stored in the EEPROM 22 based on the flow illustrated in FIG. 5, the function management table 31 for searching the management record 310 is set in the function management table 31b illustrated in FIG. 6B. The

  When the function program with the function identification number “01” is called from the application 3b, the kernel 3 confirms the application identifier of the application 3b that called the function program.

  Since the kernel 3 searches the management record 310b in the registered order, if the application identifier of the application 3b that called the function program is “02”, the management record 310b in the new registration order is selected, and the “address The update program 32 is called using “E2”. If the application identifier is “01” or “03”, the management record 310b in the registered order is selected, and the update program 32 is called using “address E1”.

  When the function program having the function identification number “02” is called from the application 3b, the management record 310b having the function identification number “02” is stored in the function management table 31b illustrated in FIG. 6B. Therefore, the management record 310a having the function identification number “02” is retrieved from the function management table 31a illustrated in FIG. 6A, and the management record 310a having the function identification number “02” is used. A function program implemented in the ROM 21 is called.

1 is an external view of an IC card. 1 is a hardware configuration diagram of an IC chip. FIG. The figure explaining the program and data which are memorize | stored in the memory of IC chip. The figure explaining the structure of a function management table. The flowchart which showed the operation | movement in which a kernel manages the call of a replacement program. The figure which showed an example of the function management table.

Explanation of symbols

1 IC card 2 IC chip 21 ROM, 22 EEPROM
3 OS dedicated to kernel 3a
3b application 30 function group 31 function management table, 310 management record 32 update program

Claims (4)

  A dedicated OS in which an operating system (OS) and an application are integrated is mounted on a non-rewritable first non-volatile memory, and an update program that replaces a function program mounted on the first non-volatile memory is An IC card that can be mounted on a second rewritable memory that is rewritable, wherein the IC card includes, for each of the update programs, identification information of a program of the function that is a target of the update program. In association with the second function, an area for storing a first function management table in which identification information of the application permitted to call the update program and a call address used when the update program is called is stored in the second function management table. In the nonvolatile memory, the dedicated OS is called from the application. When the function program identification information is described in the first function management table, it is associated with the identification information of the application that called the function program and the identification information of the function program. An IC card characterized by confirming whether the described identification information of the application matches, and calling the update program only when they match.   2. The IC card according to claim 1, wherein the IC card calls the function program in association with identification information of the function program for each function program mounted in the first nonvolatile memory. The first nonvolatile memory includes a second function management table in which identification information of the application that is permitted and a call address used when calling the function program is described, and the function is called from the application. When the function program identification information is not described in the first function management table, the function program is called using the second function management table.   In an IC card mounted on a non-rewritable first non-volatile memory, a dedicated OS in which an operating system (OS) and an application are integrated is stored in an electrically rewritable second non-volatile memory, An update program calling method for replacing a function program installed in a first non-volatile memory, wherein the update program and information for identifying the program of the function that is a target of the update program for each of the update programs A first function management table in which application identification information for specifying the application permitted to call the update program and a call address used when calling the update program are associated with the function identification information. Storing in the second non-volatile memory; When the identification information of the program of the function called from the application is described in the first function management table, the identification information of the application that requested the calling of the function program and the identification information of the function program A method for calling an update program, comprising: checking whether the identification information of the application described in association with each other matches, and calling the update program only when they match. 4. The update program calling method according to claim 3, wherein the function program is allowed to be called in association with identification information of the function program for each function program installed in the first nonvolatile memory. The second function management table in which the identification information of the application and the call address used when calling the function program is described is stored in the first nonvolatile memory of the IC card, When the identification information of the called function program is not described in the first function management table, the function program is called using the second function management table.

Images