JP2001034715A - System and method for verifying program for ic card at execution and ic card - Google Patents

Abstract

PROBLEM TO BE SOLVED: To remove the partial function of verification at execution from installed functions on an IC card whose memory resources, etc., are insufficient by sufficiently verifying an application program with a legitimate tool chain outside the IC card about the verification of the application program for the IC card at the execution. SOLUTION: A run time checker 16 and a coverage checker 18 performing the verification of an application program at execution are provided, a class file 2 (13) is inputted, and the checker 16 performs verification at execution together with appropriate test data 15. Whether a Class file has undergone a reasonable routine is decided by checking a signature added when the Class file is generated, and a Cap file 21 is generated from a Class file 3 (19) of after verification at execution. A loader 22 loads the Cap file 21 into an IC card.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION The present invention relates to the development of an application program for an IC card and the verification of the IC card by performing verification outside the IC card in a download mechanism.
The present invention relates to an IC card program execution time verification system and an IC card program execution time verification method related to improvement of technology for reducing a check routine and the like mounted in a C card.

[0002]

2. Description of the Related Art Conventionally, for example, according to the specification of JavaCard 2.0, a system is (1) an IC card from which an applet (application program) can be downloaded. (2) On the IC card, the virtual machine interprets and executes the machine-independent bytecode. (3) Perform an error check at the time of execution. (4) To develop an application program, use a dedicated tool to convert the application program into a downloadable state to an IC card.

[0003] Such a system is constituted by a system using an interpreter on an IC card and a tool whose main purpose is to enable application programs to be downloaded to the system.

FIG. 3 conceptually shows a conventional system for converting an application program into a downloadable JavaCard. In this system, a compiler, a post-processor 32 for checking whether the contents are within the range of the JavaCard specification that can be downloaded to an IC card, a converter 34 for converting to a downloadable format, and a loader 36 for actually downloading to an IC card are provided. It is configured.

The process of converting an application program into a downloadable state by this system is as follows.
It is as follows.

First, the output of the Java compiler is:
Post the JavaClass file 31 to the post processor 3
In step 2, it is checked whether the class file 31 is within the range of the JavaCard specification, and the validity of the class file 31 is also checked.
(33) is generated.

[0007] Next, by the converter 34, Clas
The s-file 2 (33) is converted into a format that can be downloaded to an IC card (referred to as a Cap file 35), and the loader 36 performs the process by downloading the Cap file 35 to an IC card (not shown). Was something.

In this process, the validity and the like of the class file 31 are confirmed by the post processor 32, but the verification and the like at the time of execution of the application program are all performed on the IC card.

On an IC card, a program is executed by an interpreter (referred to as a virtual machine) which does not depend on a machine to avoid runaway by performing a check at the time of execution.

As described above, in the conventional system described above, I
The main purpose is to convert and download so that it can be downloaded to the C card, and to operate a machine-independent interpreter on the IC card, and to cooperate to reduce the system on the IC card. Has not been taken into consideration or provided.

[0011]

As described above, in the conventional device, there is no function for guaranteeing the validity of the tool chain, and the execution verification of the application program is performed on the IC card. It is assumed that it is actually performed, and a CPU that is inferior in performance to a computer such as a personal computer that normally mounts an IC card is mounted, and a system for performing runtime verification is mounted on an IC card with little memory storage and computational resources However, there is a problem that the area is insufficient for the application program and the calculation speed is reduced.

Therefore, the present invention has been made in consideration of the above circumstances, and solves the above-mentioned disadvantages and sufficiently verifies the application with a legitimate tool chain provided outside the IC card, thereby enabling the application program to be implemented. An object of the present invention is to provide an IC card program execution time verification system and an IC card program execution time verification method that can remove some functions of the execution time verification from the mounting on the IC card.

[0013]

SUMMARY OF THE INVENTION In order to achieve the above object, the present invention provides an IC card program execution verification system for verifying that an IC card program operates correctly when the IC card program is executed on the IC card. A control flow analysis of the IC card program is performed to create an information file, and signature information for proving that the IC card program has passed a valid processing routine is added to a first class file obtained by compiling the source file of the IC card program. Control flow analysis means for generating a second class file; file execution means for executing the second class file based on the information file and test data for performing runtime verification to generate a runtime log; Refer to the runtime log and the information file and
Execution time verification means for determining whether or not all the paths of the C card program have been passed and, when all the paths have been passed, creating a third class file in which signature information is added to the second class file File conversion means for converting the third class file into a CAP file that can be downloaded to the IC card if the processing has passed a legitimate processing routine based on the signature information of the third class file; Program loading means for loading into an IC card.

According to such a configuration, it is possible to reduce the implementation by omitting the routine for checking at the time of execution of the application program for the IC card from the EEPROM or the IC card where the memory is severely restricted. Can be increased.

Further, by performing various checks including the execution verification of the IC card application program outside the execution system, it is possible to check the consistency with the execution system. Can be prevented from being executed at the time of execution.

Further, by checking the signature information, it is possible to verify whether the file downloaded to the IC card has passed a valid routine,
It can also prevent the downloading of files that have not gone through legitimate routines.

In order to achieve the above object, an IC card according to the present invention verifies an IC card program outside the IC card, based on a class file to which signature information indicating that the verification has been correctly performed is added. It is characterized in that it is downloaded into an IC card and does not have a check routine in the card.

According to the present invention, since the IC card program is verified outside the IC card and downloaded after its validity is confirmed, an IC card having no check routine in the card can be used. Obtainable.

[0019]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings.

FIG. 1 conceptually shows a program execution verification system according to this embodiment.

In this system, the conventional JavaCard
A run-time checker 16 for verifying the application program at the time of execution and a coverage checker 18 are added to the IC card applet (application program) development system of the specification.
With (13) as input, runtime verification is performed by the runtime checker 16 together with appropriate test data 15. Although not specifically shown, the program execution verification system of the present embodiment is performed on a computer such as a personal computer (PC), and each file, postprocessor, and the like are provided on the computer such as the PC. .

By the way, the class file 11 is a Java file.
The source file a is compiled into a file executable by the post processor 12.

The post-processor 12 is a Java Car
The control flow analysis of the application program for d is performed, and the information file 14 is generated. In addition, a function is added to the class file 11 to add a signature, which is information for proving that the file has passed a valid routine.

Here, the signature is added to the file generated in each step of the runtime verification as proof that the signature has passed a valid routine. If the signature is not entered correctly, it is not installed in the IC card because it has not passed through a valid routine.

The class file 2 (13) is a
This is a file in which the signature is added to the ss file 11.

The run-time checker 16 executes the class file 2 (13) based on the test data 15 for performing runtime verification. At this time, the execution time dependent check items are also checked, and at the same time, the execution time log 17 is generated by referring to the information file 14. here,
The execution-time-dependent check items are check items necessary for the system on the IC card. Therefore, by verifying the contents, types, and the like of the check items, it is possible to eliminate download of a program that does not support the IC card.

The coverage checker 18 executes the execution log 1
7. Check the information file 14 to see if it has passed all the paths of the application program. Further, the coverage checker 18 checks that all the paths have passed, and then checks the class file 2
(13) with signature added to class file 3
(19) is also generated.

The converter 20 converts the class file 3
(19) is converted into a cap file 21 which can be downloaded to an IC card (not shown). Further, it is also determined whether or not the processing has passed through a valid processing routine based on the signature, and only those which have passed through the valid processing routine are converted into the cap file 21.

The loader 22 has a function of downloading the cap file 21 to an IC card (not shown).

With respect to the above configuration, referring to the flowchart of the runtime verification processing operation by the present system shown in FIG. 2,
The operation / action at the time of execution verification will be described.

The post processor 12 analyzes the control flow of the class file 11 (Step S).
201), and generate the information file 14 (step S202). In addition, a signature for certifying that a valid processing routine has been passed is added to the class file 11,
Generate a class file 2 (13).

The runtime checker 16 converts the class file 2 (13) generated by the post processor 12 into
Execute based on test data 15 (step S20)
3). At this time, the runtime dependent check items are also checked, and at the same time, the runtime log 17 is generated by referring to the information file 14 generated in step S202 (step S202).
204).

The coverage checker 18 executes the execution log 1
7. Referring to the information file 14, it is checked whether all the paths of the application program have been passed (step S205).

If it is confirmed that all the data passes (Yes in step S205), the coverage checker 18
Generates a Class file 3 (19) by adding a signature based on the Class file 2 (13) (step S206). If not all passed (No in step S205), the runtime verification check is stopped (step S207).

Next, if the converter 20 has passed a valid processing routine based on the signature of the class file 3 (19), the converter 20 converts the class file 3 (19) into a Cap file 21 (step S208). And
The loader 22 loads the Cap file 21 onto the IC card (Step S209). This completes the runtime verification processing operation.

[0036]

As described above in detail, according to the present invention, E
From an IC card with strict EPROM and memory restrictions
By omitting the execution check routine of the C card application program, the implementation can be reduced.
This makes it possible to increase the application area and the like. Also, by performing various checks outside the execution system, including verification at the time of execution of the application program for the IC card, it is possible to check the consistency with the execution system, and to execute the execution due to inconsistency of the system at the time of execution. Time errors can be prevented. In addition, by checking signatures, unauthorized tampering and those that have not been sufficiently verified at runtime will not be downloaded, and only fully verified applications that do not contain malicious code and can be downloaded can be downloaded. With such an application, it is possible to prevent damage to the IC card, such as destruction or leakage, or to prevent runaway due to downloading of an application with a bug. When the amount of implementation of the runtime verification routine of the system on the IC card changes, the IC
The run-time inspection items performed outside the card also change, but it is guaranteed that only the application that performs the corresponding run-time inspection item can be downloaded. Also, when the implementation of the system on the IC card changes, the run-time inspection items outside the execution system also change, but it is guaranteed that only the application that performs the corresponding run-time inspection item can be downloaded. But also.

Further, according to the present invention, since the IC card program is verified outside the IC card and downloaded after its validity is confirmed, the IC card does not have a check routine. You can get a card.

[Brief description of the drawings]

FIG. 1 is a conceptual diagram of a runtime verification system for an IC card according to an embodiment of the present invention.

FIG. 2 is an exemplary flowchart showing the flow of a runtime processing operation of the runtime verification system for an IC card according to the embodiment;

FIG. 3 is a conceptual diagram of a loader function in a conventional application program.

[Explanation of symbols]

11: Class file, 12: Post processor,
13 Class file 2, 14 Information file, 1
5: test data, 16: runtime checker, 17:
Execution log, 18 ... Coverage checker, 19 ... Clas
s file 3, 20 ... converter, 21 ... Cap file, 22 ... loader.

Claims (3)

[Claims] An IC that verifies that the IC card program operates correctly when the IC card program is executed on the IC card.
In the C-card program execution verification system, the control flow analysis of the IC card program is performed to create an information file, and the source file of the IC card program is compiled into a first class file that is legally processed. Control flow analysis means for generating a second class file to which signature information for proving that the routine has been passed, and a second class file of the control flow analysis means for performing runtime verification with the information file A file execution unit that executes based on the test data and generates an execution log; and, by referring to the execution log of the file execution unit and the information file, whether or not all the paths of the IC card program have been passed. And if all the paths have been passed, the second A runtime verification means for generating a third class file in which signature information is added to the class file; and a valid processing routine based on the signature information of the third class file generated by the runtime verification means. File converting means for converting the third class file into a CAP file which can be downloaded to the IC card;
A program execution verification system for an IC card, comprising: a program loading means for loading a C card. 2. An IC card program execution verification system for verifying that an IC card program operates correctly when the IC card program is executed by the IC card. A file is created, and a second class file in which signature information for proving that the IC card program has undergone a valid processing routine is added to the first class file obtained by compiling the source file of the IC card program. The above-mentioned class file is executed based on the above-mentioned information file and the test data for performing the run-time verification to generate a run-time log.
It is determined whether or not all the paths of the card program have been passed, and a third class file is created by adding signature information to the second class file. Based on the signature information of the third class file, When the program passes through a valid processing routine, the third class file is converted into a CAP file that can be downloaded to the IC card, and the CAP file is loaded onto the IC card. Method of verification. 3. A program for verifying an IC card program outside the IC card, downloading the program to the IC card based on a class file to which signature information indicating that the verification has been correctly performed, and having a check routine in the card. An IC card characterized in that it is not provided.