JP2009258772A - Application execution device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To facilitate interception between interfaces for delivering a plain text class file between decryption and a load. <P>SOLUTION: In this application execution device, when it is determined in a loading determination part that a class file to be executed in an interpreter is an encrypted class file, the class file is sent to a decryptor loader. When it is determined in the loading determination part that a class file to be sent to a virtual machine is the plain text class file, the class file is sent to a loader. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to application copyright protection.

  Conventional copyright protection for applications includes encryption of class files. For example, Non-Patent Document 1 discloses a method for encrypting a class file and a method for decrypting an encrypted class file at the time of execution. FIG. 12 is a configuration diagram of a general playback device that protects the copyright of a conventional application, and includes a virtual machine 101 and a Java (registered trademark) application 102. A virtual machine (also referred to as a Java (registered trademark) virtual machine) 101 includes an interpreter 103, a heap memory 104, and a loader 105. The application includes a decryption class loader 107, a protection target class file 108, and a decryption key 109. In order to protect the copyright of the application, the protected class file 108 is distributed in an encrypted format, and is decrypted and converted into an interpretable format before being interpreted and executed. FIG. 13 shows a control flow in which the protected class is changed from the encrypted class file to the class object. First, the decryption class loader 107 decrypts the protection target class file 108 using the decryption key 109 (S201). A class file is obtained by decoding. Thereafter, the decryption class loader 107 passes the class file to the loader 105 to obtain a class object (S202). The protected class file 108 is distributed in an encrypted format, thereby protecting the copyright of the application.

In addition to the above-described method, a method of encrypting the entire distribution file by applying conventional copy protection of the content can be considered.
“Java (registered trademark) World”, online, Internet <URL: http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html>

  However, the conventional technology cannot sufficiently protect the copyright of the Java (registered trademark) application. The interface for passing the plaintext class file between decryption and loading is clear, and there is a weakness that it is easy to intercept the plaintext class file between decryption and loading processing. Further, since the decrypted plaintext class file is arranged on the heap memory 104, the analysis is easy. Another disadvantage is that attackers can disable the copyright protection by analyzing the distribution media using normal reverse engineering techniques. Reverse engineering is a technology that analyzes applications using tools such as disassembler.

  In addition, when the entire distribution file is encrypted, the entire distribution file is decrypted at the time of execution, and the entire distribution file is placed in the memory, so that the long distribution file in plain text is held in the memory. Because it is necessary, it is extremely vulnerable to memory interception.

  An application execution apparatus according to the present invention is an application execution apparatus that executes an application described in an object-oriented program, and decrypts an encrypted class file included in the input application into a plain text class file. Then, a decrypter loader that converts the class object into a heap memory and loads it into the heap memory, a loader that converts the input plain text class file in the application into a class object and loads it into the heap memory, and a class loaded into the heap memory A virtual machine having an interpreter that interprets and executes an object; and a loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plain text class file. When the coding determination unit determines that the class file to be executed by the interpreter is an encrypted class file, the class determination unit sends the class file to the decryptor loader, and the loading determination unit transfers the class file to the virtual machine. In the case where it is determined that the class file to be sent is a plain text class file, the class file is sent to the loader.

  In addition, the application is recorded in a recording medium, and the recording medium encrypts and records a decryption key for decrypting an encrypted class file included in the application with a master key, and stores the data in the recording medium. The crypt loader holds the master key in advance, and when the encrypted class file is input, obtains an encrypted decryption key corresponding to the encrypted class file from the recording medium, and The encrypted decryption key is decrypted using the master key stored in advance, and the encrypted class file is decrypted using the decrypted decryption key.

  The decrypter loader obtains the encrypted decryption key from the recording medium and decrypts the encrypted decryption key using the master key before the encrypted class file is input. It is characterized by being cached.

  Further, the application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key, and the A metafile describing information for extracting a decryption key is recorded, and the loading determination unit describes information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. Information for retrieving the corresponding decryption key based on the metafile is sent to the decryptor loader, and the decrypter loader obtains the encrypted decryption key from the recording medium based on the information for retrieving the decryption key Decrypted using the title key held by the decryptor loader Characterized by decrypting the encrypted class files with.

  The decrypter loader holds a decryption key acquired from the recording medium.

  An application execution apparatus according to the present invention is an application execution apparatus that executes an application described in an object-oriented program, decrypts an encrypted class file included in the input application, and outputs a plaintext class file. And a loader that converts the input plaintext class file in the application or the plaintext class file decrypted by the decryptor into a class object and loads it into the heap memory, and the class object loaded into the heap memory A virtual machine having an interpreter that interprets and executes, and a loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plain text class file When it is determined by the loading determination unit that the class file to be executed by the interpreter is an encrypted class file, the encrypted class file is sent to the decryptor, and the virtual machine is transmitted by the loading determination unit. When the class file to be sent to is determined to be a plain text class file, the class file is sent to the loader.

  The application is recorded in a recording medium, and the recording medium encrypts and records a decryption key for decrypting an encrypted class file included in the application with a master key, and the decryptor The master key is held in advance, and when the encrypted class file is input, a decryption key for decrypting the encrypted class file is obtained from the recording medium, and the obtained encryption The decrypted key is decrypted using the master key held in advance, and the encrypted class file is decrypted using the decrypted decryption key.

  The decryptor acquires the encrypted decryption key from the recording medium and caches the decryption key before the encrypted class file is input.

  Further, the application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key, and the A metafile describing information for extracting a decryption key is recorded, and the loading determination unit describes information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. Information for retrieving a corresponding decryption key based on the metafile is sent to the decryptor, and the decryptor obtains the encrypted decryption key from the recording medium based on the information for retrieving the decryption key, and the decryptor Using the decryption key decrypted using the title key held by Wherein the decoding the class file.

  Further, the decryptor holds a decryption key acquired from the recording medium.

  An application execution apparatus according to the present invention is an application execution apparatus that executes an application described in an object-oriented program, and decrypts an encrypted class file included in the input application into a plain text class file. Then, a decrypter loader that converts the class object into a heap memory and loads it into the heap memory, a loader that converts the input plain text class file in the application into a class object and loads it into the heap memory, and a class loaded into the heap memory A virtual machine having an interpreter that interprets and executes an object; and a loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plain text class file. When the coding determination unit determines that the class file to be executed by the interpreter is an encrypted class file, the class determination unit sends the class file to the decryptor loader, and the loading determination unit transfers the class file to the virtual machine. If it is determined that the class file to be sent is a plain text class file, the class file is sent to the loader, so it is possible to decrypt and load the encrypted class file in the virtual machine. Thus, not only the confidentiality at the time of executing the application becomes high, but also the loading at the class file unit becomes possible, so the confidentiality at the time of executing the application becomes high.

  In addition, when a class file that should be copyright-protected in an application is an encrypted class file and a class file that does not need to be copyright-protected is a normal class file, the normal class file is loaded. By tuning the loader, it is possible to improve the normal class file loading processing speed.

  Further, the application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key, and the A metafile describing information for extracting a decryption key is recorded, and the loading determination unit describes information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. Information for retrieving the corresponding decryption key based on the metafile is sent to the decryptor loader, and the decrypter loader obtains the encrypted decryption key from the recording medium based on the information for retrieving the decryption key Decrypted using the title key held by the decryptor loader Since decrypting the encrypted class file with, it is difficult to analyze in reverse engineering techniques decryption key and the encrypted class files.

  The decrypter loader obtains the encrypted decryption key from the recording medium and decrypts the encrypted decryption key using the master key before the encrypted class file is input. Therefore, the process of decrypting the class file encrypted using the decryption key can be speeded up.

  Further, the application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key, and the A metafile describing information for extracting a decryption key is recorded, and the loading determination unit describes information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. Information for retrieving the corresponding decryption key based on the metafile is sent to the decryptor loader, and the decrypter loader obtains the encrypted decryption key from the recording medium based on the information for retrieving the decryption key Decrypted using the title key held by the decryptor loader The decrypted class file is decrypted by using a plurality of decryption keys by specifying a plurality of decryption keys in a metafile that describes information for extracting a decryption key corresponding to the encrypted class file. Even if the key becomes available and one of the multiple decryption keys is known to the attacker by cryptanalysis, the decryption key can be decrypted using another decryption key unless the attacker knows the other decryption key. Since the class file cannot be decrypted, the secrecy becomes higher.

  In addition, since the decrypter loader holds the decryption key acquired from the recording medium, the process of decrypting the class file encrypted using the decryption key can be accelerated.

  An application execution apparatus according to the present invention is an application execution apparatus that executes an application described in an object-oriented program, decrypts an encrypted class file included in the input application, and outputs a plaintext class file. And a loader that converts the input plaintext class file in the application or the plaintext class file decrypted by the decryptor into a class object and loads it into the heap memory, and the class object loaded into the heap memory A virtual machine having an interpreter that interprets and executes, and a loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plain text class file When it is determined by the loading determination unit that the class file to be executed by the interpreter is an encrypted class file, the encrypted class file is sent to the decryptor, and the virtual machine is transmitted by the loading determination unit. When the class file to be sent to is determined to be a plain text class file, the class file is sent to the loader.

  The application is recorded in a recording medium, and the recording medium encrypts and records a decryption key for decrypting an encrypted class file included in the application with a master key, and the decryptor The master key is held in advance, and when the encrypted class file is input, a decryption key for decrypting the encrypted class file is obtained from the recording medium, and the obtained encryption The decrypted key is decrypted using the master key held in advance, and the encrypted class file is decrypted using the decrypted decryption key, so the encrypted class file is decrypted in the virtual machine. It can be loaded, and the confidentiality at the time of application execution becomes high, and loading by class file unit is possible. Made for, confidentiality at the time of application execution is higher.

  In addition, when a class file that should be copyright-protected in an application is an encrypted class file and a class file that does not need to be copyright-protected is a normal class file, the normal class file is loaded. By tuning the loader, it is possible to improve the normal class file loading processing speed.

  The application is recorded in a recording medium, and the recording medium encrypts and records a decryption key for decrypting an encrypted class file included in the application with a master key, and the decryptor The master key is held in advance, and when the encrypted class file is input, a decryption key for decrypting the encrypted class file is obtained from the recording medium, and the obtained encryption Since the decrypted key is decrypted using the master key held in advance, and the encrypted class file is decrypted using the decrypted decryption key, the reverse engineering of the decrypted key and the encrypted class file is performed. Analysis with technology becomes difficult.

  Further, the decryptor obtains the encrypted decryption key from the recording medium and caches the decryption key before the encrypted class file is input. It is possible to speed up the process of decrypting the converted class file.

  Further, the application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key, and the A metafile describing information for extracting a decryption key is recorded, and the loading determination unit describes information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. Information for retrieving a corresponding decryption key based on the metafile is sent to the decryptor, and the decryptor obtains the encrypted decryption key from the recording medium based on the information for retrieving the decryption key, and the decryptor Using the decryption key decrypted using the title key held by Since the decrypted class file is decrypted, a plurality of decryption keys can be used by specifying a plurality of decryption keys in the metafile that describes information for extracting the decryption key corresponding to the encrypted class file. Even if one of the multiple decryption keys is known to the attacker by the decryption method, unless the other decryption key is known to the attacker, the decryption of the encrypted class file that is decrypted using the other decryption key Since it cannot be performed, confidentiality becomes higher.

  In addition, since the decryptor holds the decryption key acquired from the recording medium, it is possible to speed up the process of decrypting the class file encrypted using the decryption key.

  Embodiments of the present invention will be described below with reference to the drawings.

(Embodiment 1)
FIG. 1 is a diagram illustrating a configuration of a BD-ROM (also referred to as a BD) which is an example of a recording medium used in the present embodiment. A BD disc has a spiral recording area from the inner circumference to the outer circumference like other optical discs such as DVDs and CDs, and logical data is transferred between the inner lead-in and outer lead-out. It has a logical address space that can be recorded. Further, inside the lead-in, there is a special area that can be read only by a drive called BCA (Burst Cutting Area). Since this area cannot be read from an application, it is often used for copyright protection technology, for example.

  Application data such as video data is recorded in the logical address space with file system information (volume) at the head. As an implementation example of the file system, there are methods such as UDF and ISO9660, and logical data recorded in the same way as a normal PC can be read using a directory and file structure.

  In the case of the present embodiment, the directory and file structure on the BD disc is a BDDATA directory placed directly under the root directory (ROOT). This directory is a directory in which Java (registered trademark) applications handled by the BD-ROM are recorded.

  The following two types of files are recorded under the BDDATA directory.

(1) XXX. JAR ("XXX" is variable, extension "JAR" is fixed)
It is a Java (registered trademark) archive file conforming to the Jar file specification (hereinafter referred to as a Jar file). A Jar file stores a plurality of files in a directory structure. One Jar file stores data such as one or more class files, a metafile indicating attributes of the Jar file, and an image. Basically, one Java (registered trademark) application is stored in one Jar file, and the Java (registered trademark) application can be executed on the Java (registered trademark) virtual machine. A Java (registered trademark) application is composed of one or more class files. When it is necessary to protect the copyright of a Java (registered trademark) application, one or more class files are encrypted. An unencrypted class file uses the extension “class”. The encrypted class file uses the extension “secure”. An encrypted class file cannot restore a Java (registered trademark) application using reverse engineering without a decryption key (described later).

(2) XXX. KEY ("XXX" is variable, extension "KEY" is fixed)
This is the decryption key required for decrypting the class file. The decryption key is encrypted with the master key and can be decrypted only by the playback device. The master key is held inside the playback device.

  FIG. 2 shows an example of the file structure in the Jar file. Under the root directory 401, a “META-INF” directory 402, a “NotProtected.class” file 403, and a “Protected.secure” file 404 are stored. A manifest file 405 corresponding to “MANIFEST.MF” is stored under the “META-INF” directory 402.

  A “NotProtected.class” file 403 is an example of a class file. The file conforms to the class file specification.

  The “Protected.secure” file 404 is an example of an encryption class file. Since it is encrypted, it can be considered that analysis by reverse engineering in the present situation is impossible.

  FIG. 3 is a diagram showing a layer model for reproduction control. The first layer in FIG. 3 is a physical layer and is supply control of a Jar file to be processed. As shown in the first layer, the Jar file to be processed uses not only the BD-ROM but also any recording medium such as HD, memory card, network, and communication medium as the supply source. The control of the supply sources such as HD, memory card, network (disk access, card access, network communication) is the first layer control.

  The second layer is a middleware layer. It is this second layer that defines how to execute the Jar file supplied in the first layer. For example, an operating system, a Java (registered trademark) virtual machine, a CPU-dependent native library, an execution file, and the like exist in the middleware layer.

  The third layer is a Java (registered trademark) layer. Java applications and class libraries that run on Java virtual machines exist in the third layer. A Java (registered trademark) application performs processing based on a written command and user input, and outputs a certain output, for example, audio or video. The class library provides an application programming interface (API) defined by a Java (registered trademark) profile for a Java (registered trademark) application. Java (registered trademark) applications and class libraries are written in Java (registered trademark) intermediate code, and are interpreted and executed by the Java (registered trademark) virtual machine in the second layer. A Java (registered trademark) application is composed of a plurality of class files, but needs to be converted into class objects in order to be interpreted and executed. A class object is also an internal representation of a class file.

  FIG. 4 is a block diagram showing a rough functional configuration of the playback apparatus. As shown in FIG. 3, the playback device includes a BD-ROM drive 601, a heap memory 104, an interpreter 103, a decrypter loader 602, a loader 105, a UO detection module 603, and an output engine 604.

  However, in the example of FIG. 4, the description will be made by taking an example in which the supply source of the Jar file is a BD-ROM. If it is a supply source, a means for capturing such information can be substituted for the BD-ROM drive 601.

  The BD-ROM drive 601 performs loading / ejecting of the BD-ROM and accesses the BD-ROM.

  The heap memory 104 stores Jar files and is necessary for the Java (registered trademark) layer. The heap memory 104 also stores a class object that is an internal format of a class file (a structure depending on a Java (registered trademark) virtual machine) described later.

  The interpreter 103 is the core of the Java (registered trademark) virtual machine, and interprets and executes byte codes in the class object. The interpreter 103 is an important part that directly affects the execution speed of the Java (registered trademark) application. An interpreter (not shown) equipped with a JIT compiler that converts bytecode into native code to speed up interpretation execution and products that implement part of the interpreter in hardware (not shown) are also available on the market. Yes.

  A loading determination unit (not shown) determines the necessity for generation (also referred to as loading) of class objects. The loading determination unit is interpreted and executed on the interpreter 103. When a class object is necessary, the interpreter 103 interprets and executes the loading determination unit.

  By executing the interpretation, the interpreter requests the descriptor loader or loader to load the class file on the heap memory 104. The loading determination unit has a cache of class objects on the heap memory 103. The loading determination unit is implemented as a ClassLoader class in the Java (registered trademark) layer or its inheritance class. Note that the loading determination unit may be partially implemented in the middleware layer for speeding up.

  The decrypter loader 602 generates a class object on the heap memory 104 after decrypting the encrypted class file using the decryption key existing in the BD-ROM. The decryption key recorded on the BD-ROM is encrypted with the master key. The decrypter loader 602 holds a master key, decrypts the decryption key encrypted by using the master key, and restores the class file encrypted using the decryption key to plain text Can do. The decrypter loader 602 is an important part for copyright protection.

  When the third party knows the master key held in the decrypter loader 602, detailed information on the decryption key encrypted with the master key is known, and copyright protection is provided to the third party. become unable.

  In that case, there is a risk that information about the master key may be disclosed by a third party, and there is a risk that the decryption key, its intermediate data, or plain text class file may be intercepted. This is necessary for security considerations.

  When the decrypter loader 602 is implemented in hardware, the master key can be concealed in hardware, and confidentiality is improved. After decrypting the encrypted class file, the decrypter loader 602 can temporarily place the plain text class file on the heap memory 104, but in this case, in order to make it difficult to intercept information in the heap memory 104, It is necessary to shorten the period during which the plain text class file is allocated to the heap memory as much as possible. After the use of the decrypted plain text class file is completed, the plain text class file must be immediately deleted from the heap memory 104 (for example, overwritten with 0). Don't be.

  The loader 105 converts the plain text class file into a corresponding class object and loads it onto the heap memory 104. The class object loaded on the heap memory 104 can be interpreted and executed by the interpreter 103.

  The UO detection module 603 detects a user operation performed on input means such as a remote controller (not shown) or a front panel of a playback device, and notifies the Java (registered trademark) virtual machine.

  The output engine 604 outputs audio and video required by a Java (registered trademark) virtual machine.

  When the interpreter 103 needs to execute a class file (encrypted class file or plain text class file) included in the application while interpreting and executing the application program, the interpreter 103 calls the loading determination unit and sets the object to be executed. Whether the class file to be loaded should be loaded by the decrypter loader 602 or the loader 105 is determined. This is started, for example, by calling the method loadClass (class name) of the ClassLoader class with the class name in parentheses as an argument.

  FIG. 5 shows an interface between the loading determination unit and the Java (registered trademark) virtual machine.

  For example, when the loading determination unit checks the extension of the class file to be loaded and determines that the target class file is encrypted (for example, the extension is “.secure” in FIG. 2), The API calls defineEncryptedClass (class name, encrypted class file) to request the middleware layer decryptor loader 602 to load the encrypted class file.

  When the loading determination unit determines that the class file to be loaded is not encrypted (for example, the extension is “.class” in the case of FIG. 2), the API defines class (class name, plaintext class). File) is called to request the middleware layer loader 105 to load the plaintext class file. Since the loading determination unit is stored as one of the class libraries and is interpreted and executed in response to the call, a request from the loading determination unit to the decrypter loader 602 / loader 105 is made through the interpreter 103.

  With reference to FIG. 6, the control flow in which the loading determination unit executed in the Java (registered trademark) layer returns the class object will be described.

  The loading determination unit that has requested the class object first searches whether a target class object is cached in a cache (not shown) (S601). The loading determination unit has a cache of class objects loaded by itself, and prevents the same class object from being loaded into the heap memory 104 more than once.

  When the target class object is found (S602), the class object is returned to the interpreter 103 (S603).

  When the loading determination unit does not find the target class object from the cache (S602), the class file defining the target class is acquired from the Jar file (S604).

  The class file is stored in the Jar file, and the class file can be acquired based on the necessary class name. For example, when the class name is “Abracadara”, the file name of the encrypted class file is “Abracabara.secure”, and the file name of the unencrypted class file is “Abracabara.class”. The loading determination unit selects a class file that is preferentially encrypted.

  The loading determination unit determines whether or not the class file acquired from the Jar file is encrypted (S605). Whether the class file is encrypted can be determined by examining the extension of the class file.

  When it is determined that the class file is encrypted, the loading determination unit requests loading of the encrypted class file (S606). The encryption class file is loaded by calling defineEncryptedClass (class name, encryption class file) which is an API. One class object on the heap memory 104 is acquired by loading the encrypted class file.

  If the loading determination unit determines that the class file is not encrypted, it requests the loading of the plaintext class file (S607). The plaintext class file is loaded by calling defineClass (class name, plaintext class file) which is an API. One class object is acquired on the heap memory 104 by loading the plaintext class file.

  After loading the newly created class object (S609), the loading determination unit returns the newly created class object (S610).

  The API call defineEncryptedClass (class name, encrypted class file) for loading the encrypted class file is processed by the decrypter loader 602. A control flow in which the decrypter loader 602 decrypts the encrypted class file and generates a class object on the heap memory 104 will be described with reference to FIG.

  The decrypter loader 602 decrypts the received encrypted class file and converts it into a corresponding plain text class file (S701). This decryption can be decrypted with a decryption key held internally by the decrypter loader 602.

  The decrypter loader 602 verifies the class file and checks whether the class file has been tampered with (S702).

  After verifying, the decrypter loader 602 converts the class file into a class object (S703). The class object is stored in the heap memory 104 in the form of a structure depending on the Java (registered trademark) virtual machine, and it is difficult to restore the class object to the class file even if information on the heap memory 104 is intercepted.

  The decrypter loader 602 avoids intercepting the class file while temporarily holding the class file subject to copyright protection. In order to avoid interception of the class file, it must exist in the second middleware layer and the first physical layer.

  The decrypter loader is configured not to pass a plaintext class file, a decryption key, or the like to the third Java (registered trademark) layer. In the middleware layer of the second layer, there is a risk that the heap memory is dumped during processing and the class file is intercepted. In order not to be intercepted, it is desirable to avoid software interaction with other modules such as the interpreter 103 and apply software obfuscation techniques. In addition to the application of software obfuscation technology, the CPU provides a secure execution mode. Software that runs in secure execution mode is more difficult to intercept the heap memory than other software, so if the CPU provides that functionality, the decrypter loader may run in secure execution mode. desirable.

  An API call defineClass (class name, plaintext class file) for loading a plaintext class file is processed by the loader 105. A control flow in which the loader 105 generates a class object from the plaintext class file will be described with reference to FIG.

  First, the loader 105 verifies the class file and checks whether the class file has been tampered with (S801).

  After verifying, the loader 105 converts the plain text class file into a class object (S802). Since the class object is stored in the heap memory 104 in the form of a structure depending on the Java (registered trademark) virtual machine, it is difficult to restore the class object to the class file even if information on the heap memory 104 is intercepted. is there.

  The loader 105 and the decrypter loader 602 have a lot in common with the generation of class objects. However, since the class objects generated by the loader do not need to pay attention to copyright protection, tuning for speeding up the implementation is not necessary. It becomes possible.

  Alternatively, since the process after the class file encrypted by the decrypter loader 602 is converted to a plain text class file is the same as the process by the loader 105, the plain text class file is converted into a class object in the decrypter loader. The loader 105 may be used for the process of converting into the heap memory and storing it in the heap memory.

  This can be realized, for example, by sharing a common library by a part of processing by the loader 105 and the decrypter loader 602.

  FIG. 9 is a block diagram showing a rough functional configuration of a mastering apparatus that performs mastering of a BD-ROM reproduced by the reproducing apparatus. As shown in FIG. 9, the mastering device includes a class file acquisition module 1101, an encryption determination unit 1102, a key generation unit 1103, a class file encryptor 1104, an archiver 1105, a master key acquisition module 1106, a decryption key encryptor 1107, and a BD- It consists of a ROM burner 1108.

  A class file acquisition module 1101 sequentially acquires class files that constitute a Java (registered trademark) application to be processed.

  The encryption determination unit 1102 determines the necessity of encryption of the class file acquired from the class file acquisition module 1101. The necessity of encryption can be determined by using the attribute information of the class file or by making an inquiry to the user before performing encryption.

  The key generation unit 1103 generates a decryption key and an encryption key. It is desirable to use a symmetric key encryption such as AES (Advanced Encryption Standard) or DES (Data Encryption Standard) in order to speed up the decryption in the playback device. When using symmetric key encryption, since the encryption key and the decryption key are the same, it is desirable to provide a mechanism (not shown) for keeping them secret.

  The class file encryptor 1104 encrypts the class file determined to be encrypted by the encryption determination unit 1102 with the encryption key generated by the key generation unit 1103.

  The archiver 1105 stores the class file in one Jar file. A class file that does not need to be encrypted is stored with an extension “class”, and an encrypted class file obtained from the class file encryptor 1104 is stored with an extension “secure”.

  The master key acquisition module 1106 internally holds the master key of the playback device and passes it to the decryption key encryptor 1107.

  The decryption key encryptor 1107 encrypts the decryption key with the master key. Since the decryption key is encrypted with the master key, the BD-ROM created by this process is extremely difficult to decrypt without the master key.

  The BD-ROM burner 1108 burns the Jar file and the encrypted decryption key onto one BD-ROM.

  An optical disc created from the mastering apparatus has the configuration shown in FIG. Without the master key, it is necessary to break the encryption algorithm used in the class file encryptor 1104 in order to decrypt the encrypted class file in the Jar file, which can be regarded as impossible to analyze with the reverse engineering technique. .

(Embodiment 2)
In this embodiment, the decryption key information is stored in the manifest file, the decryption key is obtained from the recording medium based on the stored decryption key information, and the decryptor loader is encrypted using the obtained decryption key. The class file is configured to be decrypted.

  In the first embodiment, in order to simplify the description of items that can be regarded as the same as or the same as the items described in Embodiment 1, detailed description thereof is omitted in this embodiment.

  A BD-ROM which is an example of a recording medium used in this embodiment is as described with reference to FIG.

  The following two types of files are recorded under the BDDATA directory.

(1) XXX. JAR ("XXX" is variable, extension "JAR" is fixed)
It is a Java (registered trademark) archive file conforming to the Jar file specification (hereinafter referred to as a Jar file). A Jar file stores a plurality of files in a directory structure. One Jar file stores data such as one or more class files, a metafile indicating attributes of the Jar file, and an image. Basically, one Java (registered trademark) application is stored in one Jar file, and the Java (registered trademark) application can be executed on the Java (registered trademark) virtual machine. A Java (registered trademark) application is composed of one or more class files. When it is necessary to protect the copyright of a Java (registered trademark) application, one or more class files are encrypted. An unencrypted class file uses the extension “class”. The encrypted class file uses the extension “secure”. An encrypted class file cannot restore a Java (registered trademark) application using reverse engineering without a decryption key (described later).

(2) XXX. KEY ("XXX" is variable, extension "KEY" is fixed)
This is an encryption format for one or more decryption keys necessary for decrypting class files. Multiple decryption keys can exist in the same file. The entire file is encrypted with the title key and can be decrypted by the playback device. The playback apparatus can use Copy Protection for Recordable Media (CPRM) to acquire the title key of the optical disc based on the device key possessed by the playback apparatus.

  FIG. 10 shows an example of the contents of the manifest file 405 shown in FIG. The grammar for describing information in the manifest file 405 is disclosed in the Jar file specification. The present embodiment is characterized in that a key “Key-ID” is added to a normal manifest file. The key “Key-ID” indicates the ID of the decryption key used for decrypting the file.

  By specifying a plurality of keys “Key-ID”, it is possible to decrypt using different decryption keys to decrypt different encrypted class files. The ID is set according to the order of 0 for the key and 1 for the second key. In the manifest file, the ID of the decryption key necessary for decryption is designated. The default key ID is set for the main session of the manifest file, and the key ID of the individual file is set for the individual session. For example, in the example of FIG. 10, the default key uses the decryption key corresponding to the key number 0, and the decryption key used for decrypting the “Protected.secure” file uses the decryption key corresponding to the key number 1. Is shown.

  The layer model for playback control is as shown in FIG. The first layer in FIG. 3 is a physical layer and is supply control of a Jar file to be processed. As shown in the first layer, the Jar file to be processed uses not only the BD-ROM but also any recording medium such as HD, memory card, network, and communication medium as the supply source. The control of the supply sources such as HD, memory card, network (disk access, card access, network communication) is the first layer control.

  The second layer is a middleware layer. It is this second layer that defines how to execute the Jar file supplied in the first layer. For example, an operating system, a Java (registered trademark) virtual machine, a CPU-dependent native library, an execution file, and the like exist in the middleware layer.

  The third layer is a Java (registered trademark) layer. Java applications and class libraries that run on Java virtual machines exist in the third layer. The Java (registered trademark) application performs processing based on user input and outputs audio and video. The class library provides an application programming interface (API) defined by a Java (registered trademark) profile for a Java (registered trademark) application. Java (registered trademark) applications and class libraries are written in Java (registered trademark) intermediate code, and are interpreted and executed by the Java (registered trademark) virtual machine in the second layer. A Java (registered trademark) application is composed of a plurality of class files, but needs to be converted into class objects in order to be interpreted and executed. A class object is also an internal representation of a class file.

  The configuration of the playback apparatus of the present embodiment is as shown in FIG. As shown in FIG. 4, the playback device includes a BD-ROM drive 601, a heap memory 104, an interpreter 103, a decrypter loader 602, a loader 105, a UO detection module 603, and an output engine 604.

  The BD-ROM drive 601 performs loading / ejecting of the BD-ROM and accesses the BD-ROM. The BD-ROM drive 601 has a device key defined by CPRM, and the BD-ROM drive 601 can restore the title key of the BD-ROM.

  The heap memory 104 stores Jar files and is necessary for the Java (registered trademark) layer. A class object which is an internal format of the class file is also stored in the heap memory 104.

  The interpreter 103 is the core of the Java (registered trademark) virtual machine, and interprets and executes byte codes in the class object. The interpreter 103 is an important part that directly affects the execution speed of the Java (registered trademark) application. An interpreter having a JIT compiler that converts byte code into native code in order to speed up interpretation execution and a product in which a part of the interpreter is implemented in hardware are also commercially available. In addition, since the interpreter is implemented in consideration of high speed, it is necessary to consider that it is easy to analyze from the viewpoint of copyright protection.

  A loading determination unit (not shown) determines the necessity for generation (also referred to as loading) of class objects. The loading determination unit is interpreted and executed on the interpreter 103. When a class object is necessary, the interpreter 103 interprets and executes the loading determination unit. By executing the interpretation, the interpreter requests the descriptor loader or loader to load the class file on the heap memory 104. The loading determination unit has a cache of class objects. The loading determination unit is implemented as a ClassLoader class in the Java (registered trademark) layer or its inheritance class. The loading determination unit is implemented as a ClassLoader class in the Java (registered trademark) layer or its inheritance class. Note that the loading determination unit may be partially implemented in the middleware layer for speeding up.

  The decrypter loader 602 receives a plaintext title key from the BD-ROM drive 601. When the BD-ROM drive 601 passes the title key to the decrypter loader 602, the key may be intercepted, so the BD-ROM drive 601 authenticates the decrypter loader 602, and the mutual encryption channel (SAC: Open the Secure Authenticated Channel) and receive the plaintext title key through the open encrypted channel. At this time, elliptic curve encryption (ECC) and Diffie-Hellman algorithm can be used to realize the encrypted channel.

  The decrypter loader 602 further receives the decryption key encrypted with the title key from the BD-ROM drive 601 that has read the BD-ROM. After decrypting the encrypted decryption key with the previously received title key, the encryption class file can be decrypted using this decryption key. After decrypting the encrypted class file into a plain text class file, a class object is generated on the heap memory 104.

  The decrypter loader 602 is an important part for copyright protection. If an encryption key, title key, decryption key, etc. used by the SAC in the decrypter loader 602 are intercepted by a third party, the copyright protection as a whole system cannot be performed. In addition, there is a risk that a plain text class file temporarily stored inside may be intercepted, and security considerations are required for implementation.

  The loader 105 converts the plain text class file into a corresponding class object and arranges it on the heap memory 104. The class object placed on the heap memory 104 can be interpreted and executed by the interpreter 103.

  The UO detection module 603 detects a user operation performed on an input unit (not shown) such as a remote controller (not shown) or a front panel of a playback apparatus, and indicates that the detected input has been received by Java (registered). (Trademark) Notify the virtual machine.

  The output engine 604 outputs required audio and video as a result of interpretation and execution by a Java (registered trademark) virtual machine.

  If interpretation is performed by the interpreter 103 and a class object is required, the interpreter performs interpretation by the loading determination unit. The request is started by calling a method loadClass (class name) possessed by the ClassLoader class.

  The interface between the loading determination unit and the Java (registered trademark) virtual machine is as shown in FIG. However, if the loading determination unit determines that the class file to be loaded is encrypted, it performs an API call defineEncryptedClass (class name, encrypted class file, key ID), and the class name, encrypted class file, The middleware layer decryptor loader 602 is requested to load the encryption class file by designating the key ID.

  If the loading determination unit determines that the class file to be loaded is not encrypted, it performs an API call defineClass (class name, plain text class file), specifies the class name and class file as arguments, and The load is requested to the loader 105 of the middleware layer. Since the loading determination unit is interpreted and executed, these requests are made through the interpreter 103.

  The control flow in which the loading determination unit executed in the Java (registered trademark) layer returns the class object is basically the same as that shown in FIG.

  However, if the loading determination unit determines that the class file is encrypted as a result of the determination in S605, and requests the loading of the encrypted class file (S606), the load of the encrypted class file is definedEncryptedClass, which is an API. Is different from that described in the first embodiment in that it is necessary to specify a class name, an encrypted class file, and a key ID as arguments (that is, defineEncryptedClass (class name, encryption API class, defineEncryptedClass, is called as the conversion class file and key ID). More done.

  Here, the class name is the name of the class object to be reproduced. The encryption class file is a file acquired from the Jar file. The key ID is a key ID corresponding to the class name obtained from the metafile shown in FIG. One class object on the heap memory 104 is acquired by loading the encrypted class file.

  The API call defineEncryptedClass (class name, encrypted class file, key ID) for loading the encrypted class file is processed by the decrypter loader 602. The control flow in which the decrypter loader 602 generates a class object on the heap memory 104 from the encrypted class file is basically the same as that shown in FIG.

  However, in this embodiment, since a plurality of decryption keys can be specified by the manifest file, the decrypter loader 602 receives the decryption key corresponding to the key ID specified by the argument in S701. Decrypt encrypted class file into plain text class file.

  For example, when the key ID is 0, the first decryption key is used. When the key ID is 1, the second decryption key is used.

  Since S702 and S703 overlap with the description of the first embodiment, a detailed description thereof is omitted here.

  The decrypter loader 602 avoids intercepting the class file while temporarily holding the class file subject to copyright protection. In order to avoid interception of class files, it must exist in the physical layer of the second layer or the first layer. The decryptor loader must not pass a plain text class file, a decryption key, or the like to the third Java layer. In the middleware layer of the second layer, there is a risk that a memory file is dumped during processing and the class file is intercepted. In order not to be intercepted, it is desirable to avoid some interaction with other modules such as the interpreter 103 and apply some software obfuscation technique. In addition to the application of software obfuscation technology, the CPU provides a secure execution mode. Since software executed in the secure execution mode is more difficult to intercept the memory than other software, it is desirable that the decrypter loader is executed in the secure execution mode when the CPU provides the function. .

  An API call defineClass (class name, plaintext class file) for loading a plaintext class file is processed by the loader 105. Since the specific description thereof has been described in Embodiment 1, the detailed description thereof is omitted here.

  The loader 105 and the decrypter loader 602 have a lot in common with the generation of class objects. However, since the class objects generated by the loader do not need to pay attention to copyright protection, tuning for speeding up the implementation is not necessary. It becomes possible. However, when considering the development cost, it is conceivable that the loader 105 and the decrypter loader 602 share a common library in terms of mounting.

  FIG. 11 is a diagram illustrating an example of a configuration of a mastering device that performs mastering of a BD-ROM played back by a playback device.

  As shown in FIG. 11, the mastering device includes a class file acquisition module 1101, an encryption determination unit 1102, a key generation unit 1103, a class file encryptor 1104, an archiver 1105, a CPRM module 1301, a decryption key encryptor 1107, and a BD-ROM burner. 1108.

  A class file acquisition module 1101 sequentially acquires class files that constitute a Java (registered trademark) application to be processed.

  The encryption determination unit 1102 determines the necessity of encryption of the class file acquired from the class file acquisition module 1101. The necessity of encryption can be realized by using attribute information of a class file or by inquiring a user before performing encryption.

  The key generation unit 1103 generates a decryption key and an encryption key. Since symmetric encryption is used, the encryption key and the decryption key are the same.

  The class file encryptor 1104 encrypts the class file determined to be encrypted by the encryption determination unit 1102 with the encryption key generated by the key generation unit 1103. The encryption key has a key ID, and the class file encryptor 1104 stores the ID of the key used.

  The archiver 1105 stores the class file in one Jar file. A class file that does not need to be encrypted is stored with an extension “class”, and an encrypted class file obtained from the class file encryptor 1104 is stored with an extension “secure”.

  Also, the key ID information of the encryption key used for encryption is received from the class file encryptor 1104, and the information is stored in the metafile. The metafile is MANIFEST.NET in the META-INF directory of the Jar file. It is an MF file.

  The CPRM module 1301 performs key generation and information holding necessary for CPRM. The CPRM module 1301 passes the title key to the decryption key encryptor 1107. In addition, information defined in the CPRM specification is passed to the BD-ROM burner 1108. The specification of CPRM can be obtained from, for example, “http://www.4centity.com/tech/cprm/”.

  The decryption key encryptor 1107 encrypts the necessary decryption key with the title key. The decryption key file is generated by concatenating with the title key after sequentially concatenating the decryption keys with the key ID = 0.

  The BD-ROM burner 1108 burns the Jar file, the decryption key file, and CPRM information on one BD-ROM.

  An optical disc created from the mastering apparatus has the configuration shown in FIG. The encryption class file in the Jar file cannot be analyzed using reverse engineering. Since the title key cannot be obtained without the device key defined by CPRM, it is necessary to decrypt the encrypted class file without using the decryption key in order to decrypt the encrypted class file in the Jar file. It is extremely difficult.

  The present invention can be used for copyright protection of a Java (registered trademark) application received via a recording medium such as an optical disk or an SD card or a communication medium such as the Internet.

The figure which shows an example of the data hierarchy of BD-ROM in embodiment of this invention The figure which shows an example of the file structure of the Jar file in this Embodiment The figure which shows an example of the layer of the software in this Embodiment The figure which shows an example of a structure of the reproducing | regenerating apparatus in embodiment of this invention The figure which shows an example of the interface between the loading determination part in this Embodiment, a decryptor loader, and a loader The figure which shows an example of the process of the loading determination part in this Embodiment. The figure which shows an example of the process in which the decrypter loader in this Embodiment produces | generates a class object The figure which shows an example of the process in which the loader in this Embodiment produces | generates a class object The figure which shows an example of a structure of the mastering apparatus in this Embodiment The figure which shows an example of the content of the metafile in this Embodiment The figure which shows an example of a structure of the mastering apparatus in 2nd embodiment of this invention. 1 is a diagram illustrating an example of a configuration of a playback device that performs copyright protection of a conventional Java (registered trademark) application. Diagram showing an example of processing to change from an encrypted class file to a class object

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Virtual machine 102 Java (registered trademark) application 103 Interpreter 104 Heap memory 105 Loader 107 Decryption class loader 108 Protected class file 109 Decryption key 401 Root directory 402 META-INF directory 403 Unencrypted class file 404 Encrypted Class file 405 Manifest file 601 BD-ROM drive 602 Decryptor loader 603 UO detection module 604 Output engine 1101 Class file acquisition module 1102 Encryption determination unit 1103 Key generation unit 1104 Class file encryptor 1105 Archiver 1106 Master key acquisition module 1107 Decryption key Encrypter 1108 BD-ROM burner 1301 C RM module

Claims (10)

An application execution device that executes an application described in an object-oriented program,
A decryptor loader that decrypts the encrypted class file included in the input application and converts it into a plain text class file, then converts it into a class object and loads it into the heap memory, and classifies the plain text class file in the input application A virtual machine having a loader that converts into an object and loads it into the heap memory, and an interpreter that interprets and executes the class object loaded into the heap memory;
A loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plaintext class file;
In the loading determination unit, when it is determined that the class file to be executed by the interpreter is an encrypted class file, the class file is sent to the decryptor loader,
An application execution apparatus configured to send the class file to the loader when the loading judgment unit judges that the class file sent to the virtual machine is a plain text class file. The application is recorded in a recording medium, and the recording medium encrypts and records a decryption key for decrypting an encrypted class file included in the application with a master key, and the decrypter loader Holds the master key in advance, and when the encrypted class file is input, obtains an encrypted decryption key corresponding to the encrypted class file from the recording medium,
2. The application according to claim 1, wherein the encrypted decryption key is decrypted using the master key held in advance, and the encrypted class file is decrypted using the decrypted decryption key. Execution device. The decrypter loader obtains the encrypted decryption key from the recording medium, decrypts the encrypted decryption key using the master key before the encrypted class file is input, The application execution apparatus according to claim 1, wherein: The application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key and the decryption key Record a metafile that describes the information to retrieve
The loading determination unit includes information for extracting a corresponding decryption key based on a metafile describing information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. To the decryptor loader
The decryptor loader acquires the encrypted decryption key from the recording medium based on information for extracting the decryption key,
The application execution apparatus according to claim 1, wherein the encrypted class file is decrypted using a decryption key decrypted using a title key held by the decryptor loader. The application execution apparatus according to claim 4, wherein the decrypter loader holds a decryption key acquired from the recording medium. An application execution device that executes an application described in an object-oriented program,
A decryptor for decrypting the encrypted class file included in the input application and sending the plaintext class file to the loader, and a plaintext class file in the input application or a plaintext class file decrypted by the decryptor A virtual machine having a loader for converting into a class object and loading it into a heap memory and an interpreter for interpreting and executing the class object loaded into the heap memory;
A loading determination unit that determines whether a class file to be executed by the interpreter is an encrypted class file or a plain text class file;
When it is determined by the loading determination unit that the class file to be executed by the interpreter is an encrypted class file, the encrypted class file is sent to the decryptor,
An application execution apparatus configured to send the class file to the loader when the loading judgment unit judges that the class file sent to the virtual machine is a plain text class file. The application is recorded in a recording medium, and the recording medium is recorded by encrypting a decryption key for decrypting an encrypted class file included in the application with a master key,
The decryptor holds the master key in advance, and when the encrypted class file is input, obtains a decryption key for decrypting the encrypted class file from the recording medium,
7. The obtained encrypted decryption key is decrypted using the master key held in advance, and the encrypted class file is decrypted using the decrypted decryption key. Application execution device. 8. The decryptor according to claim 7, wherein the decryptor acquires the encrypted decryption key from the recording medium and caches the decryption key before the encrypted class file is input. Application execution device. The application is recorded in a recording medium, and the recording medium is a decryption key for decrypting an encrypted class file included in the application, the decryption key encrypted with a title key and the decryption key Record a metafile that describes the information to retrieve
The loading determination unit includes information for extracting a corresponding decryption key based on a metafile describing information for extracting a decryption key corresponding to the encrypted class file included in the application when the application is executed. To the decryptor
The decryptor obtains the encrypted decryption key from the recording medium based on information for extracting the decryption key,
7. The application execution apparatus according to claim 6, wherein the encrypted class file is decrypted using a decryption key decrypted using a title key held by the decryptor. The application execution apparatus according to claim 9, wherein the decryptor holds a decryption key acquired from the recording medium.

Images