KR100839296B1 - Recording medium for recording java applet, jar file creating method, recording medium for recording jar file creating program, and jar file creating device - Google Patents

Abstract

A Java applet which executes a plurality of predetermined Java applet programs on a computer, wherein the Java applet is electronically signed to guarantee a source, and the batch information defined for each material of the plurality of predetermined Java applet programs is provided. A false alteration detection step of detecting alteration of the batch information based on the identity confirmation information for detecting alteration, and a load program startup step of starting a load program for loading the plurality of predetermined Java applet programs; When no alteration is detected in the alteration detection step, the computer executes a load step of loading the plurality of predetermined Java applet programs by the loaded load program based on the batch information.

JAR files, applet programs, deployment information, class files, local disks, class loaders, system directories, source code

Description

RECORDING MEDIUM FOR RECORDING JAVA APPLET, JAR FILE CREATING METHOD, RECORDING MEDIUM FOR RECORDING JAR FILE CREATING PROGRAM, AND JAR FILE CREATING DEVICE}

TECHNICAL FIELD The present invention relates to Java applets, and more particularly to techniques for preventing abuse of Java applets.

Conventionally, a technique for executing processing on the client terminal side by executing a Java applet (hereinafter referred to as an applet) downloaded through a telecommunication line or the like using a Java Runtime Environment (JRE) mounted on a web application (Web browser, etc.) on a client terminal. Is provided.

The JRE that runs the applet when performing processing using such an applet prohibits the applet from performing actions that may damage the user for safety reasons.

21 is a conceptual diagram for explaining the normal processing when an applet without an electronic signature is executed. Here, a case where an attacker attempts to illegally access a protected system resource (data or personal information, etc.) 13 on the client terminal C by using an illegal JAR file evil.jar91 is shown. In this example, the JAR file evil.jar91 is not digitally signed.

When the user of the client terminal C accesses the attacker's Web site, the HTML data "evil.html" of the attacker's Web site is downloaded by the Web browser 11 via the Internet N (S71).

The web browser 11 requests the applet starter 12a of the JRE 12 to start the illegal applet based on the tag of the invalid applet included in "evil.html" (S72). The applet starter 12a loads the JAR file evil.jar91 based on the request (S73).

In this case, the illegal JAR file evil.jar91 is considered unreliable because it has not been digitally signed to assure its origin. Therefore, the access request S74 to the protected system resource 13 by the illegal JAR file evil.jar91 (an invalid applet) is prohibited by the security manager 12b (S75).

In this manner, under the access restriction of the security manager 12b, the protected system resource 13 cannot be accessed using an applet whose source is not guaranteed, and the user is not harmed.

By the way, the above-mentioned access restriction may be an obstacle in developing a web application. For example, in an electronic government system or the like, it may be necessary for a user to electronically sign an application or the like using information stored in a local device in the client terminal C. As described above, however, access to the local device on the client terminal side using the applet is normally prohibited, and the system as described above cannot be realized.

Thus, for applets whose source is guaranteed by an electronic signature or the like, a structure is provided in which the user can specifically allow the applet to perform operations (file access, command execution, etc.) that are normally prohibited. As a method of assuring a source, a method of electronically signing an applet as described above is common.

According to this structure, when an applet with a digital signature (hereinafter referred to as "signed applet") is loaded by the IRE 12, a dialog is displayed dynamically requesting the release of the security restriction when the applet is executed, and the user is displayed. There is an advantage that it is possible to prompt the user to choose whether or not to allow the release, thereby reducing the trouble of having the user change the security settings in advance.

Fig. 22 is a conceptual diagram for explaining processing when a signed applet is executed. This example shows the case where foo.jar93 and bar.jar92 are arranged with the HTML file "goodj.html" as a signed applet. Hereinafter, in the figure, what is enclosed by the frame of a double line shall mean that the signature is given.

When the user of the client terminal C accesses "goodj.html" on the Web site, the HTML file "goodj.html" is downloaded by the Web browser 11 via the Internet N (S81).

The web browser 11 requests the applet start-up unit 12a of the JRE 12 to start the applet based on the tag of the applet included in "goodj.html" (S82). The applet base 12a loads JAR files bar.jar92 and foo.jar93 based on the request (S83).

In this case, since the JAR files bar.jar92 and foo.jar93 to be loaded are all digitally signed to guarantee the source, the applet launcher 12a verifies the contents of the signature, and verifies the verification result to the user. A dialog for confirming is displayed (S84). When the user confirms the verification result by the dialog and judges that there is no problem, the security files 12. JAR files bar.jar92 and foo.jar93 are considered to be reliable.

For applets that are considered to be reliable, the applet is allowed to operate normally prohibited. Therefore, even under the access restriction by the security manager 12b, when an access request for the system resource 13 protected by these considered applets is issued (S85), the access request is permitted ( S86).

However, while the structure for granting access to the signed applet as described above is useful, there is a problem that an attacker may reuse the signed applet and use the function to damage the user.

Signed applets are made up of reusable parts, such as signed JAR files. Thus, an attacker may combine their signed JAR files with the attacker's own parts (an illegal JAR file) to call methods of classes contained in the signed JAR file or to modify fields, thereby creating the signatures of those who created those signed JAR files. One can attempt to use something other than its original intention for a fraudulent purpose (so-called fraudulent reconstruction attack).

FIG. 23 is a diagram for explaining an example of the illegal reconstruction attack as described above. Here, an attacker obtains the electronically signed JAR file foo.jar93, illegally reconstructs the electronically signed JAR file and the illegal JAR file evil.jar91 that he created, and places it together with the HTML file "evil2.html". The case is shown.

When the user of the client terminal C accesses "evil2.html" on the Web site, the HTML file "evil2.html" is downloaded by the Web browser 11 via the Internet N (S91).

The web browser 11 requests the applet start-up unit 12a of the JRE 12 to start the applet based on the tag of the applet included in "evil2.html" (S92). The applet starter 12a loads the JAR files evil.jar91 and foo.jar93 based on the request (S93).

Here, the JAR file foo.jar93 to be loaded has an electronic signature for assuring the source, so the applet launcher 12a verifies the contents of the signature and displays a dialog for confirming the verification result to the user. (S94). When the user confirms the verification result by the dialog and judges that there is no problem, the security manager 12b considers the JAR file foo.jar93 to be reliable. On the other hand, the unsigned JAR file evil.jar91 is considered unreliable.

However, as described above, for the JAR file foo.jar93 considered to be reliable, the applet can be normally prohibited. At this time, there is a fear that evil.jar91 issues an access request to the protected system resource 13 using foo.jar93 (S95), and accesses the protected system resource 13 via foo.jar93. There is (S96).

The illegal reconstruction as described above includes the use of "privileged code", a structure for providing a trusted program with its own functions to an untrusted program, a package that executes main logic, and a main logic. The program that distinguishes the utility packages to be used successively can be attacked by replacing only the classes of the utility packages to freely control the operation of the main logic, or by illegally replacing the resources included in the target program. There is a risk of giving.

In addition, once these signed JAR files are leaked, it is difficult to prevent the spread of damage. Allowing this kind of attack in an e-government system or the like may shake the foundation of the administrative system, and therefore, the establishment of a countermeasure against such an attack is urgently required.

<Start of invention>

Problems to be Solved by the Invention

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems, and an object thereof is to simply and reliably prevent an electronically signed Java applet from being illegally reused.

Means for solving the problem

MEANS TO SOLVE THE PROBLEM In order to solve the above-mentioned subject, the Java applet which concerns on this invention is a Java applet which runs a predetermined | prescribed Java applet program on a computer, The said Java applet was the electronic signature for ensuring the origin, A false alteration detecting step of detecting an alteration of the batch information on the basis of identification information for detecting false alteration of batch information defined for each of the predetermined Java applet programs; and the plurality of predetermined Java applet programs The load program startup step of starting the load program for loading the program, and when the alteration is not detected in the alteration detection step, the plurality of predetermined programs are executed by the loaded load program based on the batch information. A configuration that runs a load step on a computer that loads a Java applet program. It is.

In this way, the configuration is such that a plurality of predetermined Java applet programs are loaded based on the batch information confirmed that they have not been modified based on the identity confirmation information, thereby changing the Java applets to be different from the intention of the creator of the Java applets. You can prevent other Java applet programs from loading. In other words, it is possible to simply and reliably prevent an electronically signed Java applet from being illegally reused.

In the Java applet having the above-described configuration, it is preferable that the identity confirmation information includes a hash value of the batch information or a part or all of the data of the batch information.

In the Java applet having the above-described configuration, the identity confirmation information includes a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. The alteration detection step may be configured to detect alteration of each of the plurality of predetermined Java applet programs based on the identity confirmation information.

According to this configuration, after confirming that the batch information and the plurality of predetermined Java applet programs are not modified based on the information for identifying the identity, the plurality of predetermined Java applet programs can be loaded by the batch information. The Java applet and a plurality of predetermined Java applet programs can be modified to prevent the loading of other Java applet programs that differ from the intent of the author of the Java applet.

Further, in the Java applet having the above-described configuration, when a method call request using Java script is made for the main class in the Java applet, the method call processing based on the call request is executed. It is desirable to have a delegation step that delegates to a method corresponding to the called method in a Java applet program.

According to this structure, even when there are no predetermined Java applet programs in the list of applets in operation held by the JRE, a method call processing based on a method call request using Java script, for example, by using a wrapper method or the like. Can be performed for a plurality of predetermined Java applet programs.

In addition, in the Java applet having the above-described configuration, the applet stub set for the Java applet is configured to have an applet stub setting step for setting a plurality of predetermined Java applet programs loaded in the loading step. You may.

In this way, by setting the applet stub to the plurality of loaded Java applet programs, the plurality of predetermined Java applet programs can operate normally.

In order to solve the above-mentioned problem, the JAR file generation method which concerns on this invention is a JAR file generation method which a computer performs the process which produces a JAR file containing a Java applet which runs a some predetermined Java applet program on a computer. An identification checking information generating step of generating, by the computer, identification checking information for detecting alteration of the batch information based on batch information defined for each of the plurality of predetermined Java applet programs; A JAR file including the batch information and the information for identifying the same, based on the batch information and the information for identifying the identity, wherein a JAR file is defined in which the information for identifying the identity is defined as a class file in a predetermined package. Characterizing the JAR file generation step.

Thus, by defining the identity identification information for detecting alteration of batch information as a class file in a predetermined package, when the JAR file is digitally signed, the "same-package-same-signer" By the structure, an incorrect alteration of the identity confirmation information can be prevented.

Moreover, in the JAR file generation method of the above-mentioned structure, it is preferable that the said identity confirmation information contains the hash value of the said batch information, or part or all of the data of the said batch information.

In the JAR file generating method having the above-described configuration, the JAR file generating step includes the batch information, the identity checking information, and the plurality of predetermined Java applet programs based on the batch information and the identity checking information. A JAR file containing a load program for loading a program and a startup program for starting the load program, wherein the identity confirmation information, the load program, and the startup program are defined as class files in the same package. It can also be configured to generate a JAR file.

As described above, the JAR file generated in the JAR file generation step includes a load program for loading a plurality of predetermined Java applet programs and a startup program for starting the load program. Even if a program for realizing a function for loading a plurality of predetermined Java applet programs is not previously installed in the terminal to be downloaded, a plurality of predetermined Java applet programs can be safely loaded by simply downloading this JAR file.

Further, in the JAR file generation method having the above-described configuration, the JAR file generation step includes the plurality of predetermined Java applet programs based on the plurality of predetermined Java applet programs, the batch information, and the identity confirmation information. It is preferable to generate a JAR file including the arrangement information and the identity confirmation information, in which the identity confirmation information is defined as a class file in a predetermined package.

In this way, the plurality of predetermined Javas are downloaded from the terminal downloading the JAR file by including the plurality of predetermined Java applet programs, the batch information, and the identity checking information in the JAR file generated in the JAR file generating step. Even if you do not load the applet program from the outside, you can safely load multiple predetermined Java applet programs simply by downloading this JAR file.

In the method for generating a JAR file having the above-described configuration, the identity confirmation information includes a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. You can make it a configuration.

In addition, in the JAR file generation method having the above-described configuration, the JAR file generation step includes the plurality of predetermined Java applets based on the plurality of predetermined Java applet programs, the batch information, and the information for identifying the same. A JAR file containing a program, the batch information, the identity verification information, a load program for loading the plurality of predetermined Java applet programs, and a startup program for starting the load program. It is preferable to generate a JAR file in which the information, the load program, and the startup program are defined as class files in the same package.

With such a configuration, it is possible to easily and reliably prevent the electronically signed Java applet from being illegally reused without making any changes to the JRE that loads and executes the JAR file.

Moreover, the JAR file generation program which concerns on this invention is a JAR file generation program which makes a computer perform the process which produces | generates the JAR file containing a Java applet which runs a some predetermined Java applet program on a computer, The said several predetermined An identity verification information generating step of generating identity verification information for detecting alteration of the batch information based on the batch information defined for each material of the Java applet program of the Java applet program, and the batch information and the identity verification information. Based on the above information, the JAR file comprising the batch information and the identity confirmation information, wherein the computer executes a JAR file generation step of generating a JAR file in which the identity confirmation information is defined as a class file in a predetermined package. It features.

In the JAR file generation program having the above-described configuration, the identity confirmation information preferably includes a hash value of the batch information or a part or all of the data of the batch information.

In the JAR file generating program having the above-described configuration, the JAR file generating step includes the batch information, the identity checking information, and the plurality of predetermined Java applet programs based on the batch information and the identity checking information. A JAR file comprising a load program for loading a program and a startup program for starting the load program, wherein the identity confirmation information, the load program, and the startup program are class files in the same package. It can also be configured to generate a defined JAR file.

In the JAR file generating program having the above-described configuration, the JAR file generating step includes the plurality of predetermined Java applet programs based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information. As a JAR file containing the batch information and the identity confirmation information, it is preferable to generate a JAR file in which the identity confirmation information is defined as a class file in a predetermined package.

Further, in the JAR file generation program having the above-described configuration, the identity confirmation information may include a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. It is preferable to include.

Further, in the JAR file generation program having the above-described configuration, the JAR file generation step includes the plurality of predetermined Java applet programs based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information. And a JAR file including the batch information, the identity checking information, a load program for loading the plurality of predetermined Java applet programs, and a startup program for starting the load program. The load program and the startup program may be configured to generate a JAR file defined as a class file in the same package.

In addition, the JAR file generating apparatus according to the present invention is a JAR file generating apparatus for generating a JAR file including a Java applet for executing a plurality of predetermined Java applet programs on a computer, each of the plurality of predetermined Java applet programs. An identity verification information generation unit that generates identity verification information based on the batch information defined for the subject matter of the subject; and the batch information and identity verification information on the basis of the batch information and the identity verification information. A JAR file, characterized by comprising a JAR file generation unit for generating a JAR file in which the identity verification information is defined as a class file in a predetermined package.

In the JAR file generating apparatus having the above-described configuration, the identification confirmation information preferably includes a hash value of the batch information or a part or all of the data of the batch information.

Further, in the JAR file generating apparatus having the above-described configuration, the JAR file generating unit is configured to perform the batch information, the identity checking information, and the plurality of predetermined Java applet programs based on the batch information and the identity checking information. JAR file containing a load program for loading and a startup program for starting the load program, wherein the sameness checking information, the load program, and the startup program are defined as class files in the same package. It can be configured to generate a file.

Further, in the JAR file generation apparatus having the above-described configuration, the JAR file generation unit may include the plurality of predetermined Java applet programs based on the plurality of predetermined Java applet programs, the batch information, and the identification information. As a JAR file containing the batch information and the identity verification information, it is preferable to generate a JAR file in which the identity verification information is defined as a class file in a predetermined package.

In addition, in the JAR file generating apparatus having the above-described configuration, the identity checking information may be a part or all of a hash value of each of the plurality of predetermined Java applet programs or data of each of the plurality of predetermined Java applet programs. It may be configured to include.

In the JAR file generating apparatus having the above-described configuration, the JAR file generating unit includes the plurality of predetermined Java applet programs and the arrangement based on the plurality of predetermined Java applet programs, the arrangement information, and the information for identifying the same. A JAR file comprising information, identity identification information, a load program for loading the plurality of predetermined Java applet programs, and a startup program for starting the load program, wherein the identity check information and load program And a startup program are preferably created as JAR files defined as class files in the same package.

In addition, the above-described Java applet and JAR file generating program can be executed in a computer by storing in a recording medium readable by the computer. In addition, the computer-readable recording medium may be a portable storage medium such as a CD-ROM, a flexible disk, a DVD disk, a magneto-optical disk, or a semiconductor storage device such as an IC card, a ROM mounted on a computer, a RAM, or a magnetic recording. It also includes a fixed storage device such as a device, a database holding a computer program, another computer and its database, and a transmission medium on a line.

In this way, by executing the JAR file generation program on the computer, the steps in the above-described JAR file generation method are realized.

1 is a conceptual diagram for explaining prevention of illegal use of an electronically signed applet in this embodiment.

FIG. 2 is a diagram showing an example of a specific configuration for preventing the illegal use of the electronically signed applet shown in FIG. 1; FIG.

FIG. 3 is a diagram for explaining details of an internal configuration of a special format JAR file 2. FIG.

4 is a diagram for explaining a special applet program 24. FIG.

FIG. 5 is a diagram showing that the special format JAR file 2 having the configuration shown in FIG. 4 is digitally signed. FIG.

6 is a diagram illustrating a configuration example of a JAR file T;

FIG. 7 is a diagram illustrating a configuration of a JAR file (descriptor.jar) D. FIG.

8 shows details of a deployment descriptor (cozilet.properties).

Fig. 9 is a source code of CoziletData.java incorporating a hash value as information for checking identity.

Fig. 10 is a source code of CoziletData.java incorporating the deployment descriptor itself as the identity confirmation information.

Fig. 11 is a flowchart from when the special applet is started until the replacement with the target applet is completed.

12 is a diagram for explaining a configuration in which a JAR file (target.jar) T is not included in a special format JAR file.

Fig. 13 is a view for explaining a configuration in which a part of an applet or the like is downloaded from outside of client terminal C, and the other part is placed in advance in client terminal C;

Fig. 14 is a diagram showing details of the configuration of the special format JAR file 202;

Fig. 15 is a diagram of a special format JAR file 203 in which CoziletData.class (24c) and JAR file (descriptor.jar) D are used as identification information.

Fig. 16 is a diagram showing an example of source code of a Cozilet class (corresponding to a startup program) in which a wrapper method is added.

Fig. 17 is a diagram showing an example of source code of a Cozilet class that implements serialization invalidation.

Fig. 18 is a diagram for explaining a JAR file generation device for generating a special format JAR file.

Fig. 19 is a flowchart for explaining a flow of processing in a JAR file generation device.

20 is a diagram for explaining a configuration in which other applets or the like are placed in advance in the client terminal C;

Fig. 21 is a conceptual diagram for explaining normal processing when an applet without an electronic signature is executed.

Fig. 22 is a conceptual diagram for explaining processing when a signed applet is executed.

23 is a diagram for explaining an example of an illegal reconstruction attack.

<Best Mode for Carrying Out the Invention>

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

In the past, when an electronically signed JAR file and an illegal JAR file are incorrectly reconstructed by the JRE on a client terminal, the JRE cannot detect that these JAR files are illegally reconstructed and the signed applet cannot be detected. Processes that are allowed only to access (such as access to protected system resources) were sometimes executed illegally. Therefore, it is necessary to make the applet run only in a regular configuration (a configuration according to the intention of the applet's creator). Hereinafter, a plurality of predetermined Java applet programs having a regular configuration to be loaded in accordance with the intention of the applet creator as described above are called target applet programs.

1 is a conceptual diagram for explaining prevention of illegal use of an electronically signed applet in this embodiment. In addition, in FIG. 1, the same code | symbol is attached | subjected about the part same as what was already shown in FIG. 23, and description is abbreviate | omitted.

In this embodiment, the JRE 12 has a function 12c for executing the applet program only in a regular configuration. Thereby, even when an illegally reconfigured JAR file (for example, a reconfigured file of foo.jar93 as a signed JAR file and evil.jar91 as an illegal JAR file) is loaded from the JRE 12 (S11), the applet program is executed. The function 12c for executing only in the regular configuration prevents the exploitation of the processing permitted for the signed applet (S12).

Moreover, as a main structural example for making the JRE 12 in client terminal C also have the function 12c for running an applet program only in a regular structure, (1) Applet etc. for implementing the said function 12c (Applet and the data associated with it) are downloaded from the outside of the client terminal C, and started from the JRE 12, and (2) some of the applet programs for realizing the above functions 12c are external to the client terminal C. (3) Only the data to be placed outside of the client terminal C is externally placed among the configuration of downloading from the terminal and placing the rest in the inside of the client terminal C in advance, and (3) an applet program for realizing the function 12c. Outside applet programs can be exemplified by three configurations that are prearranged in the client terminal C. FIG.

First, (1) A client program (such as an applet program and data related thereto) for realizing a function 12c for executing the applet program only in a regular configuration to the JRE 12 in the client terminal C. The configuration which is downloaded from the outside of the terminal C and started by the JRE 12 will be described.

FIG. 2 is a diagram showing an example of a specific configuration for preventing the illegal use of the electronically signed applet shown in FIG. 1. In addition, in FIG. 2, the same code | symbol is attached | subjected about the same part already shown in FIG. 23, and description is abbreviate | omitted.

In the configuration shown in Fig. 2, by using a special format JAR file 2 which is digitally signed and whose internal configuration is special, the illegal use of the function of the electronically signed applet is prevented. Specifically, the special format JAR file 2 is defined for each of bar.jar 21 and foo.jar 22 as target applet programs, and the material of each target applet program (a plurality of predetermined Java applet programs). The batch descriptor 23 (equivalent to the batch information) 23 and the special applet program 24 are included. These bar.jar (21) to special applet program 24 are not electronically signed individually, and the entire JAR file containing these bar.jar (21) to special applet program (24) is electronic. Signature is done. In addition, the client terminal C is the same structure as the conventional client terminal shown in FIG.

When the special format JAR file 2 is loaded into the JRE 12 in the client terminal C, the special applet program 24 included in the loaded special format JAR file 2 is executed by the applet starter 12a. Then, the special applet 12d is started.

The special applet 12d (equivalent to the startup program) launched in this way is configured to load the applet based on the deployment descriptor 23 loaded in the JRE 12 in the form contained in the special format JAR file 2. It has a special applet start-up part 12e (corresponding to a load program) having a function of loading only in a regular configuration.

By such a configuration, the JRE 12 has a function for executing an applet program only in a regular configuration, thereby preventing the electronically signed applet from being illegally reused.

The details of the internal structure of the special format JAR file 2 for realizing the functions described above in the JRE 12 will be described below. As shown in Fig. 3, in this embodiment, the special format JAR file 2 is configured to include a special applet program 24, a JAR file (target.jar) T, and a JAR file (descriptor.jar) D. have.

First, the special applet program 24 will be described (see FIG. 4). The special applet program 24 is based on Cozilet.class (corresponding to the startup program) 24a, the deployment descriptor, which is a class file of the main class of the special applet program 24 having a function to be replaced with the target applet at the time of execution. CoziletClassLoader.class (corresponding to load program) 24b and CoziletData.class (corresponding to identity verification information) 24c, which are class files of a special class loader having a function of loading a program of a target applet. . In addition, since these class files all belong to the same package com.aaa.labs.sec.cozilet, an electronic signature on the entire special type JAR file 2 causes the attacker to replace these class file groups illegally. This is prevented by the structure of the same-package-same-signer. FIG. 5 is a diagram showing that the special format JAR file 2 having the configuration shown in FIG. 4 is digitally signed.

Subsequently, the JAR file (target.jar) T included in the special format JAR file 2 will be described. 6 shows an example of the configuration of the JAR file T. In FIG. Specifically, the target applet refers to a class file group or a resource file group required for executing the target applet, and a JAR file group for storing them. In FIG. 6, JAR file T contains JAR file group target1.jar and target2.jar which are target applet programs. In this case, the JAR file (target.jar) T is an unsigned JAR file. The target applet program included in the JAR file (target.jar) T is loaded only by the special class loader (program for loading) at the time of execution of the special applet program 24, and is not loaded by the standard class loader of the JRE. Therefore, the target applet program can be prevented from being exploited by an attacker.

Next, the JAR file (descriptor.jar) D included in the special format JAR file 2 will be described. 7 shows the configuration of a JAR file (descriptor.jar) D. In FIG. Here, the JAR file (descriptor.jar) D contains the Java standard property file cozilet.properties (23) (see Fig. 3). Here, the deployment descriptor cozilet.properties (23) corresponds to the deployment information of the target applet program. JAR file D is an unsigned JAR file. In addition, the JAR file D (corresponding to the layout information) is always included in the special format JAR file 2.

The details of the deployment descriptor (cozilet.properties) 23 are shown in FIG. The main_class property is the name of the target applet's main class. Special applets execute the target applet program based on the properties. The class_path property is a list of URLs in the target applet that are not included in the special format JAR file. In the example of FIG. 8, the URL of outer1.jar disposed on the trusted site and the path of outer2.jar preinstalled on the user's local disk are described. The special class loader loads the target applet program based on the property. In order to prevent exploitation by attackers, it is recommended that these URLs be located somewhere other than where the JRE can be loaded by default (such as extension directories).

The library_path property is a list of paths in the target applet program where the native library group necessary to execute native methods is placed. Since the native library must be installed on the local disk, the property specifies the path on the local disk, not the URL. Special class loaders load native library families based on properties. In order to prevent exploitation by attackers, these paths should be in places other than where the JRE can be loaded by default (such as the system directory).

The trusted_url property is a list of trusted site URLs where HTML documents containing special applets will be placed. Immediately after execution, the special applet obtains the URL where the embedded HTML document is placed and compares it with the URL contained in the property to determine whether the embedded applet is embedded by the HTML document placed on the trusted site. Can be checked

The exclusive_mode property is a flag that determines whether to enable the ability to prevent untrusted applets from running during special applets. If the value of the property is ON, the special applet enables the above functionality. On the other hand, if the property value is off, this function is disabled.

Next, CoziletData.class 24c included in the special applet program 24 will be described. CoziletData.class 24c is a class file containing information for identifying the identity for detecting alteration of a target applet program or deployment descriptor. Fig. 9 shows source code CoziletData.java of class CoziletData incorporating SHA1 hash value H of the target applet program or batch descriptor as the constant field as the information for identifying the identity. By compiling this source code, CoziletData.class (24c) can be generated.

The CoziletData class contains three constant fields: inner_hash, outer_hash, and descriptor_hash. inner_hash contains the SHA1 hash value of target.jar T. outer_hash contains the SHA1 hash value of the entire target applet program located at the URL specified by the class_path property. descriptor_hash contains SHA1 hash value of descriptor.jar D. The CoziletData class belongs to the same package com.aaa.labs.sec.cozilet as the class file group, which is another special applet program, and by signing a special format JAR file electronically, the same-package-same-signer structure Unauthorized substitution by an attacker can be prevented.

By the way, since target.jar T and descriptor.jar D included in the special format JAR file are resource files instead of class files, there is a possibility that an attacker may replace them illegally. Therefore, when the special class loader loads these resource files, it compares the SHA1 hash value of the loaded resource with the SHA1 hash value H contained in the constant field of the CoziletData class to detect whether or not the resource file has been modified. can do.

In the above-described example, the CoziletData.class 24c is configured to include the SHA1 hash value H of the target.jar T and the descriptor.jar D. However, the present invention is not limited thereto, but the target.jar T and descriptor. The configuration may include a constant field that includes some or all of the data of jar D. 10 shows an example of the source code of CoziletData.class 24c including the constant field descriptor_value including descriptor.jar D itself. In this case, the special format JAR file 2 does not need to include descriptor.jar D, and the value of descriptor.jar D can be extracted from the constant field descriptor_value when the special applet program 24 is executed.

Subsequently, the operation in the case where the above-mentioned special applet program 24 is executed by the JRE will be described using the flowchart of FIG.

First, the special format JAR file 2 according to the present embodiment is disposed on a server, for example, and loaded by the JRE through a web browser or the like, whereby the special applet program 24 is executed by the JRE.

Typically, a plurality of predetermined Java applet programs are, for example,

<applet code = "jp.example.SomeApplet"

      archive = "target1.jar, target2.jar"

     width = "400" height = "400"> </ applet>

It is invoked by an HTML document that contains an applet tag such as

On the other hand, when a plurality of predetermined Java applet programs are started by JRE using the special format JAR file 2 in this embodiment,

<applet code = "com.aaa.labs.sec.cozilet.Cozilet"

      archive = "cozilet.jar"

      width = "400" height = "400"> </ applet>

With an HTML document containing an applet tag such as this, a special applet is placed in place of the target applet to start it (S21), and the target applet program can be started.

Subsequently, the Cozilet class 24a is loaded by the JRE and an instance is created (S22). The Cozilet class retrieves the cozilet.properties (23) contained in the special format JAR file (2) in the static initializer. When alteration prevention by CoziletData.class (24c) is performed, it is checked whether or not cozilet.properties (23) has been altered (false detection step) (S23), and when altered (S24, present). The execution is forcibly terminated (S29). If not modified (S24, none), create a java.util.Properties instance from cozilet.properties (23). Hereinafter, this instance is called a cozilet deployment descriptor. Thus, the alteration of batch information is detected based on the identity confirmation information for detecting the alteration of batch information defined for each of a plurality of predetermined Java applet programs.

Next, referring to the value of the exclusive_mode property from the cozilet deployment descriptor, if ON, the function of preventing the execution of untrusted applets during the execution of the special applet program 24 is enabled (S25). This feature takes advantage of class loading and class definition restrictions in the Java virtual machine included in the JRE. The class loading restriction function can prevent an untrusted program from being loaded for classes included in a package group starting with a string specified in the security property "package.access". In addition, the class definition restriction function can prohibit an untrusted program from defining a new class for a package group that starts with a string specified in the security property "package.definition". Thus, by setting values such as "java.", "Javax.", "Com.", And "org" to these properties, untrusted programs need to run the classes (for example, the java.applet.Applet class). Because it can't be loaded, it can't run as a result.

Next, the JRE calls init () of the Cozilet class (S26). In the init () method, the Cozilet class checks whether the URL of the site where the HTML document of its built-in source is placed is trusted by comparing it with the list of URLs included in the value of the trusted_url property of the cozilet deployment descriptor. S27). The URL of the site where the built-in HTML document is placed can be obtained by getDocumentBase () of the java.applet.Applet class. It is sufficient here that this URL matches any one of each URL contained in the trusted_url property. Moreover, it can also be set as the structure which compares URL by forward matching. If it does not match any URL included in the trusted_url property (S27, it cannot), execution is forcibly terminated (S29).

If there is no problem with the above-described check (S27), the Cozilet class 24a creates an instance of the CoziletClassLoader class 24b as a loading program for loading a plurality of predetermined Java applet programs (for loading). Program start step) (S28). The CoziletClassLoader class (24b) is a target applet that exists in the constructor in the target.jar T included in the special format JAR file (2), the URL specified in the class_path property of the cozilet deployment descriptor, and the path specified in the library_path property of the cozilet deployment descriptor. Make the program loadable. If tampering is prevented by CoziletData.class 24c, the completeness of the target applet program is verified (S2a), and if tampering is detected (S2b), execution is forcibly terminated (S29).

Upon successful creation of an instance of the CoziletClassLoader class 24b, the Cozilet class 24a takes the name of the target applet's main class, which can be obtained from the main_class property of the cozilet deployment descriptor, into loadClass () of the CoziletClassLoader class 24b. By passing in as a call, you get a class instance of the target applet's main class (load step). That is, when no alteration is detected in the alteration detection step, a plurality of predetermined Java applet programs are loaded into the loading program based on the placement information. Then, the constructor of the class instance is called by the Java reflection structure to obtain an instance of the main class of the target applet (S2c).

Some processing of applets is delegated to applet stubs (such as calling getDocumentBase ()). Applet stubs are initially set in special applets. The Cozilet class sets its applet stub by calling setStub () of the target applet (S2d). Applet stubs are required to run the target applet normally. The applet stub is stored as a private field of the java.applet.Applet class, and the Cozilet class 24a does not have access to that field. Here, in the Java virtual machine, if the parent panel of a special applet in which an instance of the Cozilet class is registered has the function of applet stub, it is easy to obtain an instance of the parent panel from the Cozilet class, so that instance is used as an applet stub. It is set in the target applet (S2d).

Applets are registered in the parent panel so that they can be displayed on a browser or handle GUI events. Since a special applet is initially registered in the mother panel, the Cozilet class 24a deletes its own instance registered in the mother panel, and instead registers an instance of the main class of the special applet program 24 (S2e). . As a result, the GUI event sent from the JRE is notified to the target applet, but to the special applet 24, so that the target applet can operate normally as an applet.

The Cozilet class 24a calls init () of the main glass of the target applet (S2f). After this, the target applet operates as an applet instead of the special applet, and the applet replacement is completed (S2g).

In this way, the configuration is such that a plurality of predetermined Java applet programs are loaded based on the batch information which has been confirmed not to be modified based on the identity confirmation information. Thus, the Java applet is modified to be different from the intention of the creator of the Java applet. You can prevent different Java applet programs from loading. In other words, it is possible to simply and reliably prevent an electronically signed Java applet from being illegally reused.

In addition, public methods of special applets can be exploited by an attacker. At the beginning of each method, the caller is examined by stack inspection. Specifically, at the beginning of each method, you call checkPermission () in the java.security.AccessController class, passing an instance of the java.security.AllPermission class as an argument. This prevents classes that do not have the permission AllPermission, that is, the class of the attacker, from calling the public methods of the special applet described above. The permission passed to checkPermission () may not necessarily be AllPermission, but may be sufficient to prevent an attacker from calling it.

The above-described special format JAR file 2 includes Cozilet.class 24a as a startup program, CoziletClassLoader.class 24b as a load program, CoziletData.class 24c as identity information, and JAR file ( target.jar) T and JAR file (descriptor.jar) D, but it is configured (see Fig. 3), but not limited to this, for example, target.jar T must be a special type JAR file (2) It does not need to be included in. Also, as in the special format JAR file 201 shown in FIG. 12, when the JAR file (target.jar) T is configured to not be included in the special format JAR file, the JAR file (target.jar) T is stored in the JRE. It needs to be placed in the place which can be loaded by.

In addition, as described above, (2) a part of the applet or the like which implements the function 12c for executing the applet only in a regular configuration is downloaded from outside the client terminal C, and the rest is downloaded into the client terminal C. It can also be set as the structure arrange | positioned previously (refer FIG. 13). In FIG. 13, the special format JAR file 202 shows a configuration including CoziletData.class 24c, a JAR file (target.jar) T, and a JAR file (descriptor.jar) D as information for identifying identity. . When using the special format JAR file 202 of the structure shown in FIG. 13, Cozilet.class 24a as a starting program and CoziletClassLoader.class 24b as a loading program store the client terminal provided with JRE. It is preferably stored in the area beforehand. 14 is a diagram showing details of the configuration of the special format JAR file 202.

The special format JAR file 203 can also be configured to include CoziletData.class 24c and JAR file (descriptor.jar) D as the information for identifying the identity (see FIG. 15). In this case, Cozilet.class 24a as a startup program and CoziletClassLoader.class 24b as a loading program are stored in advance in a storage area of a client terminal having a JRE, and a JAR file (target.jar) T is a JRE. It must be arranged in the place which can be loaded by.

As described above, the special format JAR file in the present embodiment can be divided into various formats as shown in FIGS. 3, 12, 13, and 15, but the special format JAR file of any of the above-described formats Also, as a result, all of the divided components are loaded into the JRE, and are common in that each step shown in FIG. 11 is executed.

As described above, since the GUI event is normally notified by registering the target applet in the parent panel instead of the special applet, the method of the target applet related to the GUI is normally executed by the JRE. However, for target applet methods other than GUI-related, the target applet is not registered in the list of applets in the JRE's internally maintained operation, so it is not normally executed by the JRE and the special applet method is still executed. Will be. Thus, for these methods, each method in the special applet delegates method calls from the JRE to the above method in the target applet.

Specifically, you add a set of wrapper methods that have the same signature as the method signature group entered as target applet placement information to the special applet's main class, and the wrapper method group handles method calls to itself in the target applet's main class. It is configured to delegate to methods with the same signature.

FIG. 16 shows an example of source code of a Cozilet class (corresponding to a startup program) in which a wrapper method is added. By compiling this source code, you can create Cozilet.class with wrapper methods added. In the example of FIG. 16, a wrapper method having a signature such as the method signature doSomething (java.lang.String) input as the deployment information is added, and the method of the main class of the target applet having the same signature in the wrapper method is Java. Called using the reflection structure of.

When an applet's method is called from JavaScript, the request is sent to the JRE. The JRE maintains a list of applets in action, and invokes the applet's methods based on this list. However, applet lists cannot be manipulated by special applets. Thus, by adding the wrapper method of the method to the main class of the special applet contained in the special format JAR file described above, when the wrapper method is called, the script code can call the target applet's method via the wrapper method. You can do that.

In addition, the special applet in this embodiment is implemented so that its serialization is invalid. If serialization of the special applet is enabled, an attacker can steal or alter the value of the special applet's security-critical private fields using an interface that serializes or restores from serialization. Since the java.applet.Applet class is implemented to be serializable, the Cozilet class that inherits it is also serializable. Therefore, Cozilet.class (24a) invalidates its serialization by implementing forcibly throwing an exception in the method related to serialization. Fig. 17 shows an example of the source code of the Cozilet class in which the serialization is disabled.

Next, the JAR file generation apparatus 5 for generating the special format JAR file (FIGS. 3, 12, 13, and 15) of the structure mentioned above using FIG. 18 is demonstrated. This apparatus has a function of generating a JAR file containing a Java applet for executing a plurality of predetermined Java applet programs on a computer, and converts the target applet program into a special format JAR file by inputting the target applet program and batch information. (Encapsulation of the target applet program).

The JAR file generation device 5 according to the present embodiment includes an information confirmation unit 51 for confirmation of identity, a JAR file generation unit 52, a storage unit 53, a CPU 54, and a special applet generation unit 55. It is configured as having a configuration.

The identity confirmation information generation unit 51 generates the identity verification information for detecting the alteration of the batch information based on the batch information defined for each of the target applet programs (a plurality of predetermined Java applet programs). Has a role to play.

The JAR file generation unit 52, based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information, the plurality of predetermined Java applet programs, the batch information, the identity checking information, and the plurality of predetermined Java applets. JAR file containing a load program for loading a program and a startup program for starting a load program, wherein the information for identity confirmation, the load program, and the startup program are defined as class files in the same package. Create a file. In addition, the JAR file generation unit 52 has a function of digitally signing the generated JAR file.

The special applet generation unit 55 has a role of generating Cozilet.class 24a as a startup program and CoziletClassLoader.class 24b as a load program.

The storage unit (recordable medium that can be read by a computer) 53 is composed of a storage area such as RAM or ROM, and stores a program executed in the JAR file generating device 5, various applets, and the like. Have The CPU (computer) 54 has a role of executing a program stored in the storage unit 53 in order to perform various processes in the JAR file generation device 5.

FIG. 19 is a flowchart for explaining the flow of processing (the JAR file generating method) in the JAR file generating apparatus 5 as described above. Here, the case where the special format JAR file of the data format shown in FIG. 3 is produced | generated is demonstrated.

First, in the JAR file generating apparatus 5, as input data, layout information (storage) defined for the target applet programs (here, bar.jar (21) and foo.jar (22)) and the location of the target applet program Location, URL, etc.) (S61).

Next, the identity confirmation information generation unit 51 generates a JAR file (descriptor.jar) D as identity verification information for detecting alteration of the batch information based on the acquired batch information (identity check). Information generation step) (S62). Specifically, the identity confirmation information generation unit 51 is a JAR file including hash values of batch information or part or all of the data of batch information as the identity check information, hash values of target applet programs, or target applets. It is possible to create a JAR file containing some or all of the data of each program, a hash value of both the batch information and the target applet program, or a JAR file containing some or all of the respective data.

Subsequently, the JAR file generation unit 52 checks the target applet program, the batch information, and the identity on the basis of the target applet programs (bar.jar (21) and foo.jar (22)), the batch information, and the identity checking information. Creates a JAR file that contains the application information, the load program to load the target applet program, and the startup program to start the load program. At this time, the identity confirmation information, the load program, and the startup program are defined as class files in the same package in the generated JAR file (JAR file generation step) (S63). Thus, by defining the identity identification information for detecting alteration of batch information as a class file in a predetermined package, when the JAR file is digitally signed, the "same-package-same-signer" By the structure, an incorrect alteration of the identity confirmation information can be prevented. The JAR file to be generated includes a load program for loading a plurality of predetermined Java applet programs and a startup program for starting the load program, thereby allowing a plurality of terminals to download the JAR file. It is possible to safely load a plurality of predetermined Java applet programs simply by downloading this JAR file without having to install a program that realizes a function for loading a given Java applet program in advance. In other words, it is possible to simply and reliably prevent an electronically signed Java applet from being illegally reused without making any changes to the JRE that loads and executes the JAR file.

The JAR file generated as described above is digitally signed by the JAR file generation unit 52 and output as necessary (S64).

Each step in the above-described JAR file generation method is realized by executing the JAR file generation program stored in the storage unit 53 on the CPU 54.

By the steps as described above, a special format JAR file as shown in FIG. 3 including a class file group, a target applet program, and deployment information, which are special applet programs, can be generated.

In addition, the JAR file generation unit 52 selects a class file group (loading program, startup program, etc.), which are special applet programs to be included in the special format JAR file, from among the data previously stored in the storage unit 53. Can be. Of course, the special applet generated by the special applet generation unit 55 may be generated to be a class file group included in the special format JAR file.

The JAR file generation unit 52 can also generate the target applet program without including the target applet program in the special format JAR file, like the special format JAR file 201 shown in FIG. 12. In this case, the JAR file generation unit 52 starts up the batch information, the identity verification information, the load program for loading the target applet program, and the load program for starting the load, based on the batch information and the identity verification information. Create a JAR file containing your application. At this time, the JAR file generation unit 52 defines the identity confirmation information, the load program and the startup program as class files in the same package.

In addition, like the special format JAR file 202 of the data format shown in FIG. 13, the JAR file generation unit 52 does not include special applet programs (loading program, startup program, etc.) in the special format JAR file. It can also be created without. In this case, the JAR file generation unit 52 generates a JAR file containing the target applet program, the batch information, and the identity checking information, based on the target applet program, the batch information, and the identity checking information. At this time, the JAR file generation unit 52 defines the information for identifying the identity as a class file in a predetermined package.

In addition, the JAR file generation unit 52 stores the target applet program and the special applet program (loading program, startup program, etc.) in a special format, like the special format JAR file 203 of the data format shown in FIG. 15. You can also create them without including them in the JAR file. In this case, the JAR file generation unit 52 generates a JAR file containing the batch information and the information for identifying the same, based on the batch information and the information for identifying the identity. At this time, the JAR file generation unit 52 defines the information for identifying the identity as a class file in a predetermined package.

In addition to the above-described configuration, (3) among the applets and the like which realize the function 12c for executing the applet only in the regular configuration, only the data to be placed outside the client terminal C is placed outside, and the other applets and the like. May be arranged in advance in the client terminal C (FIG. 20). In FIG. 20, the applet program etc. which were arrange | positioned previously in the client terminal C are started, and the special applet start part 12a 'which has a role as a load program and a start program is shown.

As described above, according to the present invention, it is possible to easily and reliably prevent an electronically signed Java applet from being illegally reused.

Claims (23)

A computer-readable recording medium having recorded thereon a Java applet for executing a plurality of predetermined Java applet programs on a computer, The Java applet has been electronically signed to ensure its origin, An alteration detection step of detecting alteration of the arrangement information on the basis of identification information for detecting alteration of arrangement information defined for each of the plurality of predetermined Java applet programs; A load program starting step of starting a load program for loading the plurality of predetermined Java applet programs; A load step of loading the plurality of predetermined Java applet programs by the loaded load program based on the batch information when no alteration is detected in the alteration detection step; A computer-readable recording medium having recorded thereon a Java applet for executing a program on a computer. The method of claim 1, And the identification information includes a hash value of the batch information or a part or all of the data of the batch information. The method of claim 1, The identity confirmation information includes a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs, The alteration detection step is a computer-readable recording medium having recorded thereon a Java applet for detecting alteration of each of the plurality of predetermined Java applet programs based on the identity confirmation information. The method of claim 1, When a method call request using Java script is made for the main class in the Java applet, the method call processing based on the call request is the method corresponding to the called method in the plurality of predetermined Java applet programs. A computer-readable recording medium having recorded thereon a Java applet having a delegation step. The method of claim 1, A computer-readable recording medium having recorded thereon an applet stub setting step of setting an applet stub set for the Java applet for a plurality of predetermined Java applet programs loaded in the loading step. A method of generating a JAR file in which a computer performs a process of generating a JAR file containing a Java applet for executing a plurality of predetermined Java applet programs on a computer, The computer, An identity verification information generation step of generating identity verification information for detecting alteration of the batch information based on batch information defined for each of the plurality of predetermined Java applet programs; A JAR file including the batch information and the information for identifying the identity, based on the batch information and the information for identifying the identity, wherein a JAR for generating a JAR file in which the information for identifying the identity is defined as a class file in a predetermined package; File Generation Steps JAR file generation method characterized in that for executing. The method of claim 6, The identity checking information includes a hash value of the batch information or a part or all of data of the batch information. The method of claim 6, The JAR file generating step starts the batch information, the identity verification information, a load program for loading the plurality of predetermined Java applet programs, and the load program based on the batch information and the identity verification information. A JAR file containing a startup program for causing a JAR file to be generated, wherein the identification information, the load program, and the startup program are defined as class files in the same package. The method of claim 6, The JAR file generating step includes a JAR file including the plurality of predetermined Java applet programs, the batch information, and the identity checking information, based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information. And a JAR file generation method for generating a JAR file in which said identity confirmation information is defined as a class file in a predetermined package. The method of claim 9, The identity checking information includes a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. The method of claim 6, The JAR file generating step includes the plurality of predetermined Java applet programs, the batch information, the identity checking information, and the plurality of predetermined Java applets based on the plurality of predetermined Java applet programs, the batch information, and the information for identifying the same. A JAR file containing a load program for loading a Java applet program of the program and a startup program for starting the load program, wherein the identification information, the load program, and the startup program are class files in the same package. A JAR file generation method that generates a JAR file that is defined as. A computer-readable recording medium having recorded thereon a JAR file generating program for causing a computer to execute a process for generating a JAR file containing a Java applet for executing a plurality of predetermined Java applet programs on a computer, An identity verification information generation step of generating identity verification information for detecting alteration of the batch information based on batch information defined for each of the plurality of predetermined Java applet programs; A JAR file including the batch information and the information for identifying the identity, based on the batch information and the information for identifying the identity, wherein a JAR for generating a JAR file in which the information for identifying the identity is defined as a class file in a predetermined package; A computer-readable recording medium having a JAR file generating program recorded thereon, wherein the file generating step is executed on a computer. The method of claim 12, And the identity checking information includes a hash value of the batch information or a part or all of the data of the batch information. The method of claim 12, The JAR file generating step starts the batch information, the identity verification information, a load program for loading the plurality of predetermined Java applet programs, and the load program based on the batch information and the identity verification information. A JAR file containing a startup program for causing a computer to read, wherein the identity confirmation information, the load program, and the startup program record a JAR file generation program that generates a JAR file defined as a class file in the same package. Record carrier. The method of claim 12, The JAR file generating step includes a JAR file including the plurality of predetermined Java applet programs, the batch information, and the identity checking information, based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information. And a JAR file generation program for generating a JAR file in which said identity confirmation information is defined as a class file in a predetermined package. The method of claim 15, And the identification checking information includes a JAR file generating program including a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. The method of claim 12, The JAR file generating step includes the plurality of predetermined Java applet programs, the batch information, the identity checking information, and the plurality of predetermined Java applets based on the plurality of predetermined Java applet programs, the batch information, and the information for identifying the same. A JAR file containing a load program for loading a Java applet program of the program and a startup program for starting the load program, wherein the identification information, the load program, and the startup program are class files in the same package. A computer-readable recording medium having recorded thereon a JAR file generating program which generates a JAR file which is defined as. A JAR file generating device for generating a JAR file containing a Java applet for executing a plurality of predetermined Java applet programs on a computer, An identity verification information generation unit for generating identity verification information based on layout information defined for each of the plurality of predetermined Java applet programs; A JAR file including the batch information and the information for identifying the identity, based on the batch information and the information for identifying the identity, wherein a JAR for generating a JAR file in which the information for identifying the identity is defined as a class file in a predetermined package; JAR file generation device comprising a file generation unit. The method of claim 18, The identity checking information includes a hash value of the batch information or a part or all of data of the batch information. The method of claim 18, The JAR file generation unit activates the batch information, the identity verification information, a load program for loading the plurality of predetermined Java applet programs, and the load program based on the batch information and the identity verification information. A JAR file containing a startup program for generating a JAR file, wherein the identification information, the load program, and the startup program are defined as a class file in the same package. The method of claim 18, The JAR file generation unit is a JAR file including the plurality of predetermined Java applet programs, the batch information, and the identity checking information, based on the plurality of predetermined Java applet programs, the batch information, and the identity checking information. And a JAR file generating device for generating a JAR file in which said identity confirmation information is defined as a class file in a predetermined package. The method of claim 21, And the identity checking information includes a hash value of each of the plurality of predetermined Java applet programs or a part or all of data of each of the plurality of predetermined Java applet programs. The method of claim 18, The JAR file generation unit includes the plurality of predetermined Java applet programs, the batch information, the identity checking information, and the plurality of predetermined Java applets based on the plurality of predetermined Java applet programs, the batch information, and the information for identifying the same. A JAR file comprising a load program for loading a Java applet program and a startup program for starting the load program, wherein the identity confirmation information, the load program, and the startup program are class files in the same package. JAR file generator that generates a defined JAR file.

Images