WO2000042498A1

WO2000042498A1 - Method and system for executing mobile code

Info

Publication number: WO2000042498A1
Application number: PCT/JP1999/000084
Authority: WO
Inventors: Tadashi Kaji; Seiichi Susaki; Takashi Akaosugi
Original assignee: Hitachi, Ltd.
Priority date: 1999-01-13
Filing date: 1999-01-13
Publication date: 2000-07-20
Also published as: AU1889699A; JP3873624B2

Abstract

Means for deciding whether to execute a mobile code depending on the functions of the mobile code. When a mobile-code receiving section at a user terminal receives data including a mobile code from a distributor server, a signature attached to the mobile code is checked. When the signature is successfully verified, a function confirmation section confirms the specification that describes the functions of the mobile code. If the function confirmation section decides to permit the execution of the mobile code, a mobile code execution means executes the mobile code.

Description

Description Mobile Code Execution Method and System

Technical field

The present invention relates to the background art relating to the security of mobile code that is downloaded from a server to a user terminal via a network and automatically executed.

Mobile code has been widely used as a means to greatly enhance the expressive power and convenience of the World Wide Web (WWW). The Mobino record is placed on a ring server and is downloaded automatically when the user accesses the page using the user program <Browser program. The program is called.

However, on the other hand, mopile code that performs unauthorized processing, such as accessing resources (files, peripheral devices, etc.) on one user's terminal without permission and stealing information or causing failures, has become a problem. They are coming. For this reason, some systems that use mobile code have the following security functions for the execution of mobile code.

(1) Mobile code is basically not allowed to access resources on one user terminal.

(2) Mopile code can communicate only with the server where the mopile code was stored.

These security features are considered to protect the system from unauthorized mobile code. However, on the other hand, it is clear that such regulations undermine the convenience of mobile code. Therefore, the mobile code is a so-called signed code to which the signature of the creator of the mobile code (a digital signature called a digital signature) is added, and the creator of the code is The function has been extended so that if the user using the terminal recognizes that the mobile code is trusted by the user, the restriction on the mobile code is not applied. For example, Japanese Patent Laying-Open No. 10-83310 discloses an example of a system using such a signed code. The digital signature technology is described in, for example, “SECURE ELEC-TRON IC COMMERCEj (PRENT ICE HALL, 1997) pp. 111-116.

When the signed code for accessing the local file is downloaded from the server via the network, the processing procedure at the relevant user terminal will be briefly described with reference to Fig. 19 as follows. It seems.

When a user using a user terminal downloads a signed code from the server using the Browser program (step 1901), the user first verifies the digital signature attached to the signed code. The mobile code is checked for integrity (not falsified) (step 1902). If the integrity is verified, then the signer of the signature is checked to see if it is a signer already authorized to access the oral file (step 1903), and access is granted. If it is the signed signer, the signed code accesses the oral file and executes the previously programmed processing (step 1905).

Also, in step 1903, if the signer is not authorized, the user using the user terminal is permitted to access the signed code created by the signer to the oral code. Give Is selected (step 1904). If permission is granted, the signed code accesses the local file and performs the pre-programmed processing (step 1905).

If the integrity cannot be confirmed in step 1902, and if access permission is not given in step 1904, the user using the user terminal is notified to that effect (step 1906), and the processing is performed. Exit.

The security function of the signed code described above determines whether or not the signer of the mopile code allows the execution of the mobile code, and what kind of function the mobile code has I do not know until I try it. Therefore, the user cannot obtain sufficient information on whether or not to execute the mopile code until the user tries to execute the mopile code. Then, if the user decides to trust the signer, there is a problem that even if the signed code is a mobile code that performs illegal processing, it will be executed.

Japanese Patent Laying-Open No. 10-83310 discloses a method of distributing a list of resources (ACL) requested by the code together with the code, and assigning resources according to the ACL at the time of execution. By distributing the ACL with the code, you can know which resources the code will access before you run it, but how it uses it, that is, I do not know if it has such a function.

The present invention has been made in view of the above circumstances, and an object of the present invention is to determine whether to execute a mobile code based on a function of the mobile code. Mobile code configuration and execution method of the mobile code, a mobile code system using the mobile code, a source code creation terminal, a function verification server, a mobile code An object of the present invention is to provide a file distribution server, a user terminal, and a program for realizing them. Disclosure of the invention

In order to achieve the above object, the mobile code according to the present invention is characterized in that a function specification describing a function of the mobile code or an identifier corresponding to the function specification is attached. .

Further, the method for executing a mopile code according to the present invention is characterized in that before executing the mobile code, a step of checking a function of the mobile code and determining whether or not to execute the function is provided.

That is, in the mobile code execution method of the present invention, a mopile code is acquired, and an electronic signature attached to the mobile code acquired by the mopile code acquisition step is provided. A signature verification step, and, if the signature of the mobile code is successfully verified (the verification result is passed) in the signature verification step, describes a function of the mobile code. A function specification acquisition step of acquiring the specified function specification, and a function of the mopile code is confirmed based on the function specification acquired in the function specification acquisition step, and it is determined whether to execute the mobile code. In the function checking step and the function checking step, it is determined that the mobile code is permitted to be executed. A mobile code execution step for executing the mopile code in the event that the mobile phone is disconnected.

Further, the mopile code system of the present invention includes a source code creation terminal for creating a source code of a mobile code, a function verification server for verifying the function of the source code, and a mobile code for distributing the mobile code. A mobile server consisting of a distribution server and a user terminal that executes mobile code O Record system,

The source code creation terminal includes: a source code creation unit that creates a source code of a mobile code; and a source code transmission unit that sends the source code of the mobile code to the function verification server. The function verification server creates a function specification describing the function of the mobile code from the transmitted source code of the mobile code, and verifies whether the mobile code does not perform an illegal process. Function verification means; mobile code creation means for creating the mobile code from the source code when the function verification means determines that the mobile code does not perform an illegal process; A registration requesting the distribution server to register the mobile code created by the mobile code creation method described above. Recording request means, and

The mobile code distribution server includes: a mobile code storage unit that stores and stores the mobile code requested to be registered; and a mobile code storage unit that is requested to deliver from the user terminal. Mobile code transmission means for transmitting the stored mobile code to the user terminal.

The user terminal includes: a delivery request transmission unit for requesting delivery of the mobile code to the mobile code distribution server; and a signature verification unit for verifying an electronic signature attached to the delivered mobile code. Means, and if the signature verification means succeeds in verifying the signature, the function specification created by the function inspection means of the verification server is obtained, and the function of the mobile code is confirmed by the function specification. And a function checking means for determining whether to permit execution of the mobile code, and executing the mohair code when the function checking means determines that the execution of the mobile code is permitted. Mobile code execution means. Further, in the mobile code system according to the present invention, the function confirmation means may include: a function specification same as the function specification is registered in a function specification management file stored in one user terminal; The specifications are presented to the user, and if the user decides to permit the execution of the mobile code having the function, it decides to permit the execution of the corresponding mobile code. Therefore, in the present invention, the user-terminal that has downloaded the mopile code performs a process of confirming the function specification describing the functions of the mopile code before executing the mopile code. The mobile code is executed only when the function specification is permitted to be executed in advance, or when the user determines that the execution of the mobile code having the function specification is permitted. I have to.

Therefore, according to the present invention, it is possible to determine whether or not to execute the mobile code based on the function of the mobile code. The present invention is not limited to the mobile code, but can be applied to a case where a general program code such as stored in a storage device of one user terminal is executed. BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram showing a device schematic configuration and a hardware configuration of a mobile code distribution system to which an embodiment of the present invention is applied, and FIG. 2 is a diagram to which an embodiment of the present invention is applied. FIG. 3 is a diagram showing a functional block configuration of a creation terminal and a verification server related to a mobile code function verification request process in a system according to the present invention. FIG. 3 shows a system to which an embodiment of the present invention is applied. FIG. 4 is a diagram showing a functional block configuration of a verification server and a distribution server related to a mobile code function verification process and a registration process in FIG. 4. FIG. 4 is a system to which an embodiment of the present invention is applied. In, Mobi FIG. 5 is a diagram showing a functional block configuration of a distribution server and a user terminal related to a record execution process, and FIG. 5 is a diagram showing an example of functional specifications created by a verification server in FIG. FIG. 6 is an example of a functional specification confirmation screen displayed by the verification server to the verifier in FIG. 3, and FIG. 7 is a diagram in FIG. FIG. 8 is an example of an execution confirmation screen displayed by the user—terminal to the user in FIG. 4, and FIG. 9 is an example of a function specification editing screen displayed in FIG. FIG. 4 is a diagram for explaining an example of information stored in a functional specification management file shown in FIG. 4. FIG. 10 shows a mobile code function verification request in a system to which an embodiment of the present invention is applied. Creation end related to processing FIG. 11 is a flow chart for explaining the operation of the mobile server. FIG. 11 illustrates the operation of the verification server related to the function verification request processing of the mobile code in the system to which the embodiment of the present invention is applied. FIG. 12 is a flowchart for explaining the operation of a verification server related to a mobile code function verification process in a system to which an embodiment of the present invention is applied. FIG. 13 is a flowchart for explaining the operation of the distribution server related to the registration of the mobile code in the system to which one embodiment of the present invention is applied. FIG. 15 is a flowchart for explaining the operation of the distribution server related to the execution of the mobile code in the system to which one embodiment of the present invention is applied; and FIG. 15 is a diagram to which one embodiment of the present invention is applied. FIG. 16 is a flowchart for explaining the operation of the user terminal related to the execution of the mobile code in the system according to the embodiment of the present invention. FIG. 17 is a diagram showing a functional block configuration of a verification server, a distribution server, and a user terminal related to the execution of a mobile terminal. FIG. 17 shows a mobile core in a system to which another embodiment of the present invention is applied. One user terminal involved in the execution of FIG. 18 is a flow chart for explaining the operation of the verification server. FIG. 18 is a flow chart for explaining the operation of the verification server in the system to which another embodiment of the present invention is applied. FIG. 19 is a flowchart for explaining a security function in a conventional mobile code, and FIG. 20 is an execution diagram in which a user terminal displays to a user in FIG. It is an example of a confirmation screen. BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the present invention is not limited to this.

FIG. 1 is a diagram showing a device schematic configuration and a hardware configuration of a mobile code system to which an embodiment of the present invention is applied.

As shown in FIG. 1, the system according to the present embodiment verifies the functions of a source code creation terminal 110 (hereinafter, also simply referred to as creation terminal 110) for creating a source code of a mopile code, and a function of the source code. A function verification server 120 (hereinafter, also simply referred to as “verification server 120”) that creates a mopile code from the source code, and a mobile code distribution server 130 (hereinafter, simply a distribution server) that registers and distributes the mopile code. And a user terminal 140 that executes a mopile code are respectively configured on a computer, and are connected to each other via a communication network 100 such as a LAN.

In FIG. 1, a plurality of creating terminals 110, verification servers 120, distribution servers 130, or user terminals 140 may be connected.

As shown in FIG. 1, the computer that constitutes the creation terminal 110, the verification server 120, the distribution server 130, and the user terminal U0 includes a communication network interface, a display device, an input device, and a storage device. And the central processing unit ifi (CPU), Temporary storage devices (memory) are connected to each other by a bus. The communication network interfaces 111, 121, 131, and 141 are interface devices for transmitting and receiving data via the communication network 100. The display devices 112, 122, 132, and 142 are used to display messages and the like to users who use the above terminals and servers, and include a CRT, a liquid crystal display, and the like. The input devices 113, 123, 133, and 143 are used by the user to input data, instructions, and the like, and include a keyboard and a mouse. The storage devices 114, 124, 134, 144 are used to permanently store various information such as program data, and are constituted by a hard disk, a floppy disk, and the like.

The CPUs 115, 125, 135, and 145 control the respective units in an integrated manner and perform various arithmetic processing. The memories 116, 126, 136, and 146 store operating systems (hereinafter, also simply referred to as OS) 116a, 126a, 136a, and 146a, and programs and data necessary for the CPU to realize the functions of the terminals and servers. Is stored.

Here, 0S116a is a program for implementing functions such as file management, process management, or device management in order to control the entire user terminal 110.

The code creation program 116b creates a source code (hereinafter, also simply referred to as a source code) of the mopile code 146c in accordance with an instruction of a user of the creation terminal 110 (hereinafter, also simply referred to as 1 '). This is a program for storing in the storage device 114. The verification request program 116c is a program for transmitting the source code stored in the storage device 114 to the verification server 120 according to the instruction of the creator.

The code verification program 126b receives the source code from the creation terminal 110, verifies the function of the source code, and, based on the source code, This is a program for creating the pile code 146c and its functional specifications and registering them in the distribution server 130.

When receiving the mobile code U6c from the verification server 120, the code distribution program 136b stores the mobile code 146c in the storage device 134, and also allows access from the user terminal 140 by the browser program 146b. This is a program for transmitting the mobile code 146c stored in the storage device 134 with the multimedia data and the like attached thereto as necessary.

In addition, the browser program 146b communicates with the distribution server 130 when the user terminal 140 communicates with the distribution data, that is, the mobile data 146c and various data attached as needed (for example, multimedia data such as audio, images, and moving images). This is a program to download data consisting of HTML files including HTML data, confirm the functions of the mobile code 146c, and execute the mobile code 146c. Note that these attached various data are required when the browser program 146b executes the mobile code 146c.

The mobile code 146c is a program that accesses various resources of the user terminal 140 and performs calculation processing.

In the present embodiment, in addition to the execution code of the mobile code 146c, the function specification of the mopile code 146c and the signature of the verifier (in this embodiment, necessary for verifying the signature) Data and files used by the mobile code itself, and checks the integrity of the mobile code 146c itself (confirms whether it has been tampered with). ) And function confirmation.

Next, a functional block configuration and operation of each program in the present embodiment will be described. In the following description, each functional block This is realized by the CPU executing a program via the OS or directly.

However, when the creator creates the source code on the creating terminal 110, the functional block configuration and operation are the same as when the source code is created in the conventional mobile code system. The detailed description of is omitted. The source code created by the creator is stored in the source code file 202 of the storage device 114.

First, the functional block configuration and operation of the creating terminal 110 and the verification server 120 when the creating terminal 110 requests the verification server 120 to perform the function verification of the mobile code 146c are shown in FIG. This will be described with reference to FIGS. 10 and 11.

FIG. 2 is a diagram showing a functional block configuration of the creation terminal 110 and the verification server 120 when the creation terminal 110 requests the verification server 120 for function verification of the mopile code 146c. First, the functional block configuration of the creation terminal 110 will be described.

As shown in FIG. 2, the creation terminal 110 includes an input unit 204 that receives an instruction from the creator via an input device 113, and a display device and the like that are input to the input unit 204. In accordance with the creator's instruction input to the input device 113, the display 203 displayed on the display device 112 and the verification code 120 are transmitted via the communication network 100 to the source codestore of the storage device 114. And a source code transmission processing unit 201 for transmitting data or a file, for example, voice, image, or moving image data, which is used when the source code is executed, stored in the file 202. Note that the data or files used at the time of execution of these are different from the data files attached to the mobile code in the distribution data described above and are required by the mobile code at the time of execution. is there. Next, a function block configuration of the verification server 120 will be described.

As shown in FIG. 2, the verification server 120 displays, on the display device 122, information indicating that the source code has been received from the creation terminal 110, and the like, and displays the source code from the creation terminal 110. And a source code reception processing unit 211 for reception.

Next, the operation of the creation terminal 110 will be described.

FIG. 10 is a diagram illustrating an operation flow of the creation terminal 110 when the creation terminal 110 requests the function verification of the mobile code 146c to the verification server 120.

First, the creator inputs the storage location and name of the source code and the location and name of the verification server 120 into the input device 113 (step 1001). Next, in step 1002, the source code transmission processing unit 201 extracts the specified source code from the source code file 202, and executes the source code and the data used by the source code at the time of execution. A function verification request 203 including a file is created, and the function verification request 203 is transmitted to the verification server 120 specified by the creator.

Next, the operation of the verification server 120 will be described.

FIG. 11 is a diagram showing an operation flow of the verification server 120 when the creation terminal 110 requests the verification server 120 to perform the function verification of the source code.

First, in step 1101, the source code reception processing unit 211 waits for the function verification request 203 from the creating terminal 110. Upon receiving the function certificate request 203, the source code reception processing section 211 stores the source code extracted from the function verification request 203 in the source code file 212 (step 1103), and Information indicating that the source code has been received from the display device 122 (step 1104). After that, the process transits to Step 1101 and again waits for the function verification request 203 from the creating terminal 110.

Next, when the verification server 120 performs the function verification of the source code, creates the mobile code 146c, and registers the mobile code 146c in the distribution server 130, the verification server 120 and the distribution server 130 perform The functional block configuration and operation will be described.

FIG. 3 is a functional block diagram of the verification server 120 and the distribution server 130 when the function of the source code is verified by the verification server 120 and the mobile code 146c created from the source code is registered in the distribution server 130. FIG. 3 is a diagram showing a configuration. Here, each functional block of the verification server 120 is realized by the CPU 125 of the verification server 120 executing each program stored in the memory 126 via the OS. Each functional block of the distribution server 130 is realized by the CPU 135 of the distribution server 130 executing each program stored in the memory 136 via the OS.

First, a functional block configuration of the verification server 120 will be described.

As shown in FIG. 3, the verification server 120 includes an input unit 123 that receives an instruction from a user of the verification server 120 (hereinafter, also simply referred to as a verifier), and data and the like input to the input unit 123. A display device 122 to be displayed; a function verification processing unit 301 for verifying the function of the source code stored in the storage device 124 in accordance with the verifier's instruction input from the input unit 123; A mobile code creation processing unit 302 that creates a mobile code 146c from the code, a registration request transmission processing unit 303 that sends a registration request 305 to the distribution server 130 to request registration of the mobile code 146c, have. The registration request 305 includes information for designating a location for storing the mobile code 146c and the mobile code created by the mobile code generation processing unit 302. Next, the function block configuration of the distribution server 130 will be described.

As shown in FIG. 3, the distribution server 130 displays an input unit 133 for receiving an instruction of a user of the distribution server 130 (hereinafter, also simply referred to as a distributor), and data and the like input to the input unit 133. A registration request reception processing unit 311 that receives the registration request 305 from the verification server 120 and stores the mobile code 146c included in the registration request 305 in the storage device 134. , have.

Next, the operation of the verification server 120 will be described.

FIG. 12 shows an operation flow of the verification server 120 when the function of the source code is verified by the verification server 120 and the mobile code 146c created from the source code is registered in the distribution server 130. FIG.

First, when the verifier inputs a storage location and a name of the source code for verifying a function to the input unit 123 (step 1201), the function verification processing unit 301-specifies the source code specified from the source code file 212. Then, a function specification 500 describing the functions of the mopile code 146c is created from the source code (step 1202). Next, the function specification confirmation screen 600 is displayed on the display device 122 (step 1203), and the process proceeds to step 1204 to wait for the verifier's instruction.

FIG. 5 is a diagram showing an example of the function specification 500 created by the function verification processing unit 301. In this example, the source code reads (501) and writes ('504) a file called “etcZ passwdj”, and executes information (503) that executes a program called “Z bin / rm”. It has been described.

FIG. 6 is an example of the function specification confirmation screen 600 displayed on the display device 122 by the function verification processing unit 301. The verifier compares the source code displayed in the source code display area 601 with a technical specification A comparison is made with the function specification 500 displayed in the display area 602, and the function specification 500 is checked, and whether or not to create the mobile code 146c is selected. For example, the verifier checks the function specification 500 displayed on the display device 122 and determines that the mobile code 146c performs a harmful operation. The creation of the mobile code 146c can be rejected by pressing a cancel (reject) button 604 or the like. The harmful operation is, for example, the operation of running a program unrelated to the original operation or the operation of reading data from one user terminal and transferring it to the server. The creation is to create (compile) the execution code from the source code, and to combine the functional specifications, the execution code, and the data file used at the time of execution into one.

(Archive and), where _c pointing to processes that perform that further adds a signature, if the verifier issues an instruction would leave refuse the creation of the Mobairuko one de 146c, in step 1209, The source code and the function specification 500 are discarded, and the process ends. When the verifier refuses to create the above-described mopile code 146c, the verifier may be notified to the effect that the creation has been rejected, together with the reason. This has the effect that the creator can know the location of the mobile code 146c to be modified.

On the other hand, when the verifier selects the creation of the mobile code 146c by pressing the create button 603 or the like, the process proceeds to step 1205. Also, in step 1204, the verifier can edit the functional specification 500. When the inspector selects the editing of the function specification 500 by pressing the edit button 605, the process proceeds to step 1210, and the function verification processing unit 301 displays the function specification editing screen 700 on the display device. 122 and waits for an instruction from the verifier (step ^ U).

FIG. 7 shows that the function verification processing unit 301 displays the information on the display device S122. It is an example of the screen of the function specification editing screen end 00. The verifier edits the functional specification 500 using this screen.

If the user selects to reflect the edited result to the function specification 500 by pressing the update button 702 or the like, the function verification processing unit 301 newly adds the function specification 500 reflecting the edited result. Create (step 1212) and return to step 1204.

On the other hand, if the user selects not to reflect the edited result in the function specification 500 by pressing the cancel button 03 or the like, the process returns to step 1204 as it is.

In step 1205, a set of the functional specification 500 and a mobile code identifier for identifying the mobile code 146c created by the verification server is stored in a functional specification registration file 304, and the mobile code creation processing unit Move on to 302.

In step 1206, the mopile code creation processing unit 302 creates the execution code and the signature of the verifier, and creates the mobile code 146c.

Next, in Step 1207, when the verifier inputs the name of the distribution server 130 that registers the mobile code 146c and the storage location therein, the registration request transmission processing unit 303 A registration request 305 including 146c and its storage location is created, and the registration request 305 is transmitted to the designated distribution server 130 (step 1208), and the process ends. When the mobile code 146c is registered in the distribution server 130, the creator may be notified to that effect. This has the effect that the creator can know that the mobile code 146c has been successfully created.

Next, the operation of the distribution server '130 will be described.

FIG. 13 shows that the function of the source code is verified by the verification server 120, and the source FIG. 9 is a diagram showing an operation flow of the distribution server 130 when the mobile code 146c created from the code is registered in the distribution server 130.

First, in step 1301, the registration request reception processing unit 311 waits for the registration request 305 from the verification server 120. Upon receiving the registration request 305 (Step 1302), the registration request reception processing unit 311 stores the mobile code 146c included in the registration request 305 in a designated storage location (Step 1303), and performs the verification. Information indicating that the mobile code 146c has been received from the server 120 is displayed on the display unit 132 (step 1304). After that, the processing transits to Step 1301 and waits for the registration request 305 from the verification server 120 again.

Next, when the user terminal 140 receives the distribution data including the mopile code 146c from the distribution server 130 and executes the mobile code 146c, the function block configuration and operation of the user terminal 140 and the distribution server 130 are performed. The work will be described.

FIG. 4 is a diagram showing a functional block configuration of the user terminal 140 and the distribution server 130 when the user terminal 140 receives the above-mentioned distribution data including the mobile code 146c from the distribution server 130. Here, each functional block of the user terminal 140 is realized by the CPU 145 of the user terminal 140 executing each program stored in the memory 146 via the OS. Each functional block of the distribution server 130 is realized by the CPU 135 of the distribution server 130 executing each program stored in the memory 136 via the OS. First, the function block configuration of the user terminal 140 will be described.

As shown in FIG. 4, the user terminal 140 includes an input unit 143 that receives an instruction of a user of the user terminal 140 (hereinafter, also simply referred to as a user), data input to the input unit 143, A display unit 142 for displaying data and the like sent from the distribution server 130, and the queue input to the input unit 143. A request transmission processing unit 411 that transmits a delivery request 417 of the mobile code 146c to the distribution server 130 according to the instruction of the user, and a mobile communication unit that receives the mobile code 146c from the distribution server 130. A mobile phone reception processing unit 412; a signature verification processing unit 413 for verifying a signature added to the mobile code 146c; a function verification processing unit 414 for verifying the function of the mobile code 146c; and the mobile code And a mobile code execution processing unit 415 for executing 146c.

Next, the functional block configuration of the distribution server 130 will be described.

As shown in FIG. 4, the distribution server 130 includes a request reception processing unit 401 that receives the distribution request 417 from the user terminal 140, a card that makes the distribution request 417, and a mobile code 146c. And a mobile code transmission processing unit 402 for transmitting distribution data to the user terminal 140.

Next, the operation of the user terminal 140 will be described.

FIG. 14 is a diagram illustrating an operation flow of the user terminal 140 when the user terminal 140 receives the distribution data including the mobile code 146c from the distribution server 130 and executes the mobile code 146c. is there.

First, download of the mobile code 146c or the like placed on the distribution server 130 is instructed using information indicating the name and storage location of the mobile code 146c (file name / directory name, etc.). (Step 1401), the request transmission processing unit 4111 transmits the distribution request 417 of the mopile code 146c to the distribution server 130 (Step 1402). As the information indicating the name and storage location of the mobile code 146c, for example, when data is received using the Browser program as in the present embodiment, the distribution data indicates the name and storage location of the evening. As information, the so-called Uniform Resource that links the address of the distribution server 130 and the file name

Oca tors C UR s) ^ "for 用る₀ Next, in step 1403, when the mopile code reception processing unit 412 waits for distribution data from the distribution server '130 and receives the mopile code 146c or the like from the distribution server 130, the signature verification processing unit 413 Transfer processing to In step 1404, the signature verification processing unit 413 includes, as the download instruction method for verifying the verifier's signature attached to the mopile code 146c,

(1) The user explicitly specifies the URL

(2) The URL of the mobile code is specified in the HTML file being viewed, and the Browser program 146b automatically issues a download instruction.

There is. Also,

(3) The distribution server 130 may send the mopile code 146c using PUSH technology

At this time, steps 1401 and 1402 are omitted.

Here, if the integrity of the mobile code 146c has not been confirmed (the mobile code 146c has not been tampered with since the verification server 120 created the mobile code 146c), If it is determined that the verifier cannot be trusted, the fact is displayed on the display unit 142 (Step 1412), and the process proceeds to Step 1413 to end the process. Note that the method of determining whether the verifier can be trusted is the same as the method of determining whether or not the signer can be trusted in conventional signed code. Is omitted.

On the other hand, if it is determined in step 1405 that the integrity of the mopile code 146c is confirmed and that the verifier can be trusted, the process is transferred to the function confirmation processing unit 414. The function confirmation processing unit 414 extracts the function specification 500 of the mopile code I46c from the mobile code 146c (step 1406) and records it in the function specification management file 416 of the storage device 144. Then, it is confirmed whether the same functional specification 500 is registered in the table as shown in FIG. 9 (step 1407).

The functional specification management file 416 is registered in the functional specification 500 sequentially each time its execution is permitted, or distributed in advance by a trusted third party or a system administrator. This is a file that stores proven (ie secure) functional specifications. FIG. 9 shows an example in which safe function specifications 500 are sequentially numbered and registered in the function specification management file 416.

If the same function specification 500 is registered in the function specification management file 416, the process proceeds to step 1411 and the process is transferred to the mobile code execution processing unit 415.

On the other hand, if the same function specification 500 has not been registered in the function specification management file 416, in step 1408, an execution confirmation screen 800 is displayed on the display unit 142, and the execution of the mobile code 146c is performed. The user is instructed whether or not to do so.

FIG. 8 is an example of the execution confirmation screen 800. In this example, the mobile code 146c that is about to be executed is read from the file “/ etc / passwd” (811), and the read data is read.

FIG. 20 shows another example of the execution confirmation screen 800, in which information such as (813) to be transferred to a computer called www.foo.co.jp is displayed. In this example, the mobile code 146c that is currently trying to execute is "da etc /

Information such as reading (2011) and writing (2014) to a file called "passwd" and executing (2015) a program called "/ binZrm" is displayed.

In any case, the user confirms the function of the mobile code 146c that is currently about to be executed based on the information displayed on the screen, and Select whether to permit execution of mobile code 146c.

Here, when the user inputs an instruction to execute the mobile code 146c, for example, by pressing an execution button 820, the function confirmation processing unit 414 performs the function specification management. The function specification 500 of the mobile code 146c is newly added to the file 416 (step 1410), and the process proceeds to step 1411, where the process is transferred to the mobile code execution processing unit 415. On the other hand, if the user inputs an instruction not to permit execution of the mobile code 146c from the input unit 142, such as pressing the reject button 830, the process proceeds to step 1413.

In step 1411, the mobile code execution processing unit 414 executes the mobile code 146c. Note that execution of the mopile code 146c in the present embodiment means execution of an execution code included in the mobile code. Next, the operation of the distribution server 130 will be described.

FIG. 15 is a diagram showing an operation flow of the distribution server 130 when the one user terminal 140 receives the distribution data including the mopile code 146c from the distribution server 130 and executes the mobile code 146c.

First, in step 1501, the request reception processing unit 401 waits for a delivery request 417 from the user terminal 140, and upon receiving the delivery request 417 from the user terminal 140, shifts the processing to the mopil code transmission processing unit 402. The mobile code transmission processing unit 402 transmits the mobile code 146c corresponding to the delivery request 417 to the user terminal 140 with a multimedia file or the like attached as necessary (step 1503). . Thereafter, the process returns to step 1501 and waits for the end of the delivery request 41 from the user terminal 140 again.

As described above, in the present embodiment, the waiting function of the mobile code 146c created by the verification server 120 is described in the mopile code 146c. The functional specification 500 described above is included. When the user terminal 140 receives the mobile code 146c from the distribution server 130, the execution of the function specification 500 extracted from the mobile code 146c is permitted before executing the mobile code 146c. Even if it is not the case, it is presented to the user and made to select whether or not to execute the mopil code 146c. Therefore, the user terminal 140 can determine whether or not to execute the mobile code 146c based on the function of the mobile code 146c ₍ Next, as another embodiment of the present invention, An embodiment in which the functional specification 500 is centrally managed by the verification server 120 will be described.

In the present embodiment, in addition to the execution code of the mobile code 146c, the mobile code 146c includes a mobile code identifier for distinguishing the mobile code 146c from the others, and a signature of the verifier (this embodiment). However, all the data required to verify the signature are collectively described as a signature) and the data file used by the mobile code itself is included, and the integrity of the mobile code U6c itself is confirmed. Available to

The device schematic configuration and the hardware configuration of the system in which the functional specification 500 is centrally managed by the verification server 120 are the same as the above-described embodiment in which the mobile code 146c includes the functional specification 500. Detailed explanations are omitted.

Similarly, when the creator creates the source code on the creating terminal 110, the function block configuration and operation of the creating terminal 110 are the same as those of the conventional mobile code system, Detailed description is omitted.

Similarly, when the creating terminal 110 requests the verification server 120 for the function verification of the mopile code 146c, the function block configuration and operation of the creating terminal 110 and the certification server 120 will be described. Is the mobile co This is the same as the embodiment in which the function specification 500 is included in one node i46c, and a detailed description thereof will be omitted.

The function block configuration and operation of the verification server 120 and the distribution server 130 when the function verification of the mobile code 146c is performed by the verification server 120 and registered in the distribution server 130 are as follows. When the mobile code 146c is created in step 1206 in FIG. 12, the mobile code identifier described above is used except that the mobile code identifier created in association with the functional specification 500 is used instead of the functional specification 500. This is the same as the embodiment in which the function specification 500 is included in 146c, and a detailed description thereof will be omitted.

First, in this embodiment, the user server 140 receives the distribution data including the mobile code 146c from the distribution server 130, executes the mobile code 146c, and executes the verification server 120, the user terminal 140, and The function block configuration and operation of the distribution server 130 will be described.

FIG. 16 shows the verification server 120 and the distribution server 130 when the user terminal 140 receives the distribution data including the mobile code 146c from the distribution server 130 and executes the mopile code 146c in the present embodiment. FIG. 3 is a diagram showing a functional block configuration of a user terminal 140.

As shown in FIG. 16, the verification server 120 receives the function specification request 418 from the user terminal 140 and transmits the requested function specification 500 to the user terminal 140. Have.

Note that, in FIG. 16, the functional block configurations of the user terminal 140 and the distribution server 130 are the same as those shown in FIG. 4, and a detailed description thereof will be omitted. However, in the present embodiment, the function confirmation processing unit 414 of the user terminal 140 also performs processing of transmitting a function specification request 418 to the verification server 120 and receiving a function specification 500 from the verification server 120. .

Next, the operation of the user terminal 140 will be described. FIG. 5 is a diagram showing an operation flow of the user-one terminal 140 when the user-one terminal 140 receives the distribution data including the mopile code 146c from the distribution server 130 and executes the mobile code 146c. .

In this figure, steps 1401 to 1405 and steps 1407 to 1412 are the same as those in FIG. 14, and a description thereof will be omitted.

According to the result of the determination in step 1405, the process proceeds to the function confirmation processing unit 414,

The function confirmation processing unit 414 extracts the mobile code identifier from the mopile code 146c, and transmits a function specification request 418 including the mopile code identifier to the distribution server 120 (step 1701). In step 1702, when the function specification 500 corresponding to the mobile code identifier is received from the distribution server 120, the same as the table shown in FIG. 9 previously stored in the function specification management file 416 of the storage device 144. Check whether function specification 500 is registered (step 1407).

The operations in the following steps are the same as those in FIG. Next, the operation of the verification server 120 will be described.

FIG. 18 shows an operation flow of the verification server 120 when the user terminal 140 receives the distribution data including the mopile code 146c from the distribution server 130 and executes the mobile code 146c. FIG.

First, in step 1801, the specification transmission processing unit 1621 waits for the function specification request 418 from the user terminal 140. When the function specification request 418 is received, the mobile code identifier included in the function specification request 418 is extracted (step 1803), and the mobile code identifier corresponding to the mobile code identifier is extracted from the bonus specification registration file 304. The function specification 500 to be searched is searched (step 1804). The function specification 500 is transmitted to the user terminal 140 (step 1805), and the process returns to step 180U. Wait for specification request 418.

The operation of the distribution server 130 is the same as that in the above-described embodiment in which the mobile code 146c includes the functional specification 500, and a detailed description thereof will be omitted.

As described above, in the present embodiment, the verification server 120 creates the function specification 500 and the mobile code identifier for uniquely identifying the mobile code 146c created when verifying the function of the source code. The group is managed. The mobile code 146c includes the mobile code identifier. When the user terminal 140 receives the mobile code 146c from the distribution server 130, first, the mobile code identifier extracted from the mobile code 146c is used. Is transmitted to the verification server 120. Upon receiving the mobile code identifier, the verification server 120 searches for the functional specification 500 corresponding to the mobile code identifier, and returns it to the user terminal 140. The user terminal 140 that has received the function specification 500 presents the function specification 500 to the user if the function specification 500 is not a permitted function specification, and determines whether or not to execute the mopile code 146c. Or let me choose. Therefore, the user terminal 140 can determine whether or not to execute the mobile code 146c based on the function of the mobile code 146c.

In each of the embodiments described above, communication including various “requests” and “requests” performed by each program is performed by a communication technology (eg, “socket”) between well-known programs (or modules and processes). Is known).

The transmission and reception performed by each program are performed via the OS of each computer hardware, the communication network interface, and the communication network.

The display on each display unit E and the input from the input unit a are performed by the programs of the display unit and the input unit via the OS or directly. is there.

Note that the present invention is not limited to the above embodiment, and various modifications can be made within the scope of the gist.

For example, in the above embodiment, the verification server 120 and the distribution server 130 are configured on different computer hardware, but the present invention is not limited to this. That is, the verification server 120 and the distribution server 130 may be configured on the same computer hardware. Similarly, the creation terminal 110 and the verification server 120 may be configured on the same computer hardware. Similarly, the creation terminal 110 and the distribution server 130 may be configured on the same computer hardware. Further, the creation terminal 110, the verification server 120, and the distribution server 130 may be configured on the same computer hardware. In these cases, the programs that realize the functions of each server and terminal are managed as independent programs (processes) by the OS on the same computer hardware, and their operations are managed.

Further, the verification server 120 may transmit the created mopile code 146c to the creating terminal 110, and the creating terminal 110 may register the created molypile code 146c in the distribution server 130. In this way, the creator can select the distribution server 130 for registering the mobile code 146c.

Further, the creation terminal 110 may register the source code in the distribution server 130, and the distribution server 130 may request the verification server 120 to verify the function of the mopile code 146c. In this way, the distributor can request a verifier trusted by himself to perform the function verification.

In the creation terminal 110, the creator may create the function specification 500, and transmit the function specification 500 to the certification server 120 together with the source code. By doing so, the verifier can confirm that the functional specification 500 does not operate illegally and that the source code is By confirming that the mobile code 146c is implemented as per the performance specification 500 and that the mobile code 146c does not perform an illegal operation, it can be guaranteed. The function of creating the functional specification 500 in the verifier server 120 becomes unnecessary.

Before the verifier checks the function, the features of the function specification 500 of the mobile code 146c that performs the illegal processing may be put into a list and stored in the storage device 124 of the verification server 120. . Then, by confirming whether the functional specification 500 created from the source code to be verified has the features corresponding to the list, the mobile code 146c is processed illegally. A process for confirming whether or not to perform may be incorporated. By doing so, the mobile code 146c corresponding to the above list using the known fraudulent processing method can save the verifier's trouble of performing function verification, thereby improving the efficiency.

Further, the creation terminal 110 may transmit the execution code and the function specification of the mobile code 146c to the verification server 120. In this case, Step 1202 is unnecessary in FIG. Also, the “source code designation” and “execution code designation” of step 1201 are changed to the “source code discard” force “execution code discard” of step 1209. Further, the function of compiling the execution code from the source code in step 1206 can be eliminated.

Also, in the above embodiment, the confidentiality of information exchanged between the creating terminal 110, the verification server 120, the distribution server 130, and the user terminal 140 via the communication network 100, Although no special means is used to ensure integrity, the present invention does not prevent the use of various encryption means and authentication means. By applying encryption means and authentication means to the information flowing through the communication network 100, the security of the entire system can be further improved. You.

Further, in the above embodiment, it is assumed that the mopile code 146c permitted to execute by the user can use any resources of the user terminal 110, such as freely starting other programs. ing. However, for example, when the mopil code 146c requests various services from another program, the Browser program 146b or the OS 146a passes the function specification 500 to the other program, and the function specification 500 The program passed may determine whether or not to execute the request from the mobile code 146c based on the function specification 500.

In the above embodiment, the data exchange between the creation terminal 110 and the verification server 120 is performed via the communication network 100, but the present invention is not limited to this. The source code created by the creating terminal 110 may be recorded on a storage medium such as a floppy disk and delivered to the verifier. Similarly, when exchanging data between the verification server 120 and the distribution server 130, the mobile code 146c may be recorded on a storage medium and passed to the distributor. Industrial applicability

As described above, according to the present invention, whether or not to execute the mobile code can be determined based on the function of the mobile code, so that the present invention is more secure.

Claims

The scope of the claims

1.

A mobile code execution method,

Obtaining a mobile code; a mobile code obtaining step; verifying a signature attached to the obtained mobile code; a signature verification step;

A function specification obtaining step of obtaining a function specification describing a function of the mobile code when the signature of the mobile code is successfully verified by the signature verification step;

A function confirmation step of confirming a function of the mobile code based on the acquired function specification, and determining whether to permit execution of the mopile code;

A mobile code execution step for executing the mobile code when the execution of the mobile code is permitted by the function confirmation step;

How to execute a mobile code with 2.

A method for executing a mobile code according to claim 1, wherein

In the function checking step, the function specification is presented to a user, and if the user determines that the execution of the mobile code having the function specification is permitted, the execution of the mobile code is permitted. To judge

A mobile code execution method characterized by the following.

3. 3. The method for executing a mobile code according to claim 1, wherein the function checking step is performed when the function specification is registered in a function specification management file storing function specifications permitted to be executed. Determining that the execution of the mobile code is permitted.

A mobile code execution method characterized by the following.

Four .

A method for executing a mobile code according to claim 3, wherein

The function check step is to add the function specification to the function specification management file when it is determined that the execution of the mobile code is permitted.

A mobile code execution method characterized by the following. α.

A method for executing a mobile code according to any one of claims 1 to 4, wherein

The mobile code includes an execution code of the mobile code, the signature, and the functional specification,

The function specification obtaining step further includes a step of retrieving the function specification from the mobile code.

A mobile code execution method characterized by the following.

6.

The mopile code includes an execution code of the mobile code and the signature Name and a mobile code identifier that identifies the mobile code,

The function specification obtaining step includes obtaining a function specification corresponding to the mobile code identifier from a function specification registration file.

A method for executing a mopile code.

7.

A method for executing a mobile code according to claim 6, wherein:

The functional specification registration file is a file that is stored by a trusted third party as a set of the mobile code identifier and the functional specification corresponding to the mobile code identifier,

The function specification obtaining step includes obtaining a function specification corresponding to the mobile code identifier from the trusted third party.

A mobile code execution method characterized by the following.

8.

A method for executing a mobile code according to any one of claims 5 to 7, wherein

The functional specification is created by a trusted third party, and the signature is a signature of the trusted third party.

A mobile code execution method characterized by the following.

9.

A mobile code source code, a source code, a terminal, and a function verification server that verifies the functions of the source code, a function verification server, a mopile code distribution server, and a mopile code distribution server. Execute, A mobile code system comprising: a user terminal; and the source code creation terminal,

Source code creation means for creating a source code of a mobile code; source code sending means for sending the source code of the mobile code to the function verification server;

With

The function verification server,

Function verification means for creating a function specification describing the function of the mobile code from the transmitted source code of the mobile code, and verifying whether the mobile code performs an illegal process;

Mobile code creation means for creating the mobile code from the source code when the function verification means determines that the mobile code does not perform an illegal process;

Registration requesting means for requesting the distribution server to register the mopile code created by the mobile code creating means;

With

The mobile code distribution server comprises:

Mobile code storage means for storing and storing the mobile code requested for registration,

Mobile code transmission means for transmitting, to the user terminal, the mobile code stored in the mobile code storage unit requested to be delivered from the user terminal,

With

The one user terminal,

Delivery request transmitting means for requesting the mobile code distribution server to deliver a mopile code; Signature verification means for verifying an electronic signature attached to the delivered mobile code;

When the signature verification unit succeeds in verifying the signature, the function specification created by the function verification unit of the verification server is obtained, the function of the mobile code is confirmed by the function specification, and the mobile code is checked. Function checking means for determining whether or not execution of the code is permitted;

A mobile code system comprising: a mobile code execution unit that executes the mobile code when the function checking unit determines that the execution of the mobile code is permitted.

Ten .

The mobile code system according to claim 9, wherein:

The function confirmation means presents the function specification to a user, and when the user determines that the execution of the mobile code having the function specification is permitted, the user confirms that the execution of the mobile code is permitted. To judge

Mobile code system characterized by the following.

1 1.

10. The mobile code system according to claim 9 or 10, wherein the function confirmation unit is configured to store the function specification permitted to be executed and to register the function specification in advance in a function specification management file. Means for determining that execution of the mobile code is permitted

Mobile code system characterized by:

1 2

[; 冃 The mobile code system described in claim 11 The function checking means includes means for adding the function specification to the function specification management file when it is determined that the execution of the mobile code is permitted.

Mobile code system characterized by the following.

13 .

The mobile code system according to any one of claims 9 to 12, wherein

The function checking means includes means for acquiring the function specifications from the mobile code.

Mobile code system characterized by the following. 14 .

The mobile code system according to any one of claims 9 to 12, wherein

The mobile code includes an execution code of the mobile code, the signature, and a mopile code identifier for identifying the mopile code,

The function confirmation means includes means for acquiring a function specification corresponding to the mobile code identifier from a function specification registration file.

Mobile code system characterized by the following. 1 5.

15. The mobile code system according to claim 14, wherein: The means for acquiring the function specification includes means for transmitting the Mopile code identifier to the function verification server,

The function verification server,

Function specification storage means for storing a set of a mobile code identifier and the function specification corresponding to the mobile code identifier as the function specification registration file;

Means for searching the function specification registration file for a function specification corresponding to the mobile code identifier received from the user terminal;

Function specification transmitting means for transmitting the searched function specification to the user terminal.

Mobile code system characterized by the following. 1 6.

The mopile code system according to any one of claims 13 to 15,

The signature is generated and added by the function verification server.

Mobile code system characterized by the following.