WO2007011001A1 - 実行装置 - Google Patents

実行装置 Download PDF

Info

Publication number
WO2007011001A1
WO2007011001A1 PCT/JP2006/314428 JP2006314428W WO2007011001A1 WO 2007011001 A1 WO2007011001 A1 WO 2007011001A1 JP 2006314428 W JP2006314428 W JP 2006314428W WO 2007011001 A1 WO2007011001 A1 WO 2007011001A1
Authority
WO
WIPO (PCT)
Prior art keywords
class
execution
memory
program
code
Prior art date
Application number
PCT/JP2006/314428
Other languages
English (en)
French (fr)
Inventor
Kazufumi Miyatake
Tomonori Nakamura
Hidetaka Ohto
Original Assignee
Matsushita Electric Industrial Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to US11/917,948 priority Critical patent/US20100146304A1/en
Priority to JP2007526058A priority patent/JPWO2007011001A1/ja
Priority to EP06781383A priority patent/EP1909244A1/en
Publication of WO2007011001A1 publication Critical patent/WO2007011001A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode

Definitions

  • the present invention relates to a technique for preventing eavesdropping and tampering of a program, and more particularly, to a technique for preventing a program from being analyzed, tampered with, etc. during program execution.
  • applications have been executed on devices having information processing functions such as personal computers, digital televisions, mobile phones, and the like. For example, it is downloaded from a server on the Internet by a program distribution service.
  • a CPU (Central Processing Unit) 200 that implements this method has the encoding rule determination unit 201 determine the data determined by the data determination unit 202 among the data in the encoding program.
  • the data is encoded by the data encoding unit 203 using the method, and the data is used.
  • An arithmetic expression used by the arithmetic expression converter 204 is placed in a memory. Data that needs to be decrypted is decrypted by the decryption processing unit 205.
  • Patent Document 1 Japanese Patent Laid-Open No. 2005-49925
  • the present invention does not complicate the application program itself, and can prevent an important part of the application program from fraud such as analysis without requiring a device having a large tamper resistance.
  • the purpose is to provide an execution device.
  • the execution device of the present invention is a program execution device that executes an application program having one or more classes including an execution code created in an object-oriented language, When loading the class, the second execution device including a memory and a processor, which has tamper resistance with the first execution device, loads the execution code of the class into the memory of the second execution device, and And a loader for loading a portion other than the execution code loaded into the memory of the second execution device into the memory within the first execution device.
  • the execution apparatus has the above-described configuration, so that while executing an application class, an execution code is loaded only into a memory of an execution device having tamper resistance and executed. Therefore, it becomes difficult to analyze and falsify the execution code part using a debugger or the like at the time of execution, and the application can be protected against illegal acts. Since it is stored in the memory of the execution device that it has, the execution device that has tamper resistance is smaller than when the entire class is stored.
  • the execution code of the class is encrypted
  • the program execution device further includes decryption means for decrypting the encrypted information
  • the loader is encrypted. It is also possible to cause the decryption code means to decrypt the executable code and load the decrypted executable code into the memory of the second execution device! /.
  • the class to be protected can be encrypted, so it cannot be executed even if the application is copied, it can be protected at times other than the execution time, and the execution section having tamper resistance at the time of execution. Will be able to run and protect the application.
  • the class is encrypted
  • the first execution device further includes determination means for determining whether or not the class is encrypted and the second execution device includes
  • the execution device further includes decryption means for decrypting the encrypted class stored in the memory in the device, and the loader is a first executed by a processor of the first execution device.
  • a loader and a second loader that is executed by the processor of the second execution device.
  • the first loader causes the determination means to determine whether or not the class is encrypted, and is encrypted.
  • the class determined to be not loaded is loaded into the memory in the first device, the class determined to be encrypted is stored in the memory of the second execution device, and the second loader Execution device menu
  • the encrypted class stored in the memory is decrypted by the decryption means, and the execution code of the decrypted class obtained is loaded into the memory of the second execution device and the decrypted class is loaded.
  • the portion of the class other than the execution code loaded into the memory of the second execution device is associated with the execution code and the memory in the first device. As well as to load.
  • the program execution apparatus further includes a control unit that controls execution of the class, and the control unit causes the processor of the first device to execute the class stored in the memory of the first device. If the execution code of the class is not recorded in the memory of the first device, the corresponding execution code stored in the memory of the second device may be executed by the processor of the second device. .
  • one class can be divided and stored in association with a normal execution device memory and a tamper-resistant execution device memory.
  • the normal execution device and the execution device having tamper resistance can be shared and executed. Therefore, only the executable code to be protected in the class can be stored in the memory of the tamper resistant execution device and executed.
  • the execution device of the present invention is a tamper-resistant execution device provided in a program execution apparatus that executes an application program having one or more classes including an execution code, created in an object-oriented language.
  • a memory a processor, decryption means for decrypting the encrypted class stored in the memory, and the decryption means for decrypting the encrypted class stored in the memory.
  • the execution code of the decrypted class obtained is loaded into the memory, and the portion of the decrypted class other than the execution code loaded into the memory is associated with the execution code.
  • a loader for loading into the memory outside the device.
  • a computer program includes a memory and a processor provided in a program execution device that executes an application program having one or more classes including an execution code, which is created in an object-oriented language.
  • Execution device with tamper resistance A computer program for causing a chair to perform a load process, wherein a decryption step for decrypting an encrypted class stored in the memory and an encryption stored in the memory are received.
  • the class is decoded in the decoding step, the execution code of the decoded class obtained is loaded into the memory, and the portion of the decoded class other than the execution code loaded into the memory is A step of associating with the execution code and loading it into a memory outside the device.
  • an integrated circuit of the present invention is an integrated circuit having tamper resistance provided in a program execution device that executes an application program having one or more classes including an execution code, which is created in an object-oriented language.
  • a circuit a memory, a processor, decryption means for decrypting an encrypted class stored in the memory, and the decryption of an encrypted class stored in the memory
  • the executable code of the decrypted class obtained is decoded into the memory, and the portion of the decrypted class other than the executable code loaded in the memory is executed.
  • An integrated circuit comprising: a loader that is loaded in a memory outside the device in association with a code.
  • FIG. 1 is a diagram showing a hardware and software configuration of an execution device according to the present invention.
  • FIG. 2 is a diagram showing an example of a program stored in the first ROM 1920.
  • FIG. 3 is a diagram showing an example of data and programs stored in a second ROM 2920.
  • FIG. 4 is a functional block diagram showing a configuration of an execution device according to the present invention.
  • FIG. 5 is a diagram showing a configuration example of an application program 1210.
  • FIG. 6 is a diagram showing a configuration example and content example of a protection target class list 1220.
  • FIG. 7 is a diagram showing a configuration example of a class file.
  • FIG. 8 is a diagram showing a subprogram configuration of the virtual machine 1100.
  • FIG. 9 is a diagram showing a configuration of a subprogram of a byte code processing unit.
  • FIG. 10 is a flowchart showing an activation process of execution device 100.
  • FIG. 11 is a flowchart showing a load process of execution device 100.
  • FIG. 12 is a diagram showing a state in which a class file of a protection target class is loaded.
  • FIG. 13 is a flowchart showing class execution processing of execution apparatus 100.
  • FIG. 14 is a flowchart showing bytecode execution processing of the execution device 100.
  • FIG. 15 is a diagram showing an example of a method in the ava (registered trademark) language.
  • FIG. 16 is a diagram showing bytecode 4100 obtained by compiling method 4000.
  • FIG. 17 is a diagram showing an example of the state of the work area 1400 when the ava (registered trademark) frames are stacked.
  • FIG. 18 is a diagram showing an example of the state of the work area 1400 after executing the iadd instruction.
  • FIG. 19 is a diagram showing an example of the state of the work area 1400 after executing the newarray instruction.
  • FIG. 20 is a diagram showing an example of the state of the work area 1400 after executing the areturn instruction.
  • FIG. 21 is a functional block diagram illustrating a configuration example of an execution apparatus 500 according to the second embodiment.
  • FIG. 22 is a flowchart showing a load process of execution device 500.
  • FIG. 23 is a diagram showing a state in which a class file of a protected class is loaded.
  • FIG. 24 is a diagram showing an example of a byte code.
  • FIG. 25 is a diagram showing an example of divided byte codes.
  • FIG. 26 is a flowchart showing class execution processing of the execution apparatus 500 of the second embodiment.
  • FIG. 27 A diagram showing a configuration example of the execution device 800 of the third embodiment.
  • FIG. 28 is a flowchart showing class execution processing of the execution device 800 of the third embodiment.
  • FIG. 29 is a diagram showing a configuration of a conventional technique.
  • the execution device focuses on the fact that, in many cases, the application itself can be efficiently protected by protecting a part of the programs of the application against the illegal acts.
  • Each application has a different purpose and purpose. Different programs that do not want to be analyzed, altered, etc., that is, programs with confidentiality are different.
  • the present invention intends to protect an application itself by executing only a processing program that is essential for protecting the application from fraud in an execution device having tamper resistance.
  • the key processing may be all applications.
  • the present invention makes it difficult to analyze a program by executing only an execution code of the key processing program in an execution device having tamper resistance.
  • the execution device according to the present invention has a function of determining the program of the key process during application execution. .
  • Java (registered trademark) application running on a Java (registered trademark) virtual machine will be described.
  • the execution device is specifically an electronic device equipped with a Java (registered trademark) virtual machine such as a digital TV, a set-top box, a car navigation terminal, a mobile phone, or a PDA (Personal Digital Assistants). Is applicable.
  • FIG. 1 is a diagram showing the hardware and software configurations of an execution device that is effective in the present invention.
  • the execution device 100 includes a normal execution unit 1000 and a protection execution unit 2000.
  • the normal execution unit 1000 is an execution unit that is not specially protected, and is the same as the program execution means installed in a normal personal computer or digital home appliance.
  • the protection execution unit 2000 is a tamper-resistant execution unit that can prevent eavesdropping and tampering by an unauthorized user and can safely execute a program.
  • the normal execution unit 1000 and the protection execution unit 2000 each include a CPU and a memory.
  • the normal execution unit 1000 includes a first CPU 1900, a first IRAM (Random Access Memory) 1910, and a first IROM (Read Only Memory) 1920
  • the protection execution unit 2000 includes a second CPU 2900, a second RAM 2910, and a second ROM 2920. Prepare.
  • the first RAM is assumed to be accessible from the second CPU 2900.
  • Each RAM (1910, 2910) is specifically composed of a primary storage memory such as SRAM, DRAM, etc. Used to temporarily store data when the CPU (1900, 2900) performs processing.
  • Each ROM (1920, 2920) is specifically composed of a read-only nonvolatile memory such as a flash memory or a hard disk.
  • the first ROM 1920 and the second ROM 2920 store programs and the like of each processing unit activated by the normal execution unit 1000 and the protection execution unit 2000, respectively.
  • the normal execution unit 1000 includes an OS (Operating System) 1020 which is basic software, a Java (registered trademark) virtual machine 1100, an application program 1210 executed by the execution device 100, and an external of the execution device 100.
  • the application also includes an application acquisition program 1010 having a function of downloading the application program 1210.
  • the Java (registered trademark) virtual machine 1100 (hereinafter referred to as "virtual machine") is a Java (registered trademark) virtual machine that sequentially analyzes and executes a program written in the Java (registered trademark) language. . In other words, it simulates the CPU of the virtual machine 1100, which is a software program, and analyzes and executes the instruction code of Java (registered trademark).
  • OS 1020 is a generic term for technologies that are composed of kernels and libraries that execute other subprograms in parallel, such as Linux. The OS 1020 executes the Java (registered trademark) virtual machine 1100 as a subprogram.
  • the protection execution unit 2000 includes a byte code processing unit 2200 that controls execution of an application in the protection execution unit 2000, and a decryption processing unit 2100 having a function of decrypting an encrypted program. .
  • FIG. 2 is a diagram showing an example of a program stored in the first ROM 1920.
  • the first ROM 1920 includes an OS that is a program loaded into the memory of the normal execution unit 1000.
  • FIG. 3 is a diagram showing an example of data and programs stored in the second ROM 2920.
  • the byte code processing unit 2921 and the decryption processing unit 2922 which are programs loaded into the memory of the protection execution unit 2000, and the decryption key 2923 are stored.
  • the decryption key 2923 is used by the decryption processing unit 2100 to decrypt the encrypted application program 1210.
  • the execution device 100 includes hardware and software for executing an original function, for example, a broadcast reception device in the case of a television.
  • FIG. 4 is a functional block diagram showing the configuration of the execution device according to the present invention.
  • the thin line represents the data flow when the class is loaded, and the thick line represents the data flow when the class is executed. In this figure, only the data flow when executing the encrypted class file is shown. The same applies to FIG.
  • the execution device 100 includes a normal execution unit 1000 and a protection execution unit 2000 as shown in FIG. Here, only functional units that are directly related to the description of the embodiment are described.
  • the normal execution unit 1000 includes an application storage unit 1200, a virtual machine 1100, a class storage unit 1300, a work area 1400, and a first CPU.
  • the application storage unit 1200 has a function of storing the application program 1210.
  • the state force when the application acquisition program 1010 (see FIG. 1) reads the application program 1210 will be described.
  • the application storage unit 1200 is secured in the first RAM 1010.
  • FIG. 5 is a diagram illustrating a configuration example of the application program 1210.
  • the application program 1210 includes a plurality of class files (such as 1211) and a protected class list 1220.
  • the class file includes an encrypted class file and an unencrypted plaintext class file.
  • the encrypted class is a class that performs confidential processing.
  • Whether or not the class file is encrypted is determined by referring to the protected class list 1220.
  • FIG. 6 is a diagram showing a configuration example and content example of the protection target class list 1220.
  • the protected class list 1220 is a list of encrypted class file identifiers.
  • the class name is an identifier. This class name is stored in a constant pool for each class described later.
  • class file 001”, “class file 003”, and “class file 021” of “class file 001”, “class file 002”, etc. constituting the application program 1210 are encrypted.
  • FIG. 7 is a diagram showing a configuration example of the class file.
  • the class file 3000 includes class structure information 3100, a constant pool 3200, meta information 3300 of zero or more methods, and zero or more byte codes 3400.
  • Classfa The file may contain other information, but only items relevant to the present invention will be described here.
  • Class structure information 3100 is information related to the structure of the class, such as fields and methods held by this class, and the ability to inherit which class.
  • the constant pool 3200 is information such as field names and method names of other classes that are defined in this class or that also refer to this class power.
  • the method meta information 3300 is information on the method such as the access flag of each method and the size of the argument.
  • Byte code 3400 describes processing to be executed in the class.
  • a source program written in the Java (registered trademark) language is converted into byte code by a byte code compiler.
  • This bytecode is a hardware-independent intermediate code.
  • Method meta-information 3300 and bytecode 3400 exist in a one-to-one correspondence with methods belonging to the class. That is, the same number of methods as the number of methods includes the method meta information 3300 and the bytecode 3400 in the class file.
  • class structure information 3100 the constant pool 3200, and the method meta information 3300 are collectively referred to as “meta information”.
  • the virtual machine 1100 is composed of a plurality of subprograms. In the figure, only a loader 1120 and an interpreter 1110 having functions unique to the present invention are shown.
  • FIG. 8 is a diagram showing the configuration of the subprogram of the virtual machine 1100.
  • the virtual machine 1100 includes an interpreter 1110, a P-writer 1120, a verifier 1130, a Java (registered trademark) heap management unit 1140, a Java (registered trademark) native library 1150, a JIT compiler 1160, and a class library 1170.
  • the interpreter 1110 is a subprogram having a function of interpreting and executing the bytecode included in the class file, and is a subprogram that performs core processing on the virtual machine 1100.
  • the interpreter 1110 according to the present invention has a function of detecting that it is stored in the bytecode force protection execution unit to be executed at the time of execution of the class and passing control.
  • the loader 1120 has a function of searching the class file of the class to be executed from the application program 1210 and loading the found class file into the virtual machine 1100. At this time, the class is loaded in an executable state.
  • the loader 1120 of the present invention has a function of determining whether or not the class power to be loaded is encrypted and, if encrypted, requesting the load to the protection execution unit 2000. .
  • the class loader 1120 has a function of performing class unload processing.
  • the class unloading process is a process for removing from the virtual machine 1100 a class that has been executed and is no longer needed.
  • the verifier 1130 has a function of checking the deficiency of the data format of the class and the safety of the Neut code included in the class (see Java (registered trademark) Virtual Machine Specification). Class loader 1120 will not load classes that verifier 1130 determines are not valid! /.
  • the Java (registered trademark) heap management unit 1140 has a function of managing a working memory used by a Java (registered trademark) application, called a Java (registered trademark) heap. This working memory is secured in the first RAM 1910.
  • the Java (registered trademark) heap management unit 1140 has a function of performing garbage collection.
  • Garbage collection is a process that frees up the working memory that is no longer needed for application execution and allows it to be reused for other purposes.
  • the Java (registered trademark) native library 1150 is a library called from a Java (registered trademark) application, and is a node software that is described in FIG. 1 provided in the OS 1020 and the execution device 100. Provide functions provided by subprograms to applications.
  • the JIT compiler 1160 has a function of translating the bytecode into an execution format that can be understood by the first CPU 1900 or the second CPU 2900.
  • the class library 1170 is configured with classes necessary for the execution of the virtual machine 1100, and the virtual library 1170 This is the first class that machine 1100 loads at runtime.
  • the class library 1170 is a part of the virtual machine 1100 and is a set of classes that are open to the public.
  • the class storage unit 1300 has a function of storing a class of an application program to be executed.
  • the class storage unit 1300 is a so-called method area, and is actually an area in the virtual machine 1100, and loads a class that can be executed by the loader 1120.
  • the class storage unit 1300 is loaded with classes such as a loader 1120 of the virtual machine 1100 or a secure loader 2220 described later of the bytecode unit 2200.
  • the class storage unit 1300 is secured in the first RAM 1910 and can be referred to from the protection execution unit 2000.
  • the work area 1400 is a work area used when executing a class. Specifically, it refers to the stack, heap, etc., and is actually an area in the virtual machine 1100.
  • the work area 1400 is secured in the first RAM 1910 and can be referred to from the protection execution unit 2000.
  • the decryption processing unit 2100 receives the application storage unit 12
  • the encrypted class in 00 is read, decrypted using the encryption key 2923 (see Fig. 3) stored in the encryption key storage unit 2500, and the decrypted class is stored in the decryption class storage unit.
  • An arbitrary encryption algorithm can be used as an encryption algorithm, and typical encryption algorithms include AES (Advanced Encryption Standard) and DES (Data Encryption Standard).
  • the bytecode processing unit 2200 has only a function necessary for bytecode execution out of the functions of the virtual machine 1100, and includes a plurality of subprograms. Only the secure interpreter 2210 and the secure loader 2 220 having the functions are described.
  • FIG. 9 is a diagram showing the configuration of the subprogram of the bytecode processing unit.
  • the bytecode processing unit 2200 includes a secure interpreter 2210, a secure loader 2220, a secure verifier 2230, a secure Java (registered trademark) heap management unit 2240, and a bytecode management unit 2250.
  • the secure interpreter 2210 has a function similar to that of the interpreter 1110 of the virtual machine 1100, receives a request from the interpreter 1110 of the virtual machine 1100, executes a bytecode, and notifies the interpreter 1110 when the execution is completed.
  • the secure loader 1110 has a function of loading a class file in the encryption class storage unit 2400.
  • One class is divided and loaded into the bytecode storage unit 2600 of the self-execution unit and the class storage unit 1300 of the normal execution unit 1000.
  • the part stored in the bytecode storage unit 2600 of the self-execution unit and the part stored in the class storage unit 1300 of the normal execution unit 1000 are stored in association with each other.
  • the association method will be described later with reference to FIG.
  • the secure verifier 2230 has the same function as the verifier 1130 of the virtual machine 1100.
  • the secure Java (registered trademark) heap management unit 2240 has only the function of unloading the bytecode at the time of class unloading among the functions of the virtual machine 1 lOOJava (registered trademark) heap management unit 1140. This is because, except for the Neut code, they are normally stored in the memory of the execution unit 1000, and the virtual machine 1100 manages them.
  • the bytecode management unit 2250 has a function of managing in association with meta information necessary for execution stored in the normal execution unit 1000 when executing the class in the protection execution unit 2000. Specifically, the same identifier is assigned to the Neut code stored in the bytecode storage unit 2600 and the meta information of the method stored in the class storage unit 1300 to manage them in a one-to-one correspondence (Fig. 12).
  • the Neut code storage unit 2600 has a function of storing only the byte code (see FIG. 7) among the classes of application programs to be executed.
  • This byte code storage unit 2600 is a so-called method area, and is actually an area in the Neutcode processing unit 2200, and stores the byte code of the class loaded by the secure loader 2220 and made executable. .
  • this byte code storage unit 2600 is secured in the second RAM 2910. Therefore, the byte code storage unit 2600 is not referred to by the normal execution unit 1000.
  • the class loading process specifically, the process until the execution device 100 starts the application program 1210 for the power-on / off operation will be described. Then, with reference to FIG. 11 and FIG. The process of loading a class will be explained.
  • FIG. 10 is a flowchart showing the activation process of execution device 100.
  • step S100 When the user turns on the execution device 100 (step S100), the first CPU 1900 loads the OS1921 (see Fig. 2) stored in the first ROM 1920 into the first RAM 1910. Start OS 1020 (step SI 10).
  • the Java (registered trademark) virtual machine 1922 stored in the first ROM 1920 of the OS 1020 is loaded into the first RAM 1910, and the virtual machine 1100 is activated (step S120).
  • the 2nd CPU2900 [This load request is notified via the 1st CPU1900, the 2CPU2900 loads the bytecode processing unit 2921 stored on the 2nd ROM2900 into the 2nd RAM2910, The bytecode processing unit 2200 is activated (step S13 0).
  • the second CPU 2900i, the second ROM 2900, and the decryption process 2922 (see FIG. 3) stored on the second ROM 2900 are loaded into the second RAM 2910, and the decryption processing unit 2100 is started (step S14 0). .
  • step S120 the order of starting the virtual machine 1100 (step S120) and starting the decryption processing unit 2100 and the bytecode processing unit 2200 (steps S130 and S140) may be reversed.
  • the virtual machine 1100 starts executing the application program 1210.
  • the application program 1210 is started by executing a specific class file of the application program 1210. This specific class file name is stored in advance by the virtual machine 1100! /.
  • This first class is loaded by the loader 1120, and execution is started by the interpreter 1110. After that, the necessary class files are loaded and executed from the application storage unit 1200, and the application is executed. It will be.
  • the virtual machine 1100 Before first loading a specific class file (step S160), the virtual machine 1100 stores the protected class list 1220 included in the application program 1210 together with the specific class file in the class storage unit 1300 ( Step S 150).
  • FIG. 11 is a flowchart showing the loading process of execution device 100. This loading process This is a process that performs 1000 loaders 1120 for normal execution and 2220 secure loaders for protection execution 2000.
  • FIG. 12 is a diagram showing a state in which the class file of the protection target class is loaded.
  • the interpreter 1110 passes the class file name to the loader 1120 and requests loading.
  • the loader 1120 determines whether or not the class power protection target class of the passed class file name, that is, whether or not the class power is encrypted (step S200).
  • the determination method is to check whether the class file name passed in the list of the protection target class list 1220 of the class storage unit 1300 is listed, and if so, determine that the class is a protection target class. To do.
  • step S200 determines that the class requested to be loaded is not a protected class (step S200: NO)
  • the loader 1120 loads the class storage unit 1300 (step S260).
  • step S200 if it is determined that the class requested to be loaded is a protected class (step S200: YES), the address and size in the application storage unit 1200 of the class to be loaded are obtained. Then, it notifies the decryption processing unit 2100 of the protection execution unit 2000 and requests loading (step S210).
  • the decryption processing unit 2100 Upon receiving the notification, the decryption processing unit 2100 reads the class file from the application storage unit 1200, decrypts it using the decryption key 2923 stored in the encryption key storage unit 2500, and stores it in the decryption class storage unit 2400. (Step S220).
  • the class stored in the decryption class storage unit 2400 is referred to as a “decryption class file”.
  • the decryption processing unit 2100 that created the decryption key class file notifies the byte code processing unit 2200 to that effect.
  • the bytecode processing unit 2200 Upon receiving the notification, the bytecode processing unit 2200 causes the secure verifier 2230 to inspect the decryption class file and requests the secure loader 2220 to load it.
  • the secure loader 2220 Upon receiving the load request, the secure loader 2220 analyzes the syntax of the decryption key class file, determines the bytecode part and the meta information part from the tag of the decryption key class file, and determines the bytecode part. And meta information part (step S230). Of this split At this time, the secure loader 2220 adds two pieces of information. The first is information indicating that the bytecode is divided, and the second is information for associating the bytecode part with the meta information part. Information to be added will be described later with reference to FIG.
  • secure loader 2220 loads the byte code portion into byte code storage unit 2600 (step S240), and loads the meta information portion into class storage unit 1300 of normal execution unit 1000 (step S250). .
  • each part is in a format that the virtual machine 1100 can execute.
  • Figure 12 shows the state loaded in each storage unit.
  • the bytecode storage unit 2600 of the protection execution unit 2000 is loaded with bytecode 2610, and the class storage unit 1300 of the normal execution unit 1000 has class structure information 1310, constant pool 1320, and method meta information 1330. Being done!
  • Step S230 the secure loader 2220 displays information indicating that the bytecode has been divided and information for associating the bytecode portion with the meta information portion. Append.
  • a byte code division flag 1331 which is a flag indicating that the code has been divided, is added to the meta information 1330 of the method.
  • the byte code division flag 1331 is “1”, it is divided, and when it is “0”, it indicates that it is not divided.
  • the secure loader 2220 adds information for associating the bytecode portion with the meta information portion. This information is instructed and added to the bytecode management unit 2250.
  • the bytecode management unit 2250 adds ID2611 to Neutcode 2610 and ID1332 to method metainformation 1330 so that the relationship between bytecode 2610 and method metainformation 1330 can be identified, and assigns an ID to the same value. Manage it.
  • the meta information 1330 ID1332 and bytecode 2610 ID2611 of the method converted from the same method to the internal format must have the same value.
  • step S200 determines whether a protection target class (step S200: NO) and is loaded into the class storage unit 1300).
  • the loader 1120 displays “0” in the bytecode division flag 1331 of the method meta information. Set. Note that nothing is set in the ID 1332 of the method meta information 1330.
  • Secure verifier 2230 force Decryption class file is inspected. If the result of the inspection is an error, the loader 1120 is notified of this and the loading process is terminated.
  • FIG. 13 is a flowchart showing the class execution process.
  • the interpreter 1110 calls a method (step S30 0).
  • the interpreter 1110 determines whether the byte code of the corresponding method is divided, that is, whether the Neut code is stored in the class storage unit 1300 and can be executed by the normal execution unit 1000 (step S310).
  • This determination is made by checking the byte code division flag 1331 of the method meta information 1330.
  • step S310 NO
  • the interpreter 1110 executes the method (step S350).
  • the process in which the interpreter 1110 executes the method is the same as that of the conventional Java virtual machine. The operation is the same (see Java (registered trademark) Virtual Machine Specification).
  • step S310 when the bytecode division flag 1331 is “1” (step S310: YES), the interpreter 1110 calls the bytecode processing unit 2200 of the protection execution unit 2000 prepared in 031020. Call execution environment transition function and request execution of bytecode. For example, when the Neut code processing unit 2200 periodically monitors a specific bit on the first RAM 1910 and the execution environment transition function sets this specific bit to “1”, the byte code processing unit 2200 starts processing. It is a mechanism.
  • the secure interpreter 2210 of the bytecode processing unit 2200 Upon receipt of the request, the secure interpreter 2210 of the bytecode processing unit 2200 passes the received ID1332 value to the bytecode management unit 2250 and requests a search for a bytecode having the same ID.
  • the bytecode management unit 2250 that has received the request receives the same value I from the bytecode storage unit 2600.
  • the byte code 2610 having D2611 is searched, and the address of the byte code is returned to the secure interpreter 2210 (step S330).
  • the secure interpreter 2210 that has received the bytecode address executes the bytecode (step S340).
  • the secure interpreter 2210 refers to the class storage unit 1300 for meta information necessary for execution, and uses the work area 1400 for the stack area and the heap area.
  • FIG. 14 is a flowchart showing the bytecode execution processing.
  • This flowchart is a flowchart for executing the Java (registered trademark) language method 4000 shown in FIG. 15. An example of executing this method 4000 will be described below.
  • this method 4000 is a method of the class file of the protection target class 1220.
  • Figure 16 shows the bytecode 4100 obtained by compiling method 4000.
  • the program of method 4000 is a program that takes two values of int type as arguments, creates an int type array whose size is the sum of the two values, and returns the int type array as the return value.
  • the secure interpreter 2210 first creates a frame 1430 in the frame area 1420 of the work area 1400 of the normal execution unit 1000. Specifically, a Java (registered trademark) frame 1430 of a method 4000 to be executed is stacked on the calling Java (registered trademark) frame 1440 (step S700).
  • the call source Java (registered trademark) frame 1440 is the Java (registered trademark) frame of the method that called the method 4000 to be executed from V, and each frame has the same configuration. Yes.
  • FIG. 17 shows the state of the work area 1400 when Java (registered trademark) frames to be executed by the secure interpreter 2210 are stacked.
  • a Java (registered trademark) heap 1410 In the work area 1400, a Java (registered trademark) heap 1410, a Java (registered trademark) frame 1430, and a call 3 ⁇ 4 [ava (registered trademark) frame 1440 are generated.
  • the Java (registered trademark) heap 1410 is a working memory used by the virtual machine 1100, and is managed by the Java (registered trademark) heap management unit 1140 (see FIG. 8).
  • a Java (registered trademark) frame 1430 is a working memory of a method that is executed by the secure interpreter 2210 !, and includes a local variable area 1450 and an operand stack 1460.
  • the local variable area 1450 is an area for storing local variables of the method.
  • the operand stack 1460 is a stack that performs an operation executed by a method. For example, if there is a code that adds a local variable in a method, data is loaded from the local variable area 1 450 to the operand stack 1460, The addition is performed on the operand stack 146 0 and stored in the local variable area 1450.
  • the secure interpreter 2210 that has loaded the argument with the frame starts the processing of the bytecode 4100.
  • the code 4101 in the first to third lines of the byte code 4100 is a stack operation, and the process proceeds as follows (step S710).
  • the iload instruction loads the value of a variable in the local variable area onto the operand stack.
  • the iadd instruction is an instruction that adds two values from the top of the operand stack.
  • the resulting work area 1400 is shown in FIG.
  • the secure interpreter 2210 executes the code “newarray” 4102 of the bytecode 4100.
  • the newarray instruction is an instruction for allocating an array area having the number of elements at the top of the operand stack in the Java (registered trademark) heap 1410.
  • the state of the work area 1400 with the area secured is shown in FIG.
  • the newarray instruction in order to prevent writing to the Java (registered trademark) heap also from other threads at the same time, uses a mouth function provided by the OS 1020 of the normal execution unit 1000. Before allocating the area, it is necessary to acquire a Java (registered trademark) heap lock.
  • the secure interpreter 2210 cannot directly use the lock function provided by the OS 1020 of the normal execution unit 1000, when the “newarray” 4102 is fetched, the top of the operand stack 1460 is obtained.
  • the value “i + j” 1461 is extracted from the operand stack 1460 (see FIG. 18), and the Java (registered trademark) heap management unit 1140 of the virtual machine 1100 is called using this value as an argument (step S720).
  • the Java (registered trademark) heap management unit 1140 uses the lock function provided by the OS 1020. Acquire a lock on the Java® heap 1410.
  • the Java (registered trademark) heap management unit 1140 sends to the Java (registered trademark) heap 1410 the object 1 (the size of “i + j” received as an argument 1 ( 1411) (step S730) and the reference 1462 to object 1 is put on the operand stack (step S740, see FIG. 19).
  • FIG. 19 shows the state force of the work area 1400 at this time.
  • the secure interpreter 2210 performs processing of “areturn” 4103 of the byte code 4000.
  • the secure interpreter 2210 knows that the processing of the current method has been completed, and discards the Java (registered trademark) frame 1430, which is the working memory of the method 4000, and calls it. On the original Java frame 1440, the top value of the operand stack 1460, the reference 1442 to the object 1 is stacked (step S750).
  • FIG. 20 shows the state of the work area 1400 at that time.
  • secure interpreter 2210 returns processing to interpreter 1110. This completes the execution of the bytecode 4100 and the normal execution unit 1000 continues the next processing.
  • the normal execution unit 1000 when there is a process that cannot be performed in the protection execution unit 2000 when executing bytecode, the normal execution unit 1000 is requested to perform the process. Even in this case, the byte code itself is protected.
  • the newarray instruction is taken as an example.
  • the processing that has been transferred from the secure interpreter 2210 to the normal execution unit 120 is also normal. Transition to execution unit 1000 may be required.
  • the secure interpreter 2210 calls the Java (registered trademark) native library 1150
  • the Java (registered trademark) native library 1150 exists only in the normal execution unit 1000, so the processing needs to be transferred to the normal execution unit 1000. There is.
  • the execution device of the present embodiment is particularly effective when access to the memory of the protection execution unit normal execution unit is restricted.
  • the second CPU 2900 can access the first RAM 1910. Therefore, when the protection execution unit executes bytecode, it accesses the meta information in the memory of the normal execution unit. Was easy.
  • an execution device capable of maintaining the execution speed while protecting the bytecode from an unauthorized user even when the second CPU 2900 and the first RAM 1910 cannot be accessed will be described.
  • FIG. 21 is a functional block diagram illustrating a configuration of the execution device according to the second embodiment.
  • protection execution unit 2 is almost the same as that of the execution device of the first embodiment (see FIG. 4). However, protection execution unit 2
  • the execution device 500 includes a normal execution unit 5000 and a protection execution unit 6000.
  • the normal execution unit 5000 includes an application storage unit 1200, a virtual machine 5100, a class storage unit 1300, a work area 1400, and a first CPU 1900.
  • the application storage unit 1200, the class storage unit 1300, the work area 1400, and the first CPU 1900 are the same as those in the first embodiment.
  • the virtual machine 5100 includes a loader 5120 and an interpreter 5110, and basically has the same functions as the loader 1120 and the interpreter 1110 of the first embodiment.
  • the interpreter 1110 determines whether the bytecode is in the force protection execution unit 2000 in the normal execution unit 1 000 by referring to the bytecode division flag in the meta information when executing the class.
  • the interpreter 5110 of this embodiment is different in that it refers to the division flag in the byte code.
  • the method of setting the division flag in the bytecode is explained in ⁇ Method of selecting a code part that does not require meta information etc.> described later.
  • the loader 1120 of Embodiment 1 passes the class file address and size, and reads the class file to the protection execution unit 2000.
  • the loader 5120 of this embodiment is different in that it passes the read encrypted class file. This is because the protection execution unit 6000 cannot access the application storage unit 1200 in which the class file is stored.
  • the decryption key class storage unit 2400, the encryption key storage unit 2500, the byte code storage unit 2600, and the second CPU 2900 are the same as those in the first embodiment.
  • the decryption processing unit 6100 basically decrypts the class file in the same manner as the decryption processing unit 2100 of the first embodiment, but the decryption processing unit 2100 reads the class file from the application storage unit 1200 and decrypts it. In contrast, the decryption processing unit 6100 decrypts the class file delivered by 5000 normal execution units.
  • the bytecode processing unit 6200 includes a secure interpreter 6210 and a secure loader 6220.
  • the secure interpreter 2210 is the power that accessed the meta information and beep normally stored in the memory of the execution unit 1000.
  • the secure interpreter 6210 The difference is that the data information is not accessed.
  • the secure loader 2220 writes the meta information directly into the class storage unit 1300, but the secure loader 5220 is output via the second CPU 2900 to the normal execution unit 5000 and needs to be written by the first CPU 1900.
  • the work area 6700 has the same function as the work area 1400 of the normal execution unit 5000.
  • the first RAM 1910 cannot be accessed. It is reserved in the second RAM 2910.
  • the heap area is secured in the work area 1400 of the normal execution unit 5000 as in the first embodiment.
  • FIG. 22 is a flowchart showing the load process of execution device 500.
  • This load process is a process executed by 5000 loaders 5120 for normal execution and 6220 secure loaders 6220 for protection execution.
  • FIG. 23 is a diagram showing the state of the class storage unit 1300 and the bytecode storage unit 2600 loaded with the class file of the protection target class.
  • a class file name is passed to the interpreter 5110 power loader 5120 to request loading, and the loader 5120 that receives the request determines whether the class power of the passed class file name is encrypted or not. If it is determined (step S200) and it is determined that the class is not protected (step S200: NO), it is loaded into the class storage unit 1300 (step S260).
  • step S200 if it is determined that the class requested to be loaded is a protected class (step S200: YES), the class to be loaded is read from the application storage unit 1200 and read. The extracted class file is passed to the decryption processing unit 6100 (step S410).
  • the decryption processing unit 6100 Upon receiving the class file, the decryption processing unit 6100 decrypts the received class file using the decryption key 2923 stored in the encryption key storage unit 2500 and stores it in the decryption class storage unit 2400 ( Step S420).
  • the decryption processing unit 6100 that created the decryption key class file indicates that the bytecode processing unit 62
  • the bytecode processing unit 6200 that has received the notification causes the secure verifier 2230 to inspect the decryption class file and requests the secure loader 6220 to load it.
  • the secure loader 6220 Upon receiving the load request, the secure loader 6220 analyzes the syntax of the decryption key class file and converts it into an internal format executable by the virtual machine 5100. At this time, secure loader
  • the 6220 discriminates the byte code portion and the meta information portion from the tag of the decryption key class file and divides them (step S430).
  • the secure loader 6220 selects, from the bytecode, the portion of the bytecode that does not require access to the meta information and the Java (registered trademark) heap at the time of execution. A method of selecting a code portion that does not require meta information or the like will be described later with reference to FIG.
  • the secure loader 6220 divides it into a byte code that does not require meta information and a byte code that requires meta information (step S440).
  • the secure loader 6220 When the secure loader 6220 divides the byte code that does not require meta information and the byte code that requires meta information, the secure loader 6220 requests the byte code management unit 2250 to request method meta information and byte code that does not require meta information. ID is added to each (Fig. 2)
  • the secure loader 6220 converts the meta information and the bytecode that requires meta information, etc.
  • the first CPU 1900 receives the received meta information (see FIG. 23: class structure information 1310, constant pool 1320, method meta information 5
  • the secure loader 5220 uses byte code 6610 that does not require meta information (see Fig. 23).
  • "iload-1" on the first line and "iload-2" on the second line are instructions that load the first value of the local variable area on the operand stack and do not require meta information .
  • the operand stack is an area in the work area 6700 frame area.
  • “iadd” on the third line is an instruction for adding values on the operand stack and does not require meta information.
  • the Neut code 7001 from the first to third lines is an instruction that does not require meta information.
  • “Newarray” on the fourth line is an instruction that requires a Java (registered trademark) heap to secure an area in the Java (registered trademark) heap on the work area 1400.
  • the byte code 7002 in the fourth and fifth lines is an instruction that requires access to meta information and Java (registered trademark) heap.
  • Figure 25 shows an example of divided bytecodes.
  • Byte code 7001 in the 1st to 3rd lines of byte code 7000 is created as byte code 7200 that does not require meta information. Cut out the bytecodes of consecutive lines as one lump. In this embodiment, a method is described as an example.
  • byte code 7000 a byte code 7200 that does not require meta information and a part of the code that is manually divided is rewritten as byte code 7100 that requires meta information.
  • a byte code 7100 that requires meta information is embedded with a division flag 7101 indicating that it has been divided into the divided head portions. Specifically, an instruction code indicating a predetermined division flag is described.
  • a meaningless code 7102 such as a nop instruction is embedded.
  • a part of the byte code of the class file can be loaded into an area that cannot be analyzed by a debugger or the like. If there is a plurality of bytecode chunks that do not require meta information, the method can be executed by associating the divided flag 7101 with the corresponding bytecode. For example, a common ID is assigned to the division flag and the corresponding bytecode.
  • FIG. 26 is a flowchart showing the class execution process.
  • step S500 when executing a class, the interpreter 5110 calls a method (step S500).
  • the interpreter 5110 creates a Java (registered trademark) frame of the method to be executed in the work area 1400, and starts executing the bytecode 7100 that requires meta information (step S510).
  • the interpreter 5110 fetches an instruction, it determines whether or not the instruction is the division flag 7101 (step S520).
  • step S520 If it is not the division flag 7101 (step S520: NO), that is, if it is another instruction code, the instruction is executed by the normal execution unit 5000 except for the method end (step S570: NO). (Step S 510).
  • step S520 If it is the division flag 7101 (step S520: YES), the interpreter 5110 requests the bytecode processing unit 6200 in the protection execution unit 6000 to perform the process (step S530). At the time of this request, the value of ID5331 in the local variable area and operand stack in the Java frame of the method being executed and the meta information 5330 of the method is passed as an argument.
  • the secure interpreter 6210 of the bytecode processing unit 6200 that has received the request passes the received ID5331 value to the bytecode management unit 2250 and requests a search for a bytecode having the same ID.
  • the bytecode management unit 2250 searches the bytecode storage unit 2600 for a bytecode 6610 that does not require meta information having ID6611 that matches the received ID5331 value (step S540). [0129] The bytecode management unit 2250 that has found the bytecode 6610 that does not require meta information with the matching ID value returns the address of the bytecode to the secure interpreter 6210. For example, the address of byte code 7200 that does not require the meta information of FIG.
  • the secure interpreter 6210 performs processing of the byte code 6610 that does not require meta information, using the local variable area and operand stack received as arguments (step S550).
  • Step S560 When the execution of byte code 6610 that does not require meta information is completed, the local variable area, the operand stack, and the program counter indicating the instruction to be executed next by the interpreter 5110 of the normal execution unit 5000 are used as return values, and the process is interpreted. Return to (Step S560).
  • the interpreter 5110 continues the program counter force received as the return value of the byte code 6610 that requires meta information (step S570, step S510).
  • the subsequent processing is the same as that of the conventional Java (registered trademark) virtual machine.
  • the normal execution unit and the protection execution unit can each operate in multitasking.
  • FIG. 27 is a diagram illustrating a configuration example of the execution device 800 for executing the present embodiment.
  • the second CPU 2900 is similar to the first embodiment in that the second CPU 2900 can read and write to the first RAM 1910 in the normal execution unit 1000.
  • the second CPU 2900 is a CPU physically different from the first CPU 1900.
  • the secure OS 8100 is an OS that supports multitasking such as Linux that runs on the second CPU 2900 in the protection execution board 8000.
  • the class file loading process performed prior to execution is the same as in the first embodiment (see FIG. 11 and the like). Since the functional blocks are the same as those in the first embodiment, the operation of the execution apparatus of the present embodiment will be described with reference to FIG.
  • FIG. 28 is a flowchart showing class execution processing according to the third embodiment.
  • the steps indicated by dotted lines represent processing related to the execution of the target class.
  • the interpreter 1110 of the normal execution unit 1000 starts execution of the thread (step S600), and requests the protection execution unit 8000 for processing when the thread is of a method of the protection target class.
  • the requested process is referred to as “the process”.
  • the interpreter 1110 requests the secure OS 8100 of the protection execution unit 8000 for the processing via the OS 1020 (step S610).
  • the secure OS 8100 temporarily stops the process performed by the protection execution unit 8000, receives the process of the thread that has received the request (step S700), and notifies the OS 1020 that the process has been received.
  • the interpreter 1110 of the normal execution unit 1000 waits for the processing completion notification from the protection execution unit 8000 for the thread that has requested the processing (step S620).
  • the secure OS 8100 passes the process to the scheduler of the secure OS 8100 and registers it (step S710). The start of this process is managed by the scheduler in the secure OS8100.
  • the interpreter 1110 of the normal execution unit 1000 executes the processing of another thread (step S630).
  • the Neut code management unit 2200 of the protection execution unit 8000 also continues the processing of the byte code processing unit 2200 that has been executed before the processing is passed (step S720).
  • the bytecode management unit 2200 receives a notification of the start of the process from the scheduler, and starts the process (step S730).
  • the Neut code management unit 2200 When the Neut code management unit 2200 completes the execution of the process, it notifies the OS 1020 of the secure OS 8100 normal execution unit 1000 that detected the completion (step S740).
  • Step S640 Upon reception of the completion notification from the protection execution unit 8000, the interpreter 1110 of the normal execution unit 1000 enters a waiting state and starts the process again. (Step S640).
  • the normal execution unit 1000 and the protection execution unit 8000 respectively execute other processes in accordance with instructions from the scheduler (step S650 and step S750).
  • the bytecode is stored only in the protection execution unit 8000 to prevent fraud, and the execution speed is improved by operating two CPUs in parallel.
  • all the byte codes are stored in the second RAM, and the processing performed in the protection execution unit may be partly stored in the second RAM as in the second embodiment.
  • the present invention can be implemented.
  • the execution device according to the present invention has been described above based on the embodiment. However, the execution device can be partially modified, and the present invention is of course not limited to the above-described embodiment. That is,
  • the protection target class list is referred to, but other methods may be used.
  • information for identifying another file to be downloaded may be included. If the application is sent by broadcast waves, use the multiplexed file to determine.
  • the application program developer adds a specific character string to the class that needs protection in the class file name, and determines at runtime whether the runtime protection is necessary from the class file name. Even ⁇ .
  • the classes listed in the protection target class list are assumed to be protected and encrypted, but it is not necessary to list all the classes that are encrypted. Even the class that you want to protect and the class you want.
  • a function unit that decrypts the normal execution unit is provided, and the encrypted classes are decrypted and executed on the protection target class list.
  • class name included in the class library in the Java (registered trademark) virtual machine or the like may be described in addition to the power of placing the class file name of the application.
  • only the byte code in the power class that encrypts the entire class may be encrypted. In this case, send only the bytecode to the protection execution unit.
  • the embodiment has been described with one encryption key, a plurality of keys may be used properly.
  • information that can specify the encryption key to be used is put in the list of classes to be protected, and the class is decrypted with the encryption key specified by the information.
  • Embodiment 1 the bytecode division flag is prepared in the meta information of the method. However, it may be created elsewhere.
  • a flag may be prepared for the class information structure information (see FIG. 12 and the like).
  • Embodiment 1 Embodiment 1, Embodiment 2, and Embodiment 3, the protection execution unit is requested to process only when the protection execution unit requires processing, but the protection execution unit does not require processing. In any case, the protection execution unit is requested to perform processing, and the protection execution unit normally performs processing without performing any processing. You may return to an execution part.
  • whether or not the Java (registered trademark) application or virtual machine to be executed is placed in the memory of the normal execution unit and the class file is to be executed by the protection execution unit when loading the class file.
  • the bytecode to be protected may be stored in advance in the second ROM and loaded into the second RAM at the time of execution.
  • the information that associates the meta information with the byte code for example, ID, needs to be set in advance.
  • the first CPU 1900 of the execution device 100 and the second CPU 2900 of the protection execution unit 2000 are physically different CPUs. It is also possible to behave like two CPUs virtually by switching. Also, for a CPU with multiple CPU cores in a single CPU package, such as a multi-core CPU, make that particular core operate as the second CPU.
  • the normal execution unit 1000 and the protection execution unit 2000 each have RAM and ROM.
  • one RAM may be virtually treated as two RAMs.
  • one ROM may be treated as virtually two ROMs.
  • the ROM in the protection execution unit 2000 may be embedded in the second CPU 2900.
  • the application executed by the execution device 100 is downloaded from a server on the Internet.
  • the application acquisition program 1010 may be an application acquired by another method.
  • a Java (registered trademark) application embedded in an MPEG (Moving Picture Coding Experts Group) 2 transport stream may be used.
  • the application acquisition program 1010 is a program that reads the Java (registered trademark) application embedded in the transport stream into the execution device 100.
  • a method for embedding a Java (registered trademark) program in an MPEG2 transport stream For example, there is a DSMCC method.
  • the DSMCC method is a method of encoding a file system consisting of directories and files used by computers in MPEG2 transport stream packets (MPEG standard ISOZIEC1381 81-1, MPEG standard ISOZIEC138181). — See 6).
  • SD card Secure Digital memory card
  • CD-ROM Compact Disk Read Only Memory
  • DVD Digital Versatile Disk
  • Blu-Ray Disc etc.
  • Java registered trademark
  • the application acquisition program 1010 is a program that reads the application with these recording medium capabilities.
  • the application executed by the execution device 100 may be an ava (registered trademark) application recorded in a ROM or the like in the execution device 100! /.
  • the application acquisition program 1400 is a program that reads a Java (registered trademark) application into the working memory with ROM capability.
  • the application acquisition program 1010 is a program having a function of downloading a Java (registered trademark) application according to a protocol such as TLS (Transport Layer Security) or HTTP (Hypertext Transfer Protocol).
  • a protocol such as TLS (Transport Layer Security) or HTTP (Hypertext Transfer Protocol).
  • TLS is a data transfer method that prevents eavesdropping and tampering of data during communication using encryption (see RFC2246).
  • HTTP is generally used for data communication on the Internet. This is the data transfer method used (see RFC2616).
  • RFC Request For Comments
  • IET F Internet Engineering Task Force
  • the application acquisition program 1010 or the like ⁇ Written in the Java (registered trademark) language ⁇ Java (registered trademark) program, etc.
  • the program written in the native language is realized in hardware. It may be.
  • the application executed on the virtual machine is not limited to the one written in the Java (registered trademark) language, and may be one written in another object-oriented language such as C ++. Also, the Java (registered trademark) virtual machine itself may be described in an object-oriented language or a non-object-oriented language.
  • the protection execution unit 2000 of the embodiment can be realized by using, for example, ARM's TrustZone (registered trademark) technology.
  • a conventional CPU has two modes: a normal mode in which an application operates and a privileged mode in which an OS and the like operate.
  • a program that operates in a privileged mode is altered from a program that operates in a normal mode. Is becoming impossible.
  • TrustZone (registered trademark) technology also provides a new special mode called monitor mode.
  • the monitor mode can be entered by executing a special instruction prepared by the CPU.
  • security information called S-bit is notified to peripheral hardware such as RAM and ROM.
  • the RAM and ROM that support TrustZone (registered trademark) technology are configured to allow reading and writing of data to the area allocated to the secure domain only when the S-bit is notified. Also assigned to a secure domain! / S-bits are allowed to be read and written regardless of the power reported.
  • a secure execution unit can be realized by a secure domain.
  • Intel's LaGrande technology is also similar to the TrustZone (registered trademark) technology, such as virtually separating the domain in which normal applications and the OS operating domain from the domain in which the application requiring protection is operating. Provide functionality. By using such a technology, a safe execution unit can be realized.
  • the protection execution unit 2000 is built in the execution device 100.
  • the protection execution unit 2000 may be a smart card or an IC card that is removable from the execution device 100. These smart cards and IC cards contain a CPU, memory, and security circuit inside the card.
  • the protection execution unit 2000 may be implemented entirely by nodeware.
  • data communication between the first CPU and the second CPU must be performed in an encrypted manner to prevent eavesdropping by a third party.
  • the data to be transmitted is encrypted, and the data is decrypted after being received.
  • the execution environment program for the application may be an OS that uses a Java (registered trademark) virtual machine as an example or another execution environment.
  • the application when it corresponds to an execution environment program, it may be a target of a Neut code that conceals the abrasion itself.
  • a program for causing the CPU to execute each control process (see FIG. 4 etc.) for realizing each function of the execution device shown in the embodiment is recorded on a recording medium or via various communication paths.
  • Such recording media include IC cards, optical disks, flexible disks, ROM, flash memory, and the like.
  • the distributed and distributed program is used by being stored in a memory or the like that can be read by the CPU in the device, and each function of the execution device shown in the embodiment is executed by the CPU executing the program. Realized.
  • the protection execution unit (2000, 6000, 8000) in the execution device is typically an integrated circuit. It is realized as an LSI. These may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • IC integrated circuit
  • LSI system LSI
  • super LSI super LSI
  • non-regular LSI depending on the difference in power integration as LSI.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable 'processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • the application execution device conceals the Neut code, which is indispensable for executing and analyzing the application, in a protection execution unit that is realized by hardware and is difficult to eavesdrop on and tamper with. Eavesdropping and tampering protection at the time of execution can be protected, and the rights of creators that occur in content can be protected in the application download distribution business, which is expected to be fully deployed in the future.

Abstract

　プログラム実行装置は、オブジェクト指向言語で作成された、実行コードを含む1以上のクラスを有するアプリケーションプログラムを実行する装置であって、　それぞれメモリとプロセッサとを含む、第１実行デバイスと耐タンパ性を有する第２実行デバイスとを有し、ローダは、クラスを実行する際に、当該クラスの実行コードを第２実行デバイスのメモリにロードし、当該クラスの、第２実行デバイスのメモリにロードした実行コード以外の部分を第１実行デバイス内のメモリにロードし、クラスを実行する。

Description

明 細 書
実行装置
技術分野
[0001] 本発明は、プログラムの盗聴および改竄を防止する技術に関し、特に、プログラム 実行時に、プログラムが解析、改竄等されることを防止する技術に関する。
背景技術
[0002] 近年、様々なアプリケーション.プログラム（以下、「アプリケーション」という。）が、パ ソコンをはじめ、デジタルテレビや携帯電話機などの情報処理機能を有した装置で 実行されており、これらのアプリケーションは、例えば、プログラム配信サービスにより インターネット上のサーバからダウンロードされる。
これらのアプリケーションには、著作権等の知的財産権の他、さまざまな権利が発 生している。
[0003] その一方で、アプリケーションが改竄されたり、データが盗まれたりという行為が起こ つており、このような行為は、アプリケーションに発生している権利の観点から許される べきものではない。
このような不正行為力もアプリケーションを守るために、従来からさまざまな方法が 取られており、その一つとして、アプリケーションのプログラム自体を複雑にする方法 がある。
[0004] 通常、プログラムの改竄等を行う場合には、例えば、デバッガなどのツールを用い てメモリ上の実行中のプログラムを解析し、不正行為を行う。そこで、プログラムを複 雑にして解析を困難にすることでプログラム自体を保護しょうとするのである。
アプリケーションのプログラム自体を複雑にする方法として、実行時にメモリに配置 されるプログラム内のデータと演算式とを、それぞれ複雑化してメモリに配置する方法 が開示されている (特許文献 1及び図 29参照)。
[0005] 具体的には、この方法を実現する CPU (Central Processing Unit) 200は、符号化 プログラム内のデータのうちデータ決定部 202が決定したデータを、符号化規則決 定部 201が決定した方法を用いてデータ符号ィ匕部 203で符号ィ匕し、そのデータを使 用する演算式を演算式変換部 204で複雑ィ匕したものをメモリに配置する。復号化が 必要なデータは、復号化処理部 205が復号化を行う。
[0006] この方法によれば、メモリ上のプログラム、すなわち、実行中のプログラムのデータ やアルゴリズムを解読しに《することが可能となる。
特許文献 1 :特開 2005— 49925号公報
発明の開示
発明が解決しょうとする課題
[0007] しかし、プログラム自体の複雑化は、解析を困難にすることは可能ではある力 時間 さえかければ解析されてしまうという欠点がある。また、コピーが可能であれば、プロ グラム自体が複雑化されて!/ヽても実行には問題がな!、。
解析やコピー等をさせないためには、アプリケーションをその実行環境と共に、耐タ ンパ性を有するデバイス内のメモリに置いて実行させることが望ましいが、サイズ面、 コスト面など力も現実的ではな 、ことが多!、。
[0008] 特に、実行環境が仮想マシンであれば、そのプログラムは、通常、巨大なプログラム であることから尚更である。
そこで、本発明は、アプリケーションのプログラム自体を複雑にすることなぐまた、 大きな耐タンパ性を有するデバイスを必要とせずとも、アプリケーションのプログラム の重要な部分を、解析等の不正行為から防ぐことを可能とする実行装置の提供を目 的とする。
課題を解決するための手段
[0009] 上記課題を解決する為に、本発明の実行装置は、オブジェクト指向言語で作成さ れた、実行コードを含む 1以上のクラスを有するアプリケーションプログラムを実行する プログラム実行装置であって、それぞれメモリとプロセッサとを含む、第 1実行デバイ スと耐タンパ性を有する第 2実行デバイスと、前記クラスをロードする際に、当該クラス の実行コードを第 2実行デバイスのメモリにロードし、当該クラスの、第 2実行デバイス のメモリにロードした実行コード以外の部分を第 1実行デバイス内のメモリにロードす るローダとを備えることを特徴とする。 発明の効果
[0010] 本発明に係る実行装置は、上述の構成を備えることにより、アプリケーションのクラ スを実行している間、実行コードは耐タンパ性を有する実行デバイスのメモリにのみ口 ードされ、実行されるので、実行時にデバッガ等を用いて実行コード部分を解析、改 竄することが困難になり、アプリケーションを不正行為力 守ることができるようになる クラスのうち実行コード部分のみ力 耐タンパ性を有する実行デバイスのメモリに記 憶されるので、クラス全体を記憶する場合等に比べ、耐タンパ性を有する実行デバィ スは小さくなる。
[0011] また、前記クラスの実行コードは、暗号化されており、前記プログラム実行装置は、 更に、暗号化されている情報を復号化する復号化手段を備え、前記ローダは、暗号 化されている実行コードを、前記復号ィ匕手段に復号ィ匕させ、復号化された実行コード を第 2実行デバイスのメモリにロードすることとしてもよ!/、。
これにより、保護すべきクラスを暗号ィ匕できるので、アプリケーションをコピーしても 実行することはできず、実行時以外でも保護することができ、且つ、実行時は耐タン パ性を有する実行部で実行してアプリケーションを保護することができるようになる。
[0012] また、前記クラスは、暗号化されており、前記第 1実行デバイスは、更に、クラスが暗 号化されて ヽるカゝ否かを判断する判断する判断手段を備え、前記第 2実行デバイス は、更に、自デバイス内のメモリに記憶する暗号ィ匕されているクラスを復号ィ匕する復 号化手段を備え、前記ローダは、前記第 1実行デバイスのプロセッサにより実行され る第 1ローダと、前記第 2実行デバイスのプロセッサにより実行される第 2ローダとで構 成され、前記第 1ローダは、前記判断手段にクラスが暗号化されているか否かを判断 させ、暗号ィ匕されていないと判断されたクラスは、第 1デバイス内のメモリにロードし、 暗号ィ匕されていると判断されたクラスは、第 2実行デバイスのメモリに記憶させ、前記 第 2ローダは、第 2実行デバイスのメモリに記憶された暗号ィ匕されているクラスを前記 復号ィ匕手段に復号化させ、得られた復号化されたクラスの実行コードを第 2実行デバ イスのメモリにロードし、当該復号化されたクラスの、第 2実行デバイスのメモリにロー ドした実行コード以外の部分を、当該実行コードと対応付けて第 1デバイス内のメモリ にロードすることとしてもょ 、。
[0013] これにより、クラスが暗号ィ匕されている力否かを判断でき、暗号ィ匕されているクラスを 実行する際に、復号ィ匕を耐タンパ性を有する実行デバイス内で行い、保護を要しな V、部分のみを耐タンパ性を有する実行デバイス外のメモリ〖こロードすることができるの で、保護すべき実行コードを実行する前も実行中も保護することができるようになる。 クラスが暗号ィ匕されているカゝ否かを判断する方法としては、例えば、暗号ィ匕されてい るクラスのクラス名リストを予め作成しておき、そのリストを元に判断する。
[0014] また、前記プログラム実行装置は、更に、クラスの実行を制御する制御手段を備え、 前記制御手段は、第 1デバイスのメモリに記憶されているクラスを第 1デバイスのプロ セッサに実行させ、当該クラスの実行コードが第 1デバイスのメモリに記録されていな い場合には、第 2デバイスのメモリに記憶されている対応する実行コードを第 2デバイ スのプロセッサに実行させることとしてもよい。
[0015] これ〖こより、 1つのクラスを分割し、通常の実行デバイスのメモリと耐タンパ性を有す る実行デバイスのメモリとに対応付けて記憶することができるので、 1つのクラスを、通 常の実行デバイスと耐タンパ性を有する実行デバイスとで分担して実行することがで きるようになる。従って、クラス内の保護すべき実行コードのみを、耐タンパ性を有す る実行デバイスのメモリに記憶しておき、実行することができるようになる。
[0016] 本発明の実行デバイスは、オブジェクト指向言語で作成された、実行コードを含む 1 以上のクラスを有するアプリケーションプログラムを実行するプログラム実行装置に備 えられた耐タンパ性を有する実行デバイスであって、メモリと、プロセッサと、前記メモ リに記憶する暗号ィ匕されているクラスを復号ィ匕する復号ィ匕手段と、前記メモリに記憶 された暗号化されているクラスを前記復号ィ匕手段に復号化させ、得られた復号化さ れたクラスの実行コードを前記メモリにロードし、当該復号化されたクラスの、前記メモ リにロードした実行コード以外の部分を、当該実行コードと対応付けて自デバイス外 のメモリにロードするローダとを備えることを特徴とする。
[0017] また、本発明のコンピュータプログラムは、オブジェクト指向言語で作成された、実 行コードを含む 1以上のクラスを有するアプリケーションプログラムを実行するプロダラ ム実行装置に備えられた、メモリとプロセッサとを有する耐タンパ性を有する実行デバ イスに、ロード処理を行わせるためのコンピュータプログラムであって、前記メモリに記 憶する暗号化されているクラスを復号化する復号化ステップと、前記メモリに記憶され た暗号ィ匕されて ヽるクラスを前記復号化ステップで復号ィ匕し、得られた復号化された クラスの実行コードを前記メモリにロードし、当該復号化されたクラスの、前記メモリに ロードした実行コード以外の部分を、当該実行コードと対応付けて自デバイス外のメ モリにロードするステップとを備えることを特徴とする。
[0018] また、本発明の集積回路は、オブジェ外指向言語で作成された、実行コードを含 む 1以上のクラスを有するアプリケーションプログラムを実行するプログラム実行装置 に備えられた耐タンパ性を有する集積回路であって、メモリと、プロセッサと、前記メモ リに記憶する暗号ィ匕されているクラスを復号ィ匕する復号ィ匕手段と、前記メモリに記憶 された暗号化されているクラスを前記復号ィ匕手段に復号化させ、得られた復号化さ れたクラスの実行コードを前記メモリにロードし、当該復号化されたクラスの、前記メモ リにロードした実行コード以外の部分を、当該実行コードと対応付けて自デバイス外 のメモリにロードするローダとを備えることを特徴とする集積回路。
[0019] これにより、大きな耐タンパ性を有するデバイスを必要とせずとも、アプリケーション の改竄等の不正行為を防ぐことを可能とする実行装置を容易に提供することができる ようになる。
図面の簡単な説明
[0020] [図 1]本発明にかかる実行装置のハードウェア及びソフトウェアの構成を表す図であ る。
[図 2]第 1ROM1920が記憶するプログラムの例を示す図である。
[図 3]第 2ROM2920が記憶するデータ及びプログラムの例を示す図である。
[0021]
[図 4]本発明にかかる実行装置の構成を示す機能ブロック図である。
[図 5]アプリケーションプログラム 1210の構成例を示す図である。
[図 6]保護対象クラス一覧 1220の構成例及び内容例を示す図である。
[図 7]クラスファイルの構成例を示す図である。
[図 8]仮想マシン 1100のサブプログラムの構成を示す図である。 [図 9]バイトコード処理部のサブプログラムの構成を示す図である。
[図 10]実行装置 100の起動処理を表すフローチャートである。
[図 11]実行装置 100のロード処理を表すフローチャートである。
圆 12]保護対象クラスのクラスファイルがロードされた状態を示す図である。
[図 13]実行装置 100のクラスの実行処理を表すフローチャートである。
[図 14]実行装置 100のバイトコードの実行処理を表すフローチャートを示す。
[図 15 ava (登録商標）言語のメソッドの例を示す図である。
[図 16]メソッド 4000をコンパイルし、得られたバイトコード 4100を示す図である。
[図 17 ava (登録商標）フレームを積み上げた時点での、ワーク領域 1400の状態の 例を示す図である。
[図 18]iadd命令を実行後の、ワーク領域 1400の状態の例を示す図である。
[図 19]newarray命令を実行後の、ワーク領域 1400の状態の例を示す図である。
[図 20]areturn命令を実行後の、ワーク領域 1400の状態の例を示す図である。
[図 21]実施形態 2の実行装置 500の構成例を示す機能ブロック図である。
[図 22]実行装置 500のロード処理を表すフローチャートである。
圆 23]保護対象クラスのクラスファイルがロードされた状態を示す図である。
[図 24]バイトコードの例を示す図である。
[図 25]分割したバイトコードの例を示す図である。
[図 26]実施形態 2の実行装置 500のクラスの実行処理を表すフローチャートである。 圆 27]実施形態 3の実行装置 800の構成例を示す図である。
[図 28]実施形態 3の実行装置 800のクラスの実行処理を表すフローチャートである。
[図 29]従来技術の構成を表す図である。
符号の説明
100 500 実行装置
1000 5000 通常実行部
1010 アプリ取得プログラム
1200 アプリケーションプログラム記憶部
1210 アプリケーションプログラム 1100 5100 仮想マシン
1110 5110 インタプリタ
1120 5120 ローダ
1020 8100 OS
1300 クラス記憶部
1330 メソッド'のメタ†青報
1331 バイトコード分割フラグ
1332 2611 ID
1400 6700 ワーク領域
1900 第 1CPU
1910 第 1RAM
1920 第 2ROM
2000 6000 8000 保護実行部
2100 6100 復号処理部
2200 6200 バイトコード処理部
2210 6210 セキュアインタプリタ
2220 6220 セキュアローダ
2600 バイトコード記憶部
2610 バイ卜コ^ ~"ド、
2900 第 2CPU
2910 第 2RAM
2920 第 2ROM
発明を実施するための最良の形態
<概要 >
本発明に係る実行装置は、アプリケーションのプログラムのうち、一部のプログラム を不正行為力 守ることで、アプリケーション自体を効率よく守ることができる場合が 多いことに着目したものである。
アプリケーションはそれぞれ、その用途 ·目的が異なることから、アプリケーション毎 に解析、改竄等されたくないプログラム、すなわち、秘匿性を有するプログラムが異な る。
[0024] 例えば、コピー回数を管理する等の著作権管理機能の処理や、課金機能の処理な どを行うプログラムを解析、改竄から守り、これらの機能が無効とされることを防ぐこと で、アプリケーションの著作権を守ることが可能となる。
本発明は、アプリケーションを不正行為から守る為の要となる処理のプログラムのみ を、耐タンパ性を有する実行装置内で実行することで、アプリケーション自体を守ろう とするものである。もちろん、キーとなる処理はアプリケーション全てであってもかまわ ない。
[0025] 本発明は、このキーとなる処理のプログラムのうち、実行コードのみを耐タンパ性を 有する実行装置内で実行することで、プログラムの解析を困難にするものである。 また、アプリケーションのうちのキーとなる処理は、作成者またはそのユーザのみが 知り得るものであるので、本発明に係る実行装置は、アプリケーション実行中にキーと なる処理のプログラムを判別できる機能を有する。
[0026] 以下、本発明の実施形態に係る実行装置について説明する。
本実施形態では、 Java (登録商標)仮想マシン上で動く Java (登録商標)アプリケー シヨンについて説明する。
尚、本発明に係る実行装置とは、具体的にはデジタルテレビ、セットトップボックス、 カーナビ端末、携帯電話機、 PDA (Personal Digital Assistants)などの、 Java (登録 商標)仮想マシンを搭載する電子機器全般が該当するものである。
<実施形態 1 >
<構成>
まず、図 1〜図 3を用いて、本発明の実行装置の、ハードウェア及びソフトウェアの 構成について簡単に説明し、機能ブロックの構成について説明する。
[0027] <ハードウェア及びソフトウェアの構成 >
図 1は、本発明に力かる実行装置のハードウェア及びソフトウェアの構成を表す図 である。
実行装置 100は、通常実行部 1000と保護実行部 2000で構成される。 通常実行部 1000は、特別な保護がなされていない実行部であり、通常のパーソナ ルコンピュータやデジタル家電機器等に搭載されているプログラム実行手段と同様の ものである。一方、保護実行部 2000は、耐タンパ性を有する実行部であり、不正な ユーザによる盗聴、改竄等を防止し、安全にプログラムを実行させることができるもの である。
[0028] ハードウエア構成 110として、通常実行部 1000と保護実行部 2000とは、それぞれ CPUとメモリを備える。具体的には、通常実行部 1000は、第 1CPU1900、第 IRA M (Random Access Memory) 1910及び第 IROM (Read Only Memory) 1920を備え 、保護実行部 2000は、第 2CPU2900、第 2RAM2910及び第 2ROM2920を備え る。
[0029] 本実施形態では、第 1RAMは、第 2CPU2900からもアクセスが可能であるとする 各 RAM (1910、 2910)は、具体的には SRAM、 DRAM等の一次記憶メモリで構 成され、各 CPU (1900、 2900)が処理を行う際、一時的にデータを保存するために 使用される。
[0030] また、各 ROM (1920、 2920)は、具体的にはフラッシュメモリやハードディスク等の 読み出し専用の不揮発性メモリで構成される。第 1ROM1920及び第 2ROM2920 には、それぞれ通常実行部 1000と保護実行部 2000で起動される各処理部のプロ グラム等が記憶されている。
次に、ソフトウェア構成として、通常実行部 1000は、基本ソフトウェアである OS (Op erating System) 1020、 Java (登録商標）仮想マシン 1100、本実行装置 100で実行 するアプリケーションプログラム 1210及び実行装置 100の外部力もアプリケーション プログラム 1210をダウンロードする機能を有するアプリ取得プログラム 1010とで構成 される。
[0031] Java (登録商標)仮想マシン 1100 (以下、「仮想マシン」という。 )は、 Java (登録商 標)言語で記述されたプログラムを逐次解析し実行する Java (登録商標)バーチャル マシンである。言い換えれば、ソフトウェアプログラムである仮想マシン 1100力 仮想 の CPUをシミュレートして、 Java (登録商標）の命令コードを解析実行する。 OS 1020は、他のサブプログラムを平行して実行するカーネル及び、ライブラリで構 成される技術の総称であり、 Linux等があげられる。 OS 1020は、 Java (登録商標） 仮想マシン 1100をサブプログラムとして実行する。
[0032] 保護実行部 2000は、保護実行部 2000でのアプリケーションの実行を制御するバ イトコード処理部 2200と、暗号化されたプログラムを復号化する機能を有する復号処 理部 2100とで構成される。
図 2は、第 1ROM1920が記憶するプログラムの例を示す図である。
第 1ROM1920には、通常実行部 1000のメモリにロードされるプログラムである OS
1921、仮想マシン 1922及びアプリ取得プログラム 1923の各プログラムが記憶され ている。
[0033] また、図 3は、第 2ROM2920が記憶するデータ及びプログラムの例を示す図であ る。
第 2ROM2920には、保護実行部 2000のメモリにロードされるプログラムであるバ イトコード処理部 2921と復号処理部 2922の各プログラム、及び復号化鍵 2923が記 憶されている。復号ィ匕鍵 2923は、復号処理部 2100が、暗号ィ匕されているアプリケ ーシヨンプログラム 1210を復号するために用 、るものである。
[0034] 尚、実行装置 100は、本発明にかかる構成の他、本来の機能を実行するためのハ 一ドウエアやソフトウェア、例えば、テレビであれば放送の受信装置など、で構成され ている。
く機能ブロックの構成 >
図 4は、本発明にかかる実行装置の構成を示す機能ブロック図である。
[0035] 本図にお 、て、実線矢印はデータの流れを表し、点線矢印は制御の遷移を表す。
また、細線はクラスをロードするときのデータの流れ等を表し、太線はクラスを実行す るときのデータの流れ等を表す。尚、本図では、暗号ィ匕されているクラスファイルの実 行の際のデータの流れ等のみを表して 、る。図 21も同様である。
実行装置 100は、図 1で示したように、通常実行部 1000と保護実行部 2000とで構 成される。ここでは、実施形態の説明に直接関係する機能部のみを記載している。
[0036] まず、通常実行部 1000から説明する。 <通常実行部 >
通常実行部 1000は、アプリケーション記憶部 1200、仮想マシン 1100、クラス記憶 部 1300、ワーク領域 1400及び第 1CPUとを備える。
<アプリケーション記憶部 >
アプリケーション記憶部 1200は、アプリケーションプログラム 1210を記憶する機能 を有し、本実施形態では、アプリ取得プログラム 1010 (図 1参照）がアプリケーション プログラム 1210を読み込んだ状態力 説明する。
[0037] このアプリケーション記憶部 1200は、第 1RAM1010に確保される。
ここで、アプリケーションプログラムの構成について説明する。
図 5は、アプリケーションプログラム 1210の構成例を示す図である。
アプリケーションプログラム 1210は、複数のクラスファイル（1211等)及び保護対象 クラス一覧 1220から構成される。
[0038] クラスファイルには、暗号化されたクラスファイルと暗号化されていない平文のクラス ファイルとが含まれる。暗号ィ匕されているクラスは、秘匿性を有する処理を行うクラス である。
クラスファイルが暗号ィ匕されているカゝ否かは、保護対象クラス一覧 1220を参照して 判断する。
[0039] 図 6は、保護対象クラス一覧 1220の構成例及び内容例を示す図である。
保護対象クラス一覧 1220は、暗号化されたクラスファイルの識別子の一覧であり、 本実施形態では、クラス名を識別子とする。このクラス名は、後述するクラス毎のコン スタントプールに記憶されて 、る。
例えば、アプリケーションプログラム 1210を構成する「クラスファイル 001」、「クラス ファイル 002」等のうち、 「クラスファイル 001」、 「クラスファイル 003」、 「クラスファイル 021」力 暗号化されていることになる。
[0040] 次に、クラスファイルの構成を、図 7を用いて説明する。
図 7は、クラスファイルの構成例を示す図である。
クラスファイル 3000は、クラス構造情報 3100、コンスタントプール 3200、 0個以上 のメソッドのメタ情報 3300及び 0個以上のバイトコード 3400で構成される。クラスファ ィルには、他の情報が含まれていても良いが、ここでは本発明に関連のある項目の み説明する。
[0041] クラス構造情報 3100は、このクラスが保持するフィールドやメソッド、どのクラスを継 承する力など、クラスの構造に関する情報である。
コンスタントプール 3200は、このクラスで定義している、またはこのクラス力も参照し て 、る他クラスのフィールド、メソッドの名前などの情報である。
メソッドのメタ情報 3300は、各メソッドのアクセスフラグや、引数のサイズなどメソッド に関する情報である。
[0042] バイトコード 3400は、そのクラスにおいて実行される処理を記述している。
Java (登録商標）言語で記述されたソースプログラムは、バイトコードコンパイラによつ てバイトコードに変換される。このバイトコードとは、ハードウェアに依存しない中間コ ードである。
メソッドのメタ情報 3300とバイトコード 3400は、クラスに属するメソッドに 1対 1に対 応して存在している。すなわち、メソッドの数と同数の、メソッドのメタ情報 3300及び バイトコード 3400がクラスファイルに含まれている。
[0043] 以下では、クラス構造情報 3100、コンスタントプール 3200及びメソッドのメタ情報 3 300を総称して「メタ情報」と!、うものとする。
<仮想マシン >
仮想マシン 1100は、複数のサブプログラムで構成される力 本図では、本発明に 特有の機能を有するローダ 1120とインタプリタ 1110のみを記載してある。
[0044] まず、図 8を用いて、仮想マシン 1100について説明する。
図 8は、仮想マシン 1100のサブプログラムの構成を示す図である。
仮想マシン 1100は、インタプリタ 1110、 P—ダ 1120、ベリファイャ 1130、 Java (登 録商標）ヒープ管理部 1140、 Java (登録商標)ネイティブライブラリ 1150、 JITコンパ イラ 1160及びクラスライブラリ 1170で構成される。
[0045] インタプリタ 1110は、クラスファイルに含まれるバイトコードを解釈、実行する機能を 有するサブプログラムで、仮想マシン 1100にお!/、て中核な処理を行うサブプロダラ ムである。 本発明のインタプリタ 1110は、カロえて、クラスの実行時に、実行すべきバイトコード 力 保護実行部に記憶されていることを検出し、制御を渡す機能を有する。
[0046] ローダ 1120は、実行するクラスのクラスファイルをアプリケーションプログラム 1210 から探し出し、見つけたクラスファイルを仮想マシン 1100内部へロードする機能を有 する。この際、クラスを実行可能な状態にしてロードする。
本発明のローダ 1120は、加えて、ロードしょうとするクラス力 暗号化されているか 否かを判定し、暗号ィ匕されている場合には、ロードを保護実行部 2000に依頼する機 能を有する。
[0047] また、クラスローダ 1120は、クラスアンロード処理を行う機能を有する。クラスアン口 ード処理とは、実行が終了し不要になったクラスを仮想マシン 1100から取り除く処理 である。
次に、ベリファイャ 1130は、クラスのデータ形式の不備や、クラスに含まれるノイト コードの安全性を検査する機能を有する（Java (登録商標） Virtual Machine Specificat ion参照）。クラスローダ 1120は、ベリファイャ 1130において妥当ではないと判定され たクラスはロードを行わな！/、。
[0048] Java (登録商標）ヒープ管理部 1140は、 Java (登録商標）ヒープと呼ばれる、 Java ( 登録商標)アプリケーションが使用するワーキングメモリの管理を行う機能を有する。 このワーキングメモリは第 1RAM1910に確保される。
また、 Java (登録商標）ヒープ管理部 1140は、ガベージコレクションも行う機能を有 する。ガベージコレクションとは、アプリケーション実行において不要になったヮーキ ングメモリを開放し、他の用途に再利用できるようにする処理である。
[0049] Java (登録商標)ネイティブライブラリ 1150は、 Java (登録商標）アプリケーションか ら呼出されるライブラリで、 OS 1020や、実行装置 100が備える図 1には記載されて Vヽな 、ノヽ一ドウエア、サブプログラム等で提供される機能をアプリケーションへ提供す る。
JITコンパイラ 1160は、バイトコードを第 1CPU1900もしくは第 2CPU2900が理 解可能な実行形式に翻訳する機能を有する。
[0050] クラスライブラリ 1170は、仮想マシン 1100の実行に必要なクラスで構成され、仮想 マシン 1100が実行時に最初にロードするクラスである。クラスライブラリ 1170は仮想 マシン 1100の一部であり、一般に公開されている、クラスの集合である。
<クラス記憶部 >
クラス記憶部 1300は、実行するアプリケーションプログラムのクラスを記憶する機能 を有する。
[0051] このクラス記憶部 1300は、いわゆるメソッド領域であり、実際には、仮想マシン 110 0内の領域であり、ローダ 1120が実行可能な状態にしたクラスをロードする。
このクラス記憶部 1300には、仮想マシン 1100のローダ 1120又はバイトコード部 2 200の後述するセキュアローダ 2220力ら、クラスがロードされる。
尚、このクラス記憶部 1300は、第 1RAM1910に確保され、保護実行部 2000から 参照等が可能である。
[0052] <ワーク領域 >
ワーク領域 1400は、クラスの実行に際し、使用される作業領域である。具体的には 、スタックやヒープ等をいい、実際には、仮想マシン 1100内の領域である。
尚、このワーク領域 1400は、第 1RAM1910に確保され、保護実行部 2000から参 照等が可能である。
[0053] <保護実行部 >
次に、保護実行部 2000について説明する。
保護実行部 2000は、復号処理部 2100、復号ィ匕クラス記憶部 2400、暗号鍵記憶 ^2500, ノ ィ卜 =3一ド、; ¾i § 2200、 ノ ィ卜 =fード、言己'隐§^2600¾_び 2GPU2900を 備える。
[0054] <復号処理部 >
復号処理部 2100は、ローダ 1120からの依頼によって、アプリケーション記憶部 12
00内の暗号ィ匕されたクラスを読み込み、暗号鍵記憶部 2500に記憶されている暗号 化鍵 2923 (図 3参照）を用いて復号ィ匕し、復号化されたクラスを復号化クラス記憶部
2400に記憶させる機能を有する。
[0055] 復号化するクラスのアプリケーション記憶部 1200内のアドレスとサイズは、ローダ 1
120からの依頼と共に渡される。 尚、暗号化のためのアルゴリズムは任意の暗号アルゴリズムを用いることが可能で あり、代表的な暗号アルゴリズムとしては、 AES (Advanced Encryption Standard)、 D ES (Data Encryption Standard)等があげられる。
[0056] <バイトコード処理部 >
次に、バイトコード処理部について説明する。
バイトコード処理部 2200は、仮想マシン 1100の機能のうち、バイトコードの実行に 必要な機能のみを備えたものであり、複数のサブプログラムを備えるが、ここでは、本 図では、本発明に特有の機能を有するセキュアインタプリタ 2210とセキュアローダ 2 220のみを記載する。
[0057] 図 9は、バイトコード処理部のサブプログラムの構成を示す図である。
バイトコード処理部 2200は、セキュアインタプリタ 2210、セキュアローダ 2220、セ キュアべリファイャ 2230、セキュア Java (登録商標）ヒープ管理部 2240、バイトコード 管理部 2250で構成される。
セキュアインタプリタ 2210は、仮想マシン 1100のインタプリタ 1110と同様の機能を 有し、仮想マシン 1100のインタプリタ 1110から依頼を受けてバイトコードを実行し、 実行が終了すればインタプリタ 1110に通知する機能を有する。
[0058] また、セキュアローダ 1110は、暗号化クラス記憶部 2400のクラスファイルをロード する機能を有する。 自実行部のバイトコード記憶部 2600と、通常実行部 1000のクラ ス記憶部 1300とに、ひとつのクラスを分割してロードする。
この際、自実行部のバイトコード記憶部 2600に記憶した部分と、通常実行部 1000 のクラス記憶部 1300に記憶した部分とを対応付けて記憶する。対応付けの方法は、 図 12を用いて後で説明する。
[0059] セキュアべリファイャ 2230は、仮想マシン 1100のべリファイャ 1130と同様の機能 を有する。
セキュア Java (登録商標）ヒープ管理部 2240は、仮想マシン 1 lOOJava (登録商標 )ヒープ管理部 1140の機能のうち、クラスアンロード時にバイトコードをアンロードする 機能のみを有する。ノイトコード以外は、通常実行部 1000のメモリに存在し、それら の管理は仮想マシン 1100が行うからである。 [0060] バイトコード管理部 2250は、保護実行部 2000におけるクラスの実行の際に、通常 実行部 1000内に記憶されている実行に必要なメタ情報とを関連付けて管理しておく 機能を有する。具体的には、バイトコード記憶部 2600に記憶されるノイトコードとクラ ス記憶部 1300に記憶されるメソッドのメタ情報とに、同じ識別子をつけて、 1対 1に対 応付けて管理する（図 12参照)。
[0061] <バイトコード記憶部 >
ノイトコード記憶部 2600は、実行するアプリケーションプログラムのクラスのうち、バ イトコード（図 7参照)のみを記憶する機能を有する。
このバイトコード記憶部 2600は、いわゆるメソッド領域であり、実際には、ノイトコ一 ド処理部 2200内の領域であり、セキュアローダ 2220がロードし、実行可能な状態に したクラスのバイトコードを記憶する。
[0062] 尚、このバイトコード記憶部 2600は、第 2RAM2910に確保される。従って、このバ イトコード記憶部 2600は、通常実行部 1000から参照されることはない。
<動作 >
次に、アプリケーションを実行する実行装置 100の動作を説明する。
実行装置の動作の説明として、アプリケーションのロードと実行の 2つのフェーズに 分けて説明する。
[0063] 以下、本発明に係る実行装置 100のクラスのロード処理について図 10〜図 12を用 V、て、クラスの実行処理にっ 、て図 13〜図 20を用いて説明する。
<クラスのロード処理 >
まず、図 10を用いて、クラスのロード処理、具体的には、電源投入力も実行装置 10 0がアプリケーションプログラム 1210を起動するまでの処理を説明し、その後、図 11 と図 12とを用いてクラスをロードする処理にっ 、て説明する。
[0064] 本実施形態では、実行装置の電源を入れた場合、予め定められているアプリケー シヨンが実行されるものとする。
図 10は、実行装置 100の起動処理を表すフローチャートである。
ユーザが実行装置 100の電源を投入する（ステップ S100)と、第 1CPU1900が、 第 1ROM1920に保存されている OS1921 (図 2参照）を第 1RAM1910にロードし 、 OS 1020を起動する（ステップ SI 10)。
[0065] 次に、 OS1020力 第 1ROM1920に保存されている Java (登録商標）仮想マシン 1922を第 1RAM 1910にロードし、仮想マシン 1100を起動する（ステップ S 120)。 続!ヽて、 OS1020iま、第 1CPU1900を介して、第 2CPU2900【こロード依頼を通 知し、第 2CPU2900は、第 2ROM2900上に保存されているバイトコード処理部 29 21を第 2RAM2910にロードし、バイトコード処理部 2200を起動する（ステップ S13 0)。
[0066] 次【こ、第 2CPU2900iま、第 2ROM2900上【こ保存されて!ヽる復号処理咅 2922 ( 図 3参照）を第 2RAM2910にロードし、復号処理部 2100を起動する（ステップ S14 0)。
上記の処理により、実行装置 100がアプリケーション実行可能な状態になる。尚、 仮想マシン 1100の起動（ステップ S120)と復号処理部 2100及びバイトコード処理 部 2200の起動（ステップ S130、 S140)の順番は逆になつていてもかまわない。
[0067] 実行装置 100が、アプリケーションプログラム 1210を実行可能な状態になった後、 仮想マシン 1100は、アプリケーションプログラム 1210の実行を開始する。
アプリケーションプログラム 1210の開始は、アプリケーションプログラム 1210の特 定のクラスファイルを実行することで行う。この特定のクラスファイル名は、予め、仮想 マシン 1100が記憶して!/、るものとする。
[0068] この最初のクラスがローダ 1120によってロードされ、インタプリタ 1110によって実行 が開始され、その後、適時必要なクラスファイルがアプリケーション記憶部 1200から ロードされ、実行されることで、アプリケーションが実行されていくことになる。
仮想マシン 1100は、最初に特定のクラスファイルをロード (ステップ S160)する前 に、この特定のクラスファイルと共にアプリケーションプログラム 1210の中含まれてい る保護対象クラス一覧 1220をクラス記憶部 1300に記憶させる (ステップ S 150)。
[0069] 次に、各クラスをロードする処理、すなわち、アプリケーションプログラム 1210のクラ スファイルを仮想マシン 1100が実行可能な内部形式に変換し、ロードする手順につ いて説明する。
図 11は、実行装置 100のロード処理を表すフローチャートである。この ロード処理 は、通常実行咅 1000のローダ 1120と保護実行咅 2000のセキュアローダ 2220力 S 行う処理である。
[0070] また、図 12は、保護対象クラスのクラスファイルがロードされた状態を示す図である まず、インタプリタ 1110がローダ 1120に、クラスファイル名を渡してロードを依頼す る。
依頼を受けたローダ 1120は、渡されたクラスファイル名のクラス力 保護対象のクラ スカ すなわち、暗号ィ匕されたクラス力否かを判断する（ステップ S200)。
[0071] 判断の方法は、クラス記憶部 1300の保護対象クラス一覧 1220のリストに渡された クラスファイル名が載って ヽるかをチェックし、載って 、れば保護対象のクラスであると 判断する。
ローダ 1120は、ロードの依頼を受けたクラスが、保護対象クラスでないと判断した 場合は（ステップ S200 :NO)、クラス記憶部 1300にロードする（ステップ S260)。
[0072] 一方、ロードの依頼を受けたクラスが、保護対象クラスであると判断した場合は (ステ ップ S200 : YES)、ロードするクラスのアプリケーション記憶部 1200でのアドレスとサ ィズとを、保護実行部 2000の復号処理部 2100に通知し、ロードを依頼する (ステツ プ S210)。
通知を受けた復号処理部 2100は、クラスファイルをアプリケーション記憶部 1200 から読み込み、暗号鍵記憶部 2500に記憶されている復号ィ匕鍵 2923を用いて復号 化し、復号ィ匕クラス記憶部 2400に記憶する (ステップ S220)。以下、復号化クラス記 憶部 2400に記憶されたクラスを、「復号ィ匕クラスファイル」というものとする。
[0073] 復号ィ匕クラスファイルを作成した復号処理部 2100は、その旨バイトコード処理部 22 00に通知する。
通知を受けたバイトコード処理部 2200は、セキュアべリファイャ 2230に復号化クラ スファイルを検査させ、セキュアローダ 2220にロードを依頼する。
ロードの依頼を受けたセキュアローダ 2220は、復号ィ匕クラスファイルの構文を分析 し、復号ィ匕クラスファイルのタグから、バイトコードの部分とメタ情報の部分の判別を行 い、バイトコードの部分とメタ情報の部分とに分割する (ステップ S230)。この分割の 際、セキュアローダ 2220は、 2つの情報を付加する。 1つ目は、バイトコードが分割さ れた旨の情報であり、 2つ目は、バイトコードの部分とメタ情報の部分とを対応付ける ための情報である。これら付加する情報については、図 12を用いて後で説明する。
[0074] 分割後、セキュアローダ 2220は、バイトコードの部分をバイトコード記憶部 2600に ロードし (ステップ S240)、メタ情報の部分を通常実行部 1000のクラス記憶部 1300 にロードする (ステップ S250)。この際、それぞれの部分は、仮想マシン 1100が実行 可能な形式となっている。
それぞれ記憶部にロードされた状態を図 12に示す。保護実行部 2000のバイトコ一 ド記憶部 2600には、バイトコード 2610がロードされ、通常実行部 1000のクラス記憶 部 1300には、クラス構造情報 1310、コンスタントプール 1320及びメソッドのメタ情報 1330力 —ド、されて!/ヽる。
[0075] クラスファイルのフォーマット（Java (登録商標） Virtual Machine Specification参照）に おいて、メソッドのメタ情報 3300の次に必ずバイトコード 3400があることが保証され ているため（図 7参照）、各部分の判別は容易に行うことが可能であり、バイトコード 34 00の部分とメタ情報（図 7参照： 3100、 3200、 3300)の部分とを分割することができ る。
[0076] この分割の際（図 11 :ステップ S230参照）、セキュアローダ 2220は、バイトコードが 分割された旨の情報と、バイトコードの部分とメタ情報の部分とを対応付けるための情 報とを付加する。
ノイトコードが分割された旨の情報として、分割されたことを示すフラグであるバイト コード分割フラグ 1331をメソッドのメタ情報 1330に付加する。本実施形態では、バイ トコード分割フラグ 1331が「1」の場合は、分割してあり、「0」の場合は、分割していな いことを表すものとする。
[0077] すなわち、バイトコード分割フラグ 1331が「0」の場合は、バイトコードがクラス記憶 部 1300に記憶されていることを示し、バイトコード分割フラグ 1331が「1」の場合には 、 ノイトコードがバイトコード記憶部 2600に記憶されていることを示す。
次に、セキュアローダ 2220は、バイトコードの部分とメタ情報の部分とを対応付ける ための情報を付加する。この情報は、バイトコード管理部 2250に指示して付加する。 [0078] バイトコード管理部 2250は、バイトコード 2610とメソッドのメタ情報 1330の関係を 特定できるように、ノイトコード 2610に ID2611を、メソッドのメタ情報 1330に ID133 2を付加し、同じ値に IDをつけて管理する。同一のメソッドから内部形式に変換され たメソッドのメタ情報 1330の ID1332とバイトコード 2610の ID2611には同じ値がつ いている必要がある。
[0079] 例えば、バイトコード 2610の ID2611として「1234」を、メソッドのメタ情報 1330の I D1332IDとして「1234」を設定することで、バイトコードを実行する際には、同じ IDを 持つとメソッドのメタ情報 1330を参照すればよいことが分かる。従って、 IDの値は、メ ソッドのメタ情報 1330毎に異なる必要がある。
一方、保護対象クラスではないと判断され (ステップ S200 : NO)、クラス記憶部 130 0にロードされたクラスでは、ローダ 1120は、メソッドのメタ情報のバイトコード分割フ ラグ 1331には、「0」を設定する。なお、メソッドのメタ情報 1330の ID1332には、何も 設定しない。
[0080] セキュアべリファイャ 2230力 復号化クラスファイルを検査し、検査の結果がエラー の場合には、ローダ 1120にその旨を通知し、ロードの処理を終了する。
<クラスの実行処理 >
次に、図 13〜図 20を用いて、クラスの実行の処理について説明する。
図 13は、クラスの実行の処理を表すフローチャートである。
[0081] まず、クラスを実行するにあたり、インタプリタ 1110はメソッドを呼出す (ステップ S30 0)。
インタプリタ 1110は、該当するメソッドのバイトコードが分割されている力 すなわち 、 ノイトコードがクラス記憶部 1300に記憶されており通常実行部 1000で実行可能か 否かを判断する (ステップ S310)。
[0082] この判断は、メソッドのメタ情報 1330のバイトコード分割フラグ 1331をチェックする ことで行う。
ノイトコード分割フラグ 1331が「0」になっている場合 (ステップ S310 :NO)には、 分割がなされて ヽな 、ため、インタプリタ 1110がメソッドを実行する（ステップ S350) 。インタプリタ 1110がメソッドを実行する処理は従来の Java (登録商標)仮想マシンの 動作と同じである（Java (登録商標） Virtual Machine Specification参照）。
[0083] 次にバイトコード分割フラグ 1331が「1」になっている場合 (ステップ S310 : YES)に は、インタプリタ 1110は031020に用意された、保護実行部 2000のバイトコード処 理部 2200を呼出す実行環境遷移関数を呼び出し、バイトコードの実行を依頼する。 例えば、ノイトコード処理部 2200が定期的に第 1RAM1910上の特定ビットを監視 しており、実行環境遷移関数がこの特定ビットを「1」とすると、バイトコード処理部 220 0が処理を開始するような仕組みである。
[0084] この依頼の際、実行環境遷移関数の引数として、 ID1332 (図 12参照）の値を渡し て依頼する (ステップ S320)。
依頼を受けたバイトコード処理部 2200のセキュアインタプリタ 2210は、バイトコード 管理部 2250に、受け取った ID1332の値を渡して、同じ値の IDを持つバイトコード の検索を依頼する。
[0085] 依頼をうけたバイトコード管理部 2250は、バイトコード記憶部 2600から、同じ値の I
D2611を持つバイトコード 2610を検索し、バイトコードのアドレスをセキュアインタプ リタ 2210に返す (ステップ S330)。
バイトコードのアドレスを受け取ったセキュアインタプリタ 2210は、バイトコードの実 行を行う（ステップ S 340)。
[0086] この実行においては、セキュアインタプリタ 2210は、実行に必要なメタ情報はクラス 記憶部 1300を参照し、スタックの領域やヒープの領域は、ワーク領域 1400を使用す る。
次に、保護対象クラスのバイトコードが実行される場合を、具体例を用いて説明する 図 14に、バイトコードの実行処理を表すフローチャートを示す。このフローチャート は、図 15に示す、 Java (登録商標）言語のメソッド 4000を実行する場合のフローチヤ ートであり、以下、このメソッド 4000を実行する例を説明する。
[0087] このメソッド 4000は、保護対象クラス 1220のクラスファイルのメソッドであるとする。
従って、このメソッドのバイトコードは、ノイトコード記憶部 2600に記憶されている。図 16に、メソッド 4000をコンパイルし、得られたバイトコード 4100を示す。 メソッド 4000のプログラムは、引数に int型の 2つの値をとり、 2つの値を足し算した サイズの int型の配列を作成して、 int型の配列を返り値とするプログラムである。
[0088] このバイトコード 4100を実行する際の動作を図 14のフローチャートと、フレームの 領域とヒープの領域との遷移図、図 17〜図 20とを用いて説明する。
セキュアインタプリタ 2210はまず、通常実行部 1000のワーク領域 1400のフレーム 領域 1420にフレーム 1430を作成する。具体的には、呼出元の Java (登録商標）フレ ーム 1440の上に、いまから実行するメソッド 4000の Java (登録商標）フレーム 1430 を積み上げる (ステップ S700)。
[0089] 呼出元の Java (登録商標）フレーム 1440とは、 V、まから実行するメソッド 4000を呼 出したメソッドの Java (登録商標）フレームであり、各フレームは、同様の構成を有して いる。
図 17は、セキュアインタプリタ 2210がいまから実行する Java (登録商標）フレームを 積み上げた時点での、ワーク領域 1400の状態である。
[0090] ワーク領域 1400には、 Java (登録商標）ヒープ 1410、 Java (登録商標）フレーム 14 30、呼出 ¾[ava (登録商標）フレーム 1440が生成される。
Java (登録商標）ヒープ 1410は、仮想マシン 1100が利用するワーキングメモリであ り、 Java (登録商標）ヒープ管理部 1140 (図 8参照）が管理して 、る。
Java (登録商標）フレーム 1430は、セキュアインタプリタ 2210が!、まから実行するメ ソッドのワーキングメモリであり、ローカル変数領域 1450とオペランドスタック 1460と から構成される。
[0091] ローカル変数領域 1450とは、メソッドが持つローカル変数を保存する領域である。
セキュアインタプリタ 2210が Java (登録商標）フレーム 1430を作成したときに、引数 で与えられている int型の 2つの値「i」と「j」と力 ローカル変数領域の 1番目（1452)と 2番目（1451)にそれぞれロードされる。
オペランドスタック 1460とは、メソッドが実行する演算を行うスタックであり、例えば、 メソッドの中にローカル変数の足し算をするコードがあった場合、ローカル変数領域 1 450からデータをオペランドスタック 1460にロードし、足し算をオペランドスタック 146 0上で行い、ローカル変数領域 1450にストアする、といった使われ方をする。 [0092] 引数をフレームに積んだ、セキュアインタプリタ 2210は、バイトコード 4100の処理 を開始する。
バイトコード 4100の 1〜3行のコード 4101は、スタック演算であり、次のように処理 が進められる（ステップ S710)。
iload命令は、ローカル変数領域にある変数の値をオペランドスタックにロードする 命令である。また、 iadd命令はオペランドスタックに積まれた上から 2つの値を足し合 わせる命令である。
[0093] 「iload— 1」及び「iload— 2」で、オペランドスタック 1460に引数で渡された「i」 145 2の値と「j」 1451の値を積み、オペランドスタックに積まれた iの値と jの値の足し算を 行う。
足し算の結果「i+j」 1461をオペランドスタック 1460に置く。このとき、積まれていた 引数「i」と「j」は、削除される。
[0094] その結果のワーク領域 1400の状態を、図 18に示す。
次に、セキュアインタプリタ 2210は、バイトコード 4100のコード「newarray」 4102 を実行する。
newarray命令は、 Java (登録商標）ヒープ 1410に、オペランドスタックの一番上に ある値の数の要素数を持つ配列の領域を確保する命令である。領域を確保した状態 のワーク領域 1400の状態を、図 19に示す。
[0095] newarray命令では、 Java (登録商標）ヒープに他のスレッドからも同時のタイミング で書き込みを行われることを防ぐために、通常実行部 1000の OS 1020が提供する口 ック機能を利用して、領域を確保する前に、 Java (登録商標）ヒープのロックを獲得す る必要がある。
そこで、セキュアインタプリタ 2210は、直接には、通常実行部 1000の OS 1020が 提供するロック機能は利用することができないので、 「newarray」 4102をフェッチし た時点で、オペランドスタック 1460の一番上の値「i+j」 1461をオペランドスタック 14 60から取り出し（図 18参照）、この値を引数として、仮想マシン 1100の Java (登録商 標）ヒープ管理部 1140を呼出す (ステップ S720)。
[0096] Java (登録商標）ヒープ管理部 1140は、 OS 1020が提供するロック機能を利用して 、 Java (登録商標）ヒープ 1410のロックを獲得する。
ロックが獲得できたことを確認した後で、 Java (登録商標）ヒープ管理部 1140は、 Ja va (登録商標）ヒープ 1410に、引数として受け取った「i+j」のサイズを持つオブジェ タト 1 ( 1411 )を確保し (ステップ S 730)、オブジェクト 1への参照 1462をオペランドス タックに積む (ステップ S 740、図 19参照）。
[0097] この時点でのワーク領域 1400の状態力 図 19に示す図である。
領域の確保が終わると、処理をセキュアインタプリタ 2210に復帰させ、セキュアイン タプリタ 2210は、「newarray」4102の次の処理を開始する。
セキュアインタプリタ 2210は、バイトコード 4000の「areturn」4103の処理を行う。
[0098] セキュアインタプリタ 2210は、「areturn」 4103をフェッチした時点で、現在のメソッ ドの処理が終了したことを知り、メソッド 4000のワーキングメモリである Java (登録商標 )フレーム 1430を破棄し、呼出元の Java (登録商標）フレーム 1440上に、オペランド スタック 1460の一番上の値、オブジェクト 1への参照 1442を積む（ステップ S 750)。
[0099] その時点でのワーク領域 1400の状態を図 20に示す。
最後に、セキュアインタプリタ 2210は、処理をインタプリタ 1110に戻す。 これで、バイトコード 4100の実行が終了し、その次の処理を通常実行部 1000が続 けることになる。
この例のように、バイトコードの実行に際して、保護実行部 2000内では処理部でき ない処理がある場合には、通常実行部 1000に処理を依頼する。この場合でも、バイ トコード自体は、保護されている。
[0100] 以上の説明では newarray命令を例にとり、 OS 1020が提供するロック機能を利用 する際に、セキュアインタプリタ 2210から通常実行部 120に処理を移していた力 上 記以外の場合にも、通常実行部 1000への遷移が必要になる場合がある。
例えば、セキュアインタプリタ 2210が、 Java (登録商標)ネイティブライブラリ 1150を 呼出した場合には、 Java (登録商標)ネイティブライブラリ 1150は通常実行部 1000 にしか存在しないため、通常実行部 1000に処理を移す必要がある。
[0101] 以上、説明したように、バイトコードを保護実行部 2000のバイトコード記憶部 2600 のみに記憶するため、不正なユーザがデバッガ等を利用して、 Java (登録商標）アブ リケーシヨンを盗聴、改竄を試みても、バイトコードにアクセスができないため、盗聴、 改竄は不可能になる。
<実施形態 2>
実施形態 1では、メソッドのバイトコードのすべてを保護実行部 2000内に記憶して 実行しているが、実施形態 2では、バイトコードの一部のみを保護実行部 2000内に 記憶して実行する点が異なる。
[0102] 本実施形態の実行装置は、保護実行部力 通常実行部のメモリへのアクセスが制 限される場合に、特に有効である。
というのは、実施形態 1では、第 2CPU2900から第 1RAM1910へのアクセスが可 能という前提があるので、保護実行部がバイトコードを実行する際に、通常実行部の メモリにあるメタ情報へのアクセスは容易であった。
[0103] し力し、第 2CPU2900が第 1RAM1910にアクセスできない場合には、メタ情報が 必要となるたびに、通常実行部 1000に遷移する必要があり、また、 Java (登録商標） ヒープ上のデータの読込み、書込みを行う場合にも、通常実行部 120に遷移する必 要があることから、実行速度の観点で実用的ではな!/、場合がある。
そこで、本実施形態では、第 2CPU2900力 第 1RAM1910にアクセスできない 場合でも、不正なユーザからバイトコードを保護しながら、実行速度も保持できる実行 装置を説明する。
[0104] 以下、実施形態 1と相違する点について説明する。
<構成>
図 21は、実施形態 2の実行装置の構成を示す機能ブロック図である。
構成は、実施形態 1の実行装置とほぼ同様である（図 4参照)。但し、保護実行部 2
000から通常実行部 1000のメモリを直接アクセスできないことに伴って、一部の機能 部の機能が異なる。
[0105] 以下、実施形態 1の実行装置との相違点を説明する。
実行装置 500は、通常実行部 5000と保護実行部 6000とで構成される。 通常実行部 5000は、アプリケーション記憶部 1200、仮想マシン 5100、クラス記憶 部 1300、ワーク領域 1400及び第 1CPU1900とを備える。 アプリケーション記憶部 1200、クラス記憶部 1300、ワーク領域 1400及び第 1CPU 1900は、実施形態 1と同様である。
[0106] 仮想マシン 5100は、ローダ 5120とインタプリタ 5110とを備え、基本的には、それ ぞれ実施形態 1のローダ 1120とインタプリタ 1110と同様の機能を有する。
実施形態 1のインタプリタ 1110は、クラスの実行時に、バイトコードが通常実行部 1 000にある力保護実行部 2000にあるかを、メタ情報内のバイトコード分割フラグを参 照して判断していたが（図 12、図 13参照）、本実施形態のインタプリタ 5110は、バイ トコード内の分割フラグを参照する点が異なる。バイトコード内に分割フラグを設定す る方法は、後述する <メタ情報等が必要でないコードの部分を選び出す方法 >で説 明する。
[0107] また、実施形態 1のローダ 1120は、ロードしょうとするクラスが暗号ィ匕されている場 合には、クラスファイルのアドレスとサイズを渡して、保護実行部 2000にクラスフアイ ルの読み込みを依頼したが、本実施形態のローダ 5120は、読み込んだ暗号化クラ スファイルを渡す点が異なる。保護実行部 6000は、クラスファイルが記憶されている アプリケーション記憶部 1200にアクセスできないからである。
[0108] 保護実行部 6000は、復号処理部 6100、復号化クラス記憶部 2400、暗号鍵記憶 ^2500, ノ ィ卜 =3ード、 § 6200、 ノ ィ卜 =3ード、言己'隐§^2600、フーク H 670(X¾ び第 2CPU2900を備える。
復号ィ匕クラス記憶部 2400、暗号鍵記憶部 2500、バイトコード記憶部 2600及び第 2CPU2900は、実施形態 1と同様である。
[0109] 復号処理部 6100は、基本的に実施形態 1の復号処理部 2100と同様にクラスファ ィルの復号化を行うが、復号処理部 2100がアプリケーション記憶部 1200からクラス ファイルを読み込んで復号ィ匕したのに対し、復号処理部 6100は、通常実行部 5000 カゝら渡されるクラスファイルを復号ィ匕する点が異なる。
バイトコード処理部 6200は、セキュアインタプリタ 6210とセキュアローダ 6220を備 える。
[0110] セキュアインタプリタ 2210は、実行中に、通常実行部 1000のメモリに記憶されてい るメタ情報やビープにアクセスしていた力 セキュアインタプリタ 6210は、実行時にメ タ情報等をアクセスしな 、点が異なる。
また、セキュアローダ 2220は、メタ情報を直接クラス記憶部 1300に書き込んだが、 セキュアローダ 5220は、第 2CPU2900を介してー且通常実行部 5000に出力し、 第 1CPU1900によって書き込む必要がある点が異なる。
[0111] ワーク領域 6700は、通常実行部 5000のワーク領域 1400と同様の機能を有する。
実施形態 1では、バイトコードを実行する際に必要なフレームの領域を第 1RAM19 10に確保されたワーク領域 1400に作成していた力 本実施形態では、第 1RAM19 10にアクセスできないので保護実行部 6000内の第 2RAM2910に確保することと する。尚、ヒープの領域は、実施形態 1と同様に通常実行部 5000のワーク領域 140 0に確保する。
[0112] <動作 >
本実施形態の実行装置の動作の説明として、アプリケーションのロードと実行の 2つ のフェーズに分けて説明する。
<クラスのロード処理 >
まず、各クラスをロードする処理、すなわち、アプリケーションプログラム 1210のクラ スファイルを仮想マシン 5100が実行可能な内部形式に変換し、ロードする手順につ いて説明する。
[0113] 図 22は、実行装置 500のロード処理を表すフローチャートである。この ロード処理 は、通常実行咅 5000のローダ 5120と保護実行咅 6000のセキュァローダ6220カ 行う処理である。
また、図 23は、保護対象クラスのクラスファイルがロードされた、クラス記憶部 1300 とバイトコード記憶部 2600の状態を示す図である。
[0114] まず、インタプリタ 5110力ローダ 5120に、クラスファイル名を渡してロードを依頼し 、依頼を受けたローダ 5120は、渡されたクラスファイル名のクラス力 暗号化されたク ラスカゝ否かを判断し (ステップ S200)、保護対象クラスでな!ヽと判断した場合は (ステ ップ S 200 : NO)、クラス記憶部 1300にロードする（ステップ S 260)。
[0115] 一方、ロードの依頼を受けたクラスが、保護対象クラスであると判断した場合は (ステ ップ S200 : YES)、ロードするクラスをアプリケーション記憶部 1200から読み出し、読 み出したクラスファイルを復号処理部 6100に渡す (ステップ S410)。
クラスファイルを受け取つた復号処理部 6100は、受け取つたクラスファイルを暗号 鍵記憶部 2500に記憶されている復号ィ匕鍵 2923を用いて復号ィ匕し、復号化クラス記 憶部 2400に記憶する（ステップ S420)。
[0116] 復号ィ匕クラスファイルを作成した復号処理部 6100は、その旨バイトコード処理部 62
00に通知し、通知を受けたバイトコード処理部 6200は、セキュアべリファイャ 2230 に復号ィ匕クラスファイルを検査させ、セキュアローダ 6220にロードを依頼する。
ロードの依頼を受けたセキュアローダ 6220は、復号ィ匕クラスファイルの構文を分析 し、仮想マシン 5100が実行可能な内部形式に変換する。このときに、セキュアローダ
6220は、復号ィ匕クラスファイルのタグから、バイトコードの部分とメタ情報の部分の判 別を行い、分割する (ステップ S430)。
[0117] 次に、セキュアローダ 6220は、バイトコードから、実行時にメタ情報、および Java ( 登録商標）ヒープにアクセスが必要でな 、バイトコードの部分を選び出す。メタ情報等 が必要でないコードの部分を選び出す方法は、図 24を用いて後で説明する。
セキュアローダ 6220は、メタ情報が必要でないバイトコードと、メタ情報が必要なバ イトコードに分割する (ステップ S440)。
[0118] セキュアローダ 6220は、メタ情報が必要でないバイトコードと、メタ情報が必要なバ イトコードに分割したら、バイトコード管理部 2250に依頼し、メソッドのメタ情報と、メタ 情報が必要でないバイトコードとを関連付けるための IDをそれぞれに付加する（図 2
3参照： ID5331と ID6611)。
次に、セキュアローダ 6220は、メタ情報とメタ情報等が必要なバイトコードを、第 2C
PU2900を介して第 1CPU1900に転送する。第 1CPU1900は、受け取ったメタ情 報（図 23参照：クラス構造情報 1310、コンスタントプール 1320、メソッドのメタ情報 5
330)とメタ情報等が必要なバイトコード 5340 (図 23参照）をクラス記憶部 1300に口 ードする（ステップ S450)。
[0119] また、セキュアローダ 5220は、メタ情報が必要でないバイトコード 6610 (図 23参照
)を、バイトコード記憶部 2600にロードする（ステップ S460)。
<メタ情報等が必要でないコードの部分を選び出す方法 > メタ情報等が必要でないコードの部分を選び出す方法を説明するとともに、分割フ ラグの設定を、図 24に示すバイトコード 7000を参照しながら説明する。
[0120] 1行目の「iload— 1」と 2行目の「iload— 2」とは、ローカル変数領域の 1番目の値を オペランドスタックに積む命令であり、メタ情報が必要でない命令である。オペランド スタックはワーク領域 6700のフレーム領域にある領域である。
また、 3行目の「iadd」は、オペランドスタック上の値の足し算を行う命令であり、メタ 情報が必要でな 、命令である。
[0121] 従って、 1行目から 3行目までもノイトコード 7001は、メタ情報が必要でない命令で ある。
4行目の「newarray」は、ワーク領域 1400上の Java (登録商標）ヒープに領域を確 保するため、 Java (登録商標）ヒープが必要となる命令である。
最後に「areturn」は、メソッドの後処理をするため、メタ情報が必要となる命令であ る。
[0122] 従って、 4行目と 5行目のバイトコード 7002は、メタ情報および Java (登録商標）ヒー プにアクセスが必要な命令である。
分割したバイトコードの例を、図 25に示す。
バイトコード 7000の 1行目〜3行目のバイトコード 7001を、メタ情報が必要でない バイトコード 7200として作成する。連続した行のバイトコードを 1つの塊として切り出 す。本実施形態では、メソッドに 1つの例で説明する。
[0123] また、バイトコード 7000の中で、メタ情報が必要でないバイトコード 7200とし手分割 したコードの部分を書き換えたものを、メタ情報が必要なバイトコード 7100とする。 メタ情報が必要なバイトコード 7100は、分割された先頭の部分に分割されたことを 示す分割フラグ 7101を埋め込んでおく。具体的には、予め決めた、分割フラグであ る旨を示す命令コードを記載する。
[0124] 分割された先頭以外の部分、すなわちバイトコード記憶部 2600に記憶されている コードの部分には nop命令等の意味のないコード 7102を埋め込んでおく。
以上のように構成することにより、クラスファイルのバイトコードの一部がデバッガ等 により、解析できない領域にロードすることが可能となる。 尚、メソッドに複数の、メタ情報が必要でないバイトコードの塊がある場合は、分割フ ラグ 7101と該当するバイトコードを対応付けておくことで、実行が可能となる。例えば 、分割フラグと対応するバイトコードとに共通の IDを振るなどである。
[0125] <クラスの実行処理 >
次に、実行装置 500が、バイトコード 7000を実行する処理について図 26を用いて 説明する。
図 26は、クラスの実行の処理を表すフローチャートである。
まず、クラスを実行するにあたり、インタプリタ 5110はメソッドを呼出す (ステップ S50 0)。
[0126] インタプリタ 5110は、いまから実行するメソッドの Java (登録商標）フレームを、ヮー ク領域 1400に作成し、メタ情報が必要なバイトコード 7100の実行を開始する (ステツ プ S510)。
まず、インタプリタ 5110は、命令をフェッチすると、その命令が分割フラグ 7101で ある力否かを判別する (ステップ S520)。
[0127] 分割フラグ 7101でない場合 (ステップ S520 : NO)、すなわち、他の命令コードであ つた場合は、メソッド終了以外 (ステップ S570 : NO)は、通常実行部 5000でその命 令の実行を行う（ステップ S 510)。
分割フラグ 7101である場合 (ステップ S520 : YES)は、インタプリタ 5110は、処理 を保護実行部内 6000内のバイトコード処理部 6200に処理を依頼する (ステップ S 5 30)。この依頼の際、実行中のメソッドの Java (登録商標）フレーム内のローカル変数 領域とオペランドスタック、およびメソッドのメタ情報 5330内の ID5331の値を引数と して渡す。
[0128] 依頼を受けたバイトコード処理部 6200のセキュアインタプリタ 6210は、バイトコード 管理部 2250に、受け取った ID5331の値を渡して、同じ値の IDを持つバイトコード の検索を依頼する。
バイトコード管理部 2250は、バイトコード記憶部 2600から、受け取った ID5331の 値と一致する ID6611を有するメタ情報が必要でないバイトコード 6610を検索する（ ステップ S 540)。 [0129] IDの値が一致するメタ情報が必要でないバイトコード 6610を見つけたバイトコード 管理部 2250は、バイトコードのアドレスをセキュアインタプリタ 6210に返す。例えば、 図 25のメタ情報が必要でないバイトコード 7200のアドレスである。
セキュアインタプリタ 6210は、引数として受け取ったローカル変数領域とオペランド スタックを利用して、メタ情報が必要でないバイトコード 6610の処理を行う（ステップ S 550)。
[0130] メタ情報が必要でないバイトコード 6610が実行中には、通常実行部 5000のメモリ 上のデータの読み込み、書き込みをすることは不要なので、バイトコード処理部 620 0ですベての処理が可能である。
メタ情報が必要でないバイトコード 6610の実行が完了すると、ローカル変数領域、 オペランドスタック、および、通常実行部 5000のインタプリタ 5110が次に実行する命 令を指すプログラムカウンタを返り値として、処理をインタプリタ 5110に復帰させる (ス テツプ S560)。
[0131] インタプリタ 5110は、メタ情報が必要なバイトコード 6610の返り値として受け取った プログラムカウンタ力も続きを実行する（ステップ S570、ステップ S510)。
以降の処理は従来の Java (登録商標)仮想マシンと同じである。
<実施形態 3 >
実施形態 3の実行装置は、通常実行部と保護実行部とがそれぞれマルチタスクで 動作可能なものである。
[0132] 実施形態 1と実施形態 2では、第 1CPUと第 2CPUが交互に動作することを前提と していた。
本実施形態では、第 1CPUと第 2CPUが同時に動作するときに、実行装置がアブ リケーシヨンを保護しながら実行する方式を説明する。
<構成>
図 27は、本実施形態を実行するための、実行装置 800の構成例を示す図である。
[0133] セキュア OS8100以外は、実施形態 1と同様の構成である（図 1参照)。
第 2CPU2900は、通常実行部 1000内の第 1RAM1910に対して読み込み、書き 込みが可能である点も、実施形態 1と同様である。 また、第 2CPU2900は、第 1CPU1900とは、物理的に異なる CPUである。
[0134] ここでは、セキュア OS8100のみ説明する。
セキュア OS8100は、保護実行咅 8000内の第 2CPU2900上で動作する、 Linux 等のマルチタスクをサポートして 、る OSである。
同一のスレッドの処理が、同じ時間に、保護実行部 8000と通常実行部 1000内と で動作して!/、ることはな!/、ものとする。
[0135] <動作 >
次に、実行装置 800が、アプリケーションを実行する方法を説明する。
実行に先立って行われるクラスファイルのロード処理は、実施形態 1と同様である（ 図 11等参照)。また、機能ブロックは、実施形態 1と同様であるため、図 4を参照して、 本実施形態の実行装置の動作を説明する。
[0136] 図 28は、実施形態 3のクラス実行の処理を表すフローチャートである。
点線で示したステップは、ターゲットとなるクラスの実行に関する処理を表して 、る。 通常実行部 1000のインタプリタ 1110が、スレッドの実行開始し (ステップ S600)、 スレッドが保護対象クラスのメソッドのものであった場合、 保護実行部 8000に処理 を依頼する。以下、この依頼された処理を、「当該処理」という。
[0137] インタプリタ 1110は、 OS1020を介して、保護実行部 8000のセキュア OS8100に 当該処理を依頼する（ステップ S610)。
セキュア OS8100は、保護実行部 8000が行っている処理を一時停止し、依頼を受 けたスレッドの当該処理を受け取り（ステップ S 700)、当該処理を受け取つたことを O S1020に通知する。
[0138] このときに、通常実行部 1000のインタプリタ 1110は、当該処理を依頼したスレッド を、保護実行部 8000からの処理完了通知待ち状態にする (ステップ S620)。
以降の処理は、通常実行部 1000と保護実行部 8000とが並行に動作を開始する。 セキュア OS8100は、当該処理をセキュア OS8100のスケジューラに渡して登録す る（ステップ S710)。当該処理の開始は、セキュア OS8100内のスケジューラが管理 する。
[0139] 通常実行部 1000のインタプリタ 1110は、他のスレッドの処理を実行する（ステップ S630)。
一方、保護実行部 8000のノイトコード管理部 2200も、スケジューラに処理を渡し た後は、当該処理を渡される前に実行していたバイトコード処理部 2200の処理を継 続する (ステップ S 720)。
[0140] その後、保護実行部 8000では、スケジューラにより当該処理の開始通知をバイトコ ード管理部 2200が受け取り、当該処理を開始する (ステップ S730)。
ノイトコード管理部 2200が当該処理の実行を完了すると、完了を検出したセキュア OS8100力 通常実行部 1000の OS1020に処理の完了を通知する（ステップ S74 0)。
[0141] 保護実行部 8000より完了通知を受け、通常実行部 1000のインタプリタ 1110は待 ち状態になって 、た処理を再び開始する。 （ステップ S640)。
その後、通常実行部 1000と保護実行部 8000では、それぞれスケジューラの指示 に従い、他の処理を実行していく（ステップ S650、ステップ S750)。
以上説明したように、バイトコードを保護実行部 8000にのみ記憶し、不正行為を防 ぐことができることに加え、 2つの CPUが並列で動作することにより、実行速度が向上 する。
[0142] なお、実施形態 3では、バイトコードのすべてを第 2RAMに記憶し、保護実行部内 で処理をしていた力 実施形態 2のようにバイトコードの一部を第 2RAMに記憶して も本発明は実施可能である。
<補足 >
以上、本発明に係る実行装置について実施形態に基づいて説明したが、この実行 装置を部分的に変形することもでき、本発明は上述の実施形態に限られないことは 勿論である。即ち、
(1)実施形態では、クラスファイルが暗号化されているカゝ否かを判別する場合に、保 護対象クラス一覧を参照することとしているが、他の方法であっても良い。
[0143] 例えば、保護対象クラス一覧を使用せずに、クラスファイルの特定箇所に特定のコ ードが入っていないなど、通常のクラスファイルと異なることを判別できればよい。また 、復号ィ匕の過程で、正当性を検証することとしてもよい。実行中にエラーとなることを 防ぎ、実行自体を停止することができると!、う利点がある。
また、アプリケーションをダウンロードする場合は、ダウンロードする別のファイルに 判別するための情報がはいっていてもよい。アプリケーションが放送波によって送ら れてくるものである場合には、多重化されて送られてくるファイルを利用して判別して ちょい。
[0144] またさらに、アプリケーションプログラムの開発者が、クラスファイルの名前に保護が 必要なクラスに特定の文字列を付加し、実行時に、クラスファイルの名前から実行時 の保護が必要かを判断をしてもょ ヽ。
さらに、実施形態では、保護対象クラス一覧に載っているクラスは、保護が必要で 暗号化されて ヽるものとして ヽるが、暗号化されて ヽるすべてのクラスを載せる必要 はなく、作成者が保護した ヽと希望するクラスのみでもよ 、。
[0145] この場合、例えば、通常実行部でも復号ィ匕する機能部を備え、保護対象クラス一覧 に乗って!/、な!/、暗号化されたクラスを復号化して実行する。
また、実施形態では、アプリケーションのクラスファイル名を載せることとしている力 その他、 Java (登録商標)仮想マシン内のクラスライブラリに含まれるクラス名などを記 載していてもよい。
[0146] また、実施形態では、クラス全体を暗号ィ匕している力 クラス内のバイトコードのみを 暗号ィ匕しておいても良い。この場合、バイトコードのみを保護実行部に送ることとして ちょい。
また、実施形態では、暗号鍵は 1つとして説明しているが、複数を使い分けても良 い。例えば、保護対象クラス一覧に、使用する暗号鍵を特定できる情報を入れておき 、その情報によって特定される暗号鍵でクラスを復号ィ匕するなどである。
(2)実施形態 1では、バイトコード分割フラグをメソッドのメタ情報内に用意したが、他 の場所に作成しても良い。
[0147] たとえば、クラス情報構造情報にフラグを用意してもよい（図 12等参照)。
(3)実施形態 1、実施形態 2及び実施形態 3では、保護実行部で処理が必要なときだ けに保護実行部に処理を依頼していたが、保護実行部で処理が必要でないときであ つても保護実行部に処理を依頼し、保護実行部は何も処理を行わずに処理を通常 実行部に返してもよい。
[0148] クラスの実行時に、必ず保護実行部に制御が移ることで、本当に保護した ヽクラス の特定を困難にする効果がある。
なお、実施の形態では、実行する Java (登録商標）アプリケーションや仮想マシンを 通常実行部のメモリにおいておき、そのクラスファイルをロードするときに、保護実行 部で実行すべきバイトコードである力否かを判別していた力 予め、第 2ROMに、保 護すべきバイトコードを記憶しておき、実行時に第 2RAMにロードしてもよい。この場 合、メタ情報とバイトコードを対応付ける情報、例えば、 IDは、予め設定しておく必要 がある。
(4)実施形態 1及び実施形態 2では、実行装置 100の第 1CPU1900と、保護実行 部 2000の第 2CPU2900とは、物理的に異なる CPUであるとしている力 物理的に 1つの CPU力 動作モードを切り替えるなどの方法で仮想的に 2つの CPUのように 振舞うこととしてもよい。また、マルチコア CPUのように、 1つの CPUパッケージのな かに複数の CPUコアを持つ CPUでは、そのうちの特定のコアを第 2CPUとして動作 させてちょい。
[0149] また、実施形態では、通常実行部 1000と保護実行部 2000とにそれぞれ、 RAM および ROMを持つこととしているが、 1つの RAMを仮想的に 2つの RAMとして扱つ てもよい。同様に、 1つの ROMを仮想的に 2つの ROMとして扱ってもよい。さらに、 保護実行部 2000内の ROMは第 2CPU2900に混載されていてもよい。
(5)実施形態では、実行装置 100で実行するアプリケーションは、アプリ取得プロダラ ム 1010力 インターネット上にあるサーバから、ダウンロードしたものであるが、ほか の方法で取得したアプリケーションであってもよい。
[0150] 例えば、デジタル放送のデータ放送として、 MPEG (Moving Picture Coding Expert s Group) 2トランスポートストリーム内に埋め込まれ^ Java (登録商標）アプリケーショ ンであってもよい。
この場合、アプリ取得プログラム 1010は、トランスポートストリーム内に埋め込まれた Java (登録商標）アプリケーションを実行装置 100内に読み出すプログラムとなる。
[0151] MPEG2トランスポートストリームに Java (登録商標）プログラムを埋め込む方法とし ては、例えば、 DSMCC方式がある。 DSMCC方式とは、 MPEG2トランスポートスト リームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成 されるファイルシステムをエンコードする方法である（MPEG規格書 ISOZIEC1381 81— 1、 MPEG規格書 ISOZIEC138181— 6参照）。
[0152] またさらに、実行装置 100で実行するアプリケーションは、 SDカード（Secure Digital memory card)、 CD— ROM (Compact Disk Read Only Memory;、 DVD (Digital Ve rsatile Disk)、 Blu—RayDisc等に記録され^ Java (登録商標）アプリケーションであ つてもよい。
この場合、アプリ取得プログラム 1010は、これらの記録媒体力もアプリケーションを 読み出すプログラムとなる。
[0153] また、実行装置 100で実行するアプリケーションは、実行装置 100内にある ROMな どに記録され ava (登録商標）アプリケーションであってもよ!/、。
この場合、アプリ取得プログラム 1400は、 ROM力も作業メモリに、 Java (登録商標） アプリケーションを読み出すプログラムとなる。
さらに、近年、デジタル TVや携帯電話などの電子機器では、 Java (登録商標)言語 で記述されたプログラムをダウンロードし、実行する機能を搭載するものが増加して ヽ る。例えば携帯電話では、 NTT DoCoMoが i—アプリと呼ばれるサービスを提供し ている。このサービスは、携帯電話端末力インターネット上にあるアプリケーション配 信サーバから Java (登録商標)プログラムをダウンロードして、端末上で実行する。ま た、欧州では、 DVB— MHP (Digital Video Broadcasting - Multimedia Ho me Platform)と呼ばれる仕様が策定され、既に仕様に準拠した運用が開始されて いる。 DVB— MHP規格に基づくデジタル放送では、放送波に多重化され^ Java ( 登録商標)プログラムをデジタル TVが受信し、それを実行する。
[0154] この場合、アプリ取得プログラム 1010は、 TLS (Transport Layer Security)、 HTT P (Hypertext Transfer Protocol)等のプロトコルに従い Java (登録商標）アプリケーシ ヨンをダウンロードする機能を有するプログラムとなる。
ここで、 TLSは暗号ィヒにより通信時のデータの盗聴、改竄を防ぐデータ転送方式で ある（RFC2246参照）。また、 HTTPは、インターネット上のデータ通信で一般的に 用いられて 、るデータ転送方式である（RFC2616参照）。
[0155] 尚、 RFC (Request For Comments)とは、インターネット上の技術を規格化する IET F (Internet Engineering Task Force)の公式文書であり、プロトコルなど様々な技術の 使用がまとめられているものである。
(6)本実施形態では、アプリ取得プログラム 1010など ^Java (登録商標）言語で記 述され^ Java (登録商標）プログラムなどの他、ネイティブ言語で記述されたプロダラ ムゃ、ハードウェアで実現されていてもよい。
[0156] また、仮想マシンで実行するアプリケーションは、 Java (登録商標）言語で記述され たものに限らず、 C+ +などの他のオブジェクト指向言語で記述されたものであっても よい。また、 Java (登録商標)仮想マシン自体も、オブジェクト指向言語で記述されて も、非オブジェクト指向言語で記述されてもよい。
(7)実施形態の保護実行部 2000は、例えば、 ARM社の TrustZone (登録商標）技 術を使うことで実現することができる。
[0157] TrustZone (登録商標）技術では、 RAMや ROMなどのハードウェア資源の一部 をセキュアドメインと呼ばれる仮想的に実行環境に割り当てることができる。セキュアド メインに割り当てられた RAMや ROMは、セキュアドメインで動作するプログラムのみ が利用可能であり、セキュアドメイン以外で動作するプログラムからは一切利用するこ とができない。
[0158] 従来の CPUでは、アプリケーションが動作する通常モードと OSなどが動作する特 権モードの 2種類のモードを持ち、通常モードで動作するプログラムからは特権モー ドで動作するプログラムを改ざんすることができないようになつている。
TrustZone (登録商標）技術では、さらに、モニターモードと呼ばれる特殊なモード が新しく用意される。モニターモードへは、 CPUが用意する特殊な命令を実行するこ とで遷移することができる。モニターモードで CPUが動作するときには、 S— bitと呼 ばれるセキュリティ情報が RAMや ROMなどの周辺ハードに通知される。 TrustZon e (登録商標）技術に対応した RAMや ROMは、 S— bitが通知された場合に限り、セ キュアドメインに割り当てられた領域へのデータの読み書きを許可するように構成され て 、る。またセキュアドメインに割り当てられて!/、な 、領域へのデータへの読み書きは S— bitが通知されている力否かに関わらず読み書きを許可する。このように、安全な 実行部はセキュアドメインにより実現することができる。
[0159] また、 Intel社の LaGrande技術でも、通常のアプリケーションや OSが動作するドメ インと保護が必要なアプリケーションが動作するドメインを仮想的に分離するなど、 Tr ustZone (登録商標)技術と同様の機能を提供して 、る。このような技術を使うことで 安全な実行部を実現することができる。
(8)実施形態では、保護実行部 2000は、実行装置 100に内蔵されているものとして いるが、実行装置 100から着脱可能なスマートカードや ICカードなどであることとして もよい。このスマートカード、 ICカードはカード内部に CPUやメモリ、セキュリティ回路 を含むものである。
[0160] 保護実行部 2000は、その全体をノヽードウエアにより実現してもよい。
この場合、第 1CPUと第 2CPU間のデータ通信は暗号ィ匕して行い、第 3者による盗 聴を防ぐことが必要となる。具体的には、両 CPUを結ぶデータバスを介してデータを 送信する際に、送信するデータを暗号化し、データを受信後に復号することで行わ れる。
(9)実施形態では、アプリケーションの実行環境プログラムとして、 Java (登録商標） 仮想マシンを例に説明している力 他の実行環境であってもよぐ OSであってもよい
[0161] また、更に、アプリケーションが実行環境プログラムに該当する場合には、そのアブ リケーシヨン自体を秘匿するノイトコードの対象としてもよ ヽ。
(10)実施形態で示した実行装置の各機能を実現させる為の各制御処理 (図 4等参 照）を CPUに実行させる為のプログラムを、記録媒体に記録し又は各種通信路等を 介して、流通させ頒布することもできる。このような記録媒体には、 ICカード、光デイス ク、フレキシブルディスク、 ROM,フラッシュメモリ等がある。流通、頒布されたプログ ラムは、機器における CPUで読み取り可能なメモリ等に格納されることにより利用に 供され、その CPUがそのプログラムを実行することにより実施形態で示した実行装置 の各機能が実現される。
(11)実行装置における保護実行部（2000、 6000、 8000)は典型的には集積回路 である LSIとして実現される。これらは個別に 1チップ化されても良いし、一部又は全 てを含むように 1チップィ匕されても良い。
[0162] ここでは、 LSIとした力 集積度の違いにより、 IC、システム LSI、スーパー LSI、ゥ ノレ卜ラ LSIと呼称されることちある。
また、集積回路化の手法は LSIに限るものではなぐ専用回路又は汎用プロセサで 実現してもよい。 LSI製造後に、プログラムすることが可能な FPGA (Field Programma ble Gate Array)や、 LSI内部の回路セルの接続や設定を再構成可能なリコンフィギ ユラブル'プロセッサーを利用しても良い。
[0163] さらには、半導体技術の進歩又は派生する別技術により LSIに置き換わる集積回 路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積ィ匕を行って もよい。バイオ技術の適応等が可能性としてありえる。
産業上の利用可能性
[0164] 本発明に係るアプリケーションの実行装置は、アプリケーションの実行、解析に不可 欠なノイトコードを、ハードウェアなどで実現された、盗聴、改竄が困難な保護実行 部へと隠蔽することで、アプリケーションを実行時の盗聴、改竄力 保護することがで き、今後本格展開が予想されるアプリケーションのダウンロード配信ビジネスにお 、て 、コンテンツに発生する作成者の権利などを保護することができる。

Claims

請求の範囲
[1] オブジェクト指向言語で作成された、実行コードを含む 1以上のクラスを有するアブ リケーシヨンプログラムを実行するプログラム実行装置であって、
それぞれメモリとプロセッサとを含む、第 1実行デバイスと耐タンパ性を有する第 2実 行デバイスと、
前記クラスをロードする際に、当該クラスの実行コードを第 2実行デバイスのメモリに ロードし、当該クラスの、第 2実行デバイスのメモリにロードした実行コード以外の部分 を第 1実行デバイス内のメモリにロードするローダと
を備えることを特徴とするプログラム実行装置。
[2] 前記クラスの実行コードは、暗号化されており、
前記プログラム実行装置は、更に、暗号化されている情報を復号化する復号化手 段を備え、
前記ローダは、暗号ィ匕されている実行コードを、前記復号ィ匕手段に復号ィ匕させ、復 号化された実行コードを第 2実行デバイスのメモリにロードする
ことを特徴とする請求項 1記載のプログラム実行装置。
[3] 前記クラスは、暗号化されており、
前記第 1実行デバイスは、更に、クラスが暗号化されているカゝ否かを判断する判断 する判断手段を備え、
前記第 2実行デバイスは、更に、自デバイス内のメモリに記憶する暗号ィ匕されてい るクラスを復号化する復号化手段を備え、
前記ローダは、前記第 1実行デバイスのプロセッサにより実行される第 1ローダと、 前記第 2実行デバイスのプロセッサにより実行される第 2ローダとで構成され、 前記第 1ローダは、前記判断手段にクラスが暗号化されているか否かを判断させ、 暗号ィ匕されていないと判断されたクラスは、第 1デバイス内のメモリにロードし、暗号 ィ匕されていると判断されたクラスは、第 2実行デバイスのメモリに記憶させ、
前記第 2ローダは、第 2実行デバイスのメモリに記憶された暗号化されて!/、るクラス を前記復号ィ匕手段に復号化させ、得られた復号化されたクラスの実行コードを第 2実 行デバイスのメモリにロードし、当該復号化されたクラスの、第 2実行デバイスのメモリ にロードした実行コード以外の部分を、当該実行コードと対応付けて第 1デバイス内 のメモリにロードする
ことを特徴とする請求項 1記載のプログラム実行装置。
[4] 前記プログラム実行装置は、更に、クラスの実行を制御する制御手段を備え、 前記制御手段は、第 1デバイスのメモリに記憶されているクラスを第 1デバイスのプ 口セッサに実行させ、当該クラスの実行コードが第 1デバイスのメモリに記録されてい ない場合には、第 2デバイスのメモリに記憶されている対応する実行コードを第 2デバ イスのプロセッサに実行させる
ことを特徴とする請求項 3記載のプログラム実行装置。
[5] オブジェクト指向言語で作成された、実行コードを含む 1以上のクラスを有するアブ リケーシヨンプログラムを実行するプログラム実行装置に備えられた耐タンパ性を有 する実行デバイスであって、
メモリと、プロセッサと、
前記メモリに記憶する暗号化されて ヽるクラスを復号化する復号化手段と、 前記メモリに記憶された暗号ィ匕されて ヽるクラスを前記復号ィ匕手段に復号ィ匕させ、 得られた復号ィ匕されたクラスの実行コードを前記メモリにロードし、当該復号化された クラスの、前記メモリにロードした実行コード以外の部分を、当該実行コードと対応付 けて自デバイス外のメモリにロードするローダと
を備えることを特徴とする実行デバイス。
[6] オブジェクト指向言語で作成された、実行コードを含む 1以上のクラスを有するアブ リケーシヨンプログラムを実行するプログラム実行装置に備えられた、メモリとプロセッ サとを有する耐タンパ性を有する実行デバイスに、ロード処理を行わせるためのコン ピュータプログラムであって、
前記メモリに記憶する暗号化されて ヽるクラスを復号化する復号化ステップと、 前記メモリに記憶された暗号ィ匕されて 、るクラスを前記復号化ステップで復号ィ匕し、 得られた復号ィ匕されたクラスの実行コードを前記メモリにロードし、当該復号化された クラスの、前記メモリにロードした実行コード以外の部分を、当該実行コードと対応付 けて自デバイス外のメモリにロードするステップと を備えることを特徴とするコンピュータプログラム。
オブジェクト指向言語で作成された、実行コードを含む 1以上のクラスを有するアブ リケーシヨンプログラムを実行するプログラム実行装置に備えられた耐タンパ性を有 する集積回路であって、
メモリと、プロセッサと、
前記メモリに記憶する暗号化されて ヽるクラスを復号化する復号化手段と、 前記メモリに記憶された暗号ィ匕されて ヽるクラスを前記復号ィ匕手段に復号ィ匕させ、 得られた復号ィ匕されたクラスの実行コードを前記メモリにロードし、当該復号化された クラスの、前記メモリにロードした実行コード以外の部分を、当該実行コードと対応付 けて自デバイス外のメモリにロードするローダと
を備えることを特徴とする集積回路。
PCT/JP2006/314428 2005-07-22 2006-07-20 実行装置 WO2007011001A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US11/917,948 US20100146304A1 (en) 2005-07-22 2006-07-20 Execution device
JP2007526058A JPWO2007011001A1 (ja) 2005-07-22 2006-07-20 実行装置
EP06781383A EP1909244A1 (en) 2005-07-22 2006-07-20 Execution device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005212160 2005-07-22
JP2005-212160 2005-07-22

Publications (1)

Publication Number Publication Date
WO2007011001A1 true WO2007011001A1 (ja) 2007-01-25

Family

ID=37668873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/314428 WO2007011001A1 (ja) 2005-07-22 2006-07-20 実行装置

Country Status (5)

Country Link
US (1) US20100146304A1 (ja)
EP (1) EP1909244A1 (ja)
JP (1) JPWO2007011001A1 (ja)
CN (1) CN101228531A (ja)
WO (1) WO2007011001A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008242948A (ja) * 2007-03-28 2008-10-09 Toshiba Corp 情報処理装置および同装置の動作制御方法
JP2010541084A (ja) * 2007-10-02 2010-12-24 インターナショナル・ビジネス・マシーンズ・コーポレーション セキュア・カーネル設計による安全基準の差別化
JP2011150560A (ja) * 2010-01-22 2011-08-04 Kddi Corp ソフトウェア保護システム、ソフトウェア保護方法、ソフトウェア変換方法およびプログラム
WO2012001768A1 (ja) 2010-06-29 2012-01-05 Suginaka Junko 携帯通信端末、その起動方法及びネットワーク通信システム
US10740443B2 (en) 2015-08-10 2020-08-11 Line Corporation System and method for code obfuscation of application

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2240857A4 (en) * 2007-12-21 2013-12-25 Univ Virginia Patent Found SYSTEM, METHOD AND COMPUTER PROGRAM FOR PROTECTING SOFTWARE THROUGH ANTI-FALSIFICATION AND OBSCURING TRANSFORMATIONS
FR2934697B1 (fr) * 2008-07-29 2010-09-10 Thales Sa Procede et systeme permettant de securiser un logiciel
US8438401B2 (en) * 2009-09-22 2013-05-07 Raytheon BBN Technologies, Corp. Device and method for securely storing data
EP2497055B1 (en) * 2009-11-05 2018-07-18 Trusted Logic Secure portable object
CN102598017B (zh) * 2009-11-13 2016-03-09 爱迪德技术有限公司 提高Java字节码的防窜改能力的系统和方法
EP2402880A1 (en) * 2010-07-01 2012-01-04 Aladdin Europe GmbH Method and device for selectively protecting one of a plurality of methods of a class of an application written in an object-orientated language
US9594578B2 (en) * 2012-02-28 2017-03-14 Red Hat, Inc. Hardware implementation of a virtual machine interpreter
JP5953867B2 (ja) * 2012-03-26 2016-07-20 富士ゼロックス株式会社 プログラム、及びプログラム保護装置
EP2913772A1 (de) * 2014-02-28 2015-09-02 Wibu-Systems AG Verfahren und Computersystem zum Schutz eines Computerprogramms gegen Beeinflussung
CN103955635B (zh) * 2014-04-04 2017-02-15 北京深思数盾科技股份有限公司 一种对.net可执行程序进行保护的方法和系统
EP3040896A1 (en) * 2014-12-30 2016-07-06 Gemalto Sa Secure element
US9578054B1 (en) 2015-08-31 2017-02-21 Newman H-R Computer Design, LLC Hacking-resistant computer design
EP3692460B1 (en) * 2017-10-06 2021-07-28 Private Machines Inc. Computer server device and methods for initiating and running a computer process

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000056995A (ja) * 1998-08-04 2000-02-25 Digital Vision Laboratories:Kk ネットワークで接続されたノード間のオブジェクト及びプロセスの移動方法及び機能の入れ替え方法並びにそれらの機能を有するノード装置
JP2002353960A (ja) * 2001-05-30 2002-12-06 Fujitsu Ltd コード実行装置およびコード配布方法
JP2005505028A (ja) * 2001-05-15 2005-02-17 ウェイヴ・システムズ・コーポレーション セキュアなコンピューティング環境において、サービスを条件付きでインストールかつ実行するための方法およびシステム
JP2005049925A (ja) 2003-07-29 2005-02-24 Nara Institute Of Science & Technology プログラム難読化装置、プログラム難読化プログラム及びプログラム難読化方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0024918D0 (en) * 2000-10-11 2000-11-22 Sealedmedia Ltd Method of providing java tamperproofing
US7272228B2 (en) * 2003-06-12 2007-09-18 International Business Machines Corporation System and method for securing code and ensuring proper execution using state-based encryption
US20060184803A1 (en) * 2005-02-12 2006-08-17 Rainer Ulrich Method and system for digital rights management in a mobile multimedia processor

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000056995A (ja) * 1998-08-04 2000-02-25 Digital Vision Laboratories:Kk ネットワークで接続されたノード間のオブジェクト及びプロセスの移動方法及び機能の入れ替え方法並びにそれらの機能を有するノード装置
JP2005505028A (ja) * 2001-05-15 2005-02-17 ウェイヴ・システムズ・コーポレーション セキュアなコンピューティング環境において、サービスを条件付きでインストールかつ実行するための方法およびシステム
JP2002353960A (ja) * 2001-05-30 2002-12-06 Fujitsu Ltd コード実行装置およびコード配布方法
JP2005049925A (ja) 2003-07-29 2005-02-24 Nara Institute Of Science & Technology プログラム難読化装置、プログラム難読化プログラム及びプログラム難読化方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008242948A (ja) * 2007-03-28 2008-10-09 Toshiba Corp 情報処理装置および同装置の動作制御方法
JP2010541084A (ja) * 2007-10-02 2010-12-24 インターナショナル・ビジネス・マシーンズ・コーポレーション セキュア・カーネル設計による安全基準の差別化
JP2011150560A (ja) * 2010-01-22 2011-08-04 Kddi Corp ソフトウェア保護システム、ソフトウェア保護方法、ソフトウェア変換方法およびプログラム
WO2012001768A1 (ja) 2010-06-29 2012-01-05 Suginaka Junko 携帯通信端末、その起動方法及びネットワーク通信システム
US10740443B2 (en) 2015-08-10 2020-08-11 Line Corporation System and method for code obfuscation of application

Also Published As

Publication number Publication date
JPWO2007011001A1 (ja) 2009-02-05
CN101228531A (zh) 2008-07-23
US20100146304A1 (en) 2010-06-10
EP1909244A1 (en) 2008-04-09

Similar Documents

Publication Publication Date Title
WO2007011001A1 (ja) 実行装置
US20070271446A1 (en) Application Execution Device and Application Execution Device Application Execution Method
JP5821034B2 (ja) 情報処理装置、仮想マシン生成方法及びアプリ配信システム
WO2005098570A1 (ja) 実行装置
US20080270806A1 (en) Execution Device
JP4891902B2 (ja) 電子機器、更新サーバ装置、鍵更新装置
EP1943607B1 (en) Program executable image encryption
US7962746B2 (en) Computer system and program creating device
US9524391B2 (en) Apparatus and method of portable terminal for application data protection
US20080216071A1 (en) Software Protection
WO2005096121A1 (ja) 実行装置
CN112639778A (zh) 指针认证及指针认证方案之间的动态切换
KR20170114582A (ko) 영상처리장치 및 그 제어방법
US8745407B2 (en) Virtual machine or hardware processor for IC-card portable electronic devices
JP4664055B2 (ja) プログラム分割装置、プログラム実行装置、プログラム分割方法及びプログラム実行方法
JP2008040853A (ja) アプリケーション実行方法およびアプリケーション実行装置
CN110597496B (zh) 应用程序的字节码文件获取方法及装置
CN116108468A (zh) 一种war、jar程序包加解密方法、系统及介质
KR20180100779A (ko) 안드로이드용 어플리케이션의 멀티 실행 파일을 위한 암호화 방법

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680026885.6

Country of ref document: CN

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11917948

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2007526058

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2006781383

Country of ref document: EP