WO2008018310A1

WO2008018310A1 - Application execution device, method, and program

Info

Publication number: WO2008018310A1
Application number: PCT/JP2007/064851
Authority: WO
Inventors: Germano Leichsenring; Hidetaka Ohto; Tomonori Nakamura; Kazufumi Miyatake
Original assignee: Panasonic Corporation
Priority date: 2006-08-09
Filing date: 2007-07-30
Publication date: 2008-02-14
Also published as: JP2009258772A

Abstract

An application execution device includes a physical layer, a middleware layer, and a Java layer as control layer. A decryptor for decrypting an encrypted class file to obtain a plain text file exists in the physical layer and the middleware layer. In the physical layer and the middleware layer, there exists a middleware loader described by a native code or a hardware loader configured by a hardware element. These loaders convert intermediate codes constituting the plain class file obtained by decryption into byte codes and store the byte codes obtained by the conversion in a heap memory. Thus, the plain text class file is passed in the physical layer and the middleware layer, which maintains confidentiality.

Description

Specification

Application execution apparatus, method, and program

Technical field

[0001] The present invention belongs to the technical field of application execution technology.

Background art

[0002] Application execution technology is technology that causes a virtual machine to execute an application by generating a class object that is an instance from a class file that defines the program structure of the application and providing it to a virtual machine. Industrial products that are applied products include an application execution device having a function as a BD-ROM playback device, and an embedded program incorporated in the BD-ROM playback device. The application execution method performed by these industrial products during operation is also a product of the application execution technology.

[0003] A class file is a class structure described based on the grammar of an object-oriented programming language such as Java (TM) language, and is composed of intermediate code. A class object is generated by converting such intermediate code into bytecode. As described above, the process of converting the intermediate code to the executable code and generating the class object in the heap memory of the virtual machine is called “load”. A program that performs such a loading process is called a “loader”.

[0004] In order to protect the copyright of such applications, the class files that make up the application are encrypted and recorded on a recording medium, and the application execution device prior to loading the class files, there is a need force ^s decrypts the hunt class file.

For example, Non-Patent Document 1 discloses a method of encrypting a class file and a method of decrypting an encrypted class file at the time of execution. The prior art described in this document will be described below.

[0005] When realizing the copyright protection of an application, a class file to be protected is distributed in an encrypted form. Conventional application execution devices include a decryptor and a client. A lath loader is provided. The decryptor decrypts the encrypted class file. If a plain text class file is obtained by decryption, the decryptor passes the class finale to the class loader. The class loader creates a class object on the heap memory based on this class file.

[0006] In addition to the method described above, a method of encrypting the entire distribution file by applying copy protection of conventional content is also conceivable.

Non-Patent Document 1: "Java (TM) World", online, Internet URL: http: 〃 www.java world.com/javaworid/javaqa/2003_05/01_qa_0509_jcrypt.html>

Disclosure of the invention

Problems to be solved by the invention

By the way, in the above prior art, an interface for passing a plaintext class file between the decryptor and the loader is clearly defined. If an illegal program that intercepts exchanges via this interface is running, the plaintext class file may be scammed when the plaintext class file is passed between the decryptor and the class reader. . The plain text class file is written in intermediate code, and if this intermediate code is analyzed, the source program that is the base, that is, the object-oriented programming language such as Java (TM) language, etc. The program structure of the described source program can be easily estimated. In this way, with the prior art as described above, if the program structure is inferred by a childish level reverse analysis to the extent that the plaintext class file delivery interface is understood, the vulnerability will be reduced. Have it!

[0008] On the other hand, in a device that decodes and plays back a coded AV stream, such as a BD-ROM playback device, the physical layer and middleware layer strengths of the control layer structure are robust. Often protected by technology. However, since plain text classifiers are exchanged between the class loader and the decryptor, and the force and exchange follow the above-mentioned interface, no matter how strong the tamper resistance technology is applied to the physical layer and middleware layer. It is impossible to fill the security loopholes because it is impossible to eliminate the exchange of plaintext class files between the class loader and the decryptor.

[0009] An object of the present invention is to provide a robust tamper resistance technique for the physical layer and the middleware layer. In the layer structure that is protected, the interface in the loader is clarified! /, So if the plaintext class file is scammed, an application execution device that can close the security loophole is provided. That is.

Means for solving the problem

[0010] An application execution device that is effective in the present invention for solving the above-described problems is a decryptor that obtains a plaintext class file by decrypting an encrypted class file, and a plaintext class obtained by decoding. The intermediate code that configures the file is converted to byte code, the byte code obtained by the conversion is stored in the heap memory, and the byte code stored in the heap memory is converted into native code. The loader is a middleware program written in native code, or a hardware module composed of hardware elements.

The invention's effect

[0011] In the application execution apparatus as described above, the decryptor often has an original use of decrypting an encrypted AV stream. In particular, in a BD-ROM playback apparatus or the like, the processing speed is increased. Therefore, it is often implemented in hardware. On the other hand, in the application execution device according to the present invention, when a call to the load class API is instructed, the middleware layer or the hardware layer delivers the plain text class file from the decryptor to the loader, and then the loader A class object will be created in memory. Since the class object consists of bytecodes and depends on the internal format of the virtual machine, it is difficult to analyze the program structure.

[0012] In the case of a BD-ROM playback device or the like, the processing in the middleware layer or the hardware layer is usually performed with a tamper-proof technology and highly confidential, so that it is highly sophisticated. As long as reverse technology is not applied, plaintext class files will not be stolen. In the present invention, in the layer structure of the BD-ROM playback device, a place where the confidentiality of the plaintext class file is maintained is selected for the delivery of the plaintext class file. This level of reverse analysis does not reveal the confidentiality of plaintext class files. [0013] As described above, in the present invention, the physical layer and the middleware layer are protected by a strong tamper-resistant technology and have a layer structure such as! It is possible to close the security loopholes that can be used and to strengthen the protection of applications.

Here, although optional, the following improvements can be made to the application execution device. That is, the loader is a decryptor loader for an encrypted class file, the application execution device includes a class loader defined by a class structure, and the class loader receives a plain text class file. Converts intermediate code to byte code and stores the byte code obtained by the conversion in heap memory, and includes a judgment method. Class file power S corresponding to the argument of S, it is determined whether it is a plain text class file or an encrypted class file, and if it is a plain text class file, byte code is sent to the class loader. If it is an encrypted class file, the decryptor log It is also possible to cause the reader to perform conversion to bytecode.

[0014] Since this application execution device employs a redundant configuration in which loaders are provided twice, compatibility with the internal configuration of a general Java (TM) platform can be maintained.

Based on the determination of whether the call argument corresponds to the encrypted class file, it determines which loader to use, so the encrypted class file and the class file and Even in a mixed case, the description at the time of calling the load class on the application side will not change, and it is possible to avoid complication of the application description.

[0015] With the above configuration of the application execution device, even when an application is configured from a plurality of class files, loading is performed in units of class files, and the power of the class file in an encrypted format is not encrypted. Either the loader or the class loader loads the class file depending on whether it is a computerized format, which increases confidentiality when executing the application.

[0016] In the above configuration, a class file that does not require copyright protection is replaced with a normal class file. As a result, there is room for tuning the loader when loading plaintext class files. By making improvements within the range of power and room, it is possible to improve the loading performance of ordinary class files.

Brief Description of Drawings

FIG. 1 is a diagram showing a configuration of a BD-ROM (also referred to as a BD) that is an example of a recording medium used in the present embodiment.

FIG. 2 is a diagram showing an example of a file structure in a JAR file.

FIG. 3 is a diagram showing a hardware configuration of an application execution apparatus that is effective in the present invention.

FIG. 4 is a diagram showing a layer model for playback control.

FIG. 5 is a diagram showing the relationship between the class loader 14 and the loading determination method 16 in more detail.

FIG. 6 is a diagram showing the relationship between the class loader 14 and the loading determination method 16 in more detail.

FIG. 7 is a flowchart showing a processing procedure when calling the Load Class of the loading determination method 16 and the interpreter 12.

FIG. 8 is a flowchart showing the procedure of the middleware loader 15.

FIG. 9 is a diagram showing a hardware configuration of an application execution device according to a second embodiment.

FIG. 10 is a diagram showing the positioning of the hardware loader 22 according to the second embodiment.

FIG. 11 is a diagram showing the positioning of a loading determination routine 18 according to the third embodiment.

FIG. 12 is a block diagram showing a general functional configuration of a mastering device that performs mastering of a BD-ROM played back by a playback device. It is.

[FIG. 14] A diagram in which constituent elements with improvements specific to the sixth embodiment are extracted, and exchanges between these constituent elements are added. In other words, the arrow force S added between the components in this figure, and the interaction between these components are schematically shown. FIG. 15] A diagram showing an example of the configuration of a BD-ROM mastering device played back by the playback device shown in the sixth embodiment.

Explanation of symbols

1 BD-ROM drive

2 HD drive

3 Memory card drive 3

4 Network I / F section

5 CPU

6

7 AV playback engine

8 RAM

9 Embedded program ROM

10 UO detection device

11

13 Heap memory

14 Class loader

15 middleware loader

22 Nodeware loader

51 Get class file-

52 Encryption judgment part

53 Key generator

54

55 Archiver

56 Master Key Acquisition Monore

57 Decryption Key Encryptor

58 BD-ROM burner

63 Key generator

66 CPRM modules 201 Norreto Directory

202 META-INF directory

203 Unencrypted class file

204 Encrypted class file

205 Manifest Juinore

BEST MODE FOR CARRYING OUT THE INVENTION

[0019] (Embodiment 1)

Hereinafter, embodiments of an application execution apparatus that are useful for the present invention will be described with reference to the drawings. This application execution device has a function as a BD-ROM playback device, and provides a Java (TM) application supplied on the BD-ROM for execution by a virtual machine. Since the BD-ROM corresponds to the execution target of the application execution device, the internal configuration of the BD-ROM will be described prior to the description of the application execution device.

The first row in the figure shows the appearance of the BD-ROM. The BD-ROM has a spiral recording area formed from the inner periphery to the outer periphery, as in the case of DVDs and CDs, for example.

In the second row, the spiral recording area is drawn in the horizontal direction. In the second stage, the recording area has a logical address space in which logical data can be recorded between the inner lead “in” and the outer lead “out”. Inside the lead-in is a special area called BCA (Burst Cut Area) that can only be read by a drive. Since this area cannot be read from the application! /, It is often used for copyright protection technology, for example.

In the logical address space, video data and the like are recorded with file system information at the head. There are file systems such as UDF and ISO9660. By using this file system, the logical data recorded in the recording area as described above can be read.

The third row shows the directory and file structure of the recording area. BD-ROM The directory and file structure are the BDDATA directory and the BDMV directory directly under the root directory (ROOT). The BDDATA directory is a directory in which extreme Java (TM) applications are recorded on the BD-ROM. The BDMV directory is a directory in which an encrypted AV stream (YYY.M2TS) handled by the BD-ROM is recorded.

[0022] The following two types of files exist under the BDDATA directory.

(1) XXX.JAR ("XXX" is variable, extension "JAR" is fixed)

This is a Java (TM) archive file. Java (TM) archive file is a ZIP file format specialized for Java (TM), and its contents can be confirmed by commercially available ZIP expansion software. Here, “XXX” is variable and the extension “JAR” is fixed (hereinafter referred to as JAR file). A JAR file stores multiple files in a directory structure. One JAR file contains one or more class files, metafiles indicating the attributes of the JAR file, and data such as images. Basically, one Java (TM) application is stored in one JAR file, and the Java (TM) application can be executed on the Java (TM) virtual machine. A Java (TM) application consists of one or more class files. If it is necessary to protect the copyright of a Java (TM) application, one or more class files are encrypted. An unencrypted class file uses the extension “cl _ass ”. The encrypted class file uses the extension “secure”. An encrypted class file cannot be restored without a decryption key (described later).

[0023] (2) ΧΧΧ · ΚΕΥ ("ΧΧΧ" is variable, extension "ΚΕΥ" 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. The file structure of the JAR file is as follows: “META-INF” directory 202, “NotProtected.classj finale 203, and“ Protected.secure ”finale 204 exist under the root directory 201! /. In addition, a manifest file 205 corresponding to “MAMFEST.MF” is stored under the “META-INF” directory 202! /. [0024] The “N ₀ tProtected.class” file 203 is a non-encrypted class file and stores a structure that defines a Java (TM) application that can be executed on the virtual machine. . The Java (TM) application defined in this class file is a Java (TM) Xlet controlled through the Xlet interface. The Xlet interface takes four states at any time: “loa ded, paused, active, destroyed”.

[0025] The “Protected.secure” file 204 is an example of an encrypted format class file. Like the “NotRotated.class” file 203, the class structure that defines the Java (TM) application is encoded. Is stored in. Because it is encrypted, it can be considered that this file cannot be analyzed by reverse engineering.

The “MAMFEST.MF” file 205 is a file in which the attributes of the JAR file, the hash value of the class file and the data file are described. The attributes of the JAR file include the application ID given to the Java (TM) application and the class file name that should be executed first in order to execute the JAR file. If the above attribute does not exist, the Java (TM) application that is an instance of the class file in the JAR file is not executed.

[0026] Above; ^ 7 Kyotsuna JAR Finale (MANIFEST. MF, NotProtected.class, Protected.secure), XXX.KEY file, AV stream is recorded on BD-ROM according to the file structure and directory structure Therefore, the application execution device can read MAMFEST.MF, NotProtected.class, and Protected.secure into the memory by requesting a system console for opening the file.

[0027] File open is a process of searching a directory by a file name given at the time of a system call, securing a FCB (File Control Block) if a file exists, and returning a file handle number. The FCB is generated by copying the contents of the directory entry of the target file onto the S-memory.

This is the description of the recording medium on which the present invention is predicated.

(Application execution device)

Next, an embodiment of an application execution apparatus that is effective in the present invention will be described. The application execution apparatus which is effective in the present invention has an internal configuration as shown in FIG. 3, and can be used as a BD-ROM playback apparatus. [0028] The application execution apparatus according to the present invention fully implements Java (TM) 2Micro_Edition (J2ME) Pers onal Basis Profile (PBP 1.0) and Globally Executable MHP specification (GEM 1.0.2) for package media targets. Java (TM) platform consisting of

FIG. 3 is a diagram showing a hardware configuration of the application execution apparatus that is effective in the present invention. As shown in this figure, the application execution device consists of BD-ROM drive 1, HD drive 2, memory card drive 3, network I / F unit 4, CPU5, decryptor Chip6, AV playback engine 7, RAM8, embedded program Consists of ROM9 and UO detection device 10.

(BD-ROM drive 1)

The BD-ROM drive 1 performs loading / ejection of a BD-ROM having an internal configuration as shown in FIG. 1 and accesses the BD-ROM.

[0029]

(HD drive 2)

HD drive 2 is a hard disk drive that can store class files supplied with BD-ROM and equivalent class files.

(Memory card drive 3)

Memory card drive 3 is a drive device that can be loaded with a semiconductor memory card in which a class file supplied with BD-ROM and an equivalent class file are written.

Yes

(Network I / F part 4)

The network I / F unit 4 executes a protocol stack for network connection, and causes the application execution apparatus to recognize the drive included in the computer on the network as the network drive 4a.

(CPU5)

The CPU 5 executes the native code stored in the embedded program ROM 9. (Decryptor Chip6)

The decryptor Chip 6 holds a master key, decrypts the encryption / decryption key by using the master key, obtains the decryption key, and uses this decryption key to decrypt the encrypted form Is restored to a plain text file. The decryption key recorded on the BD-ROM is recorded on the BD-ROM in the state of being encoded with the master key! The encrypted file recorded on the BD-ROM has a stream file storing the AV stream and the class file and the file S as described above, and the decryptor Chip 6 mainly stores the stream file. It is provided in the application execution device for the purpose of decryption. However, the present invention is not limited to this, and decryption can be performed even with class files of the same encryption format.

[0030] Further, when decrypting the encrypted class file, the decryptor Chip 6 caches the decryption key obtained by decrypting the decryption key encrypted with the master key. This cached decryption key is used to decrypt the encrypted class file. This makes it possible to omit the decryption process using the master key as described above when the same decryption process as the encrypted class file is performed again. . The use of such a cache can significantly reduce the time required to decrypt an encrypted class file.

(AV playback engine 7)

The AV playback engine 7 plays back the AV stream obtained by decoding the decryptor Chip 6 when requested by the Sjava (TM) virtual machine for audio and video playback, and outputs the audio video.

(RAM8)

The RAM 8 stores data necessary for the CPU 5 to perform data processing. (ROM9 for embedded program)

ROM9 for embedded programs stores embedded programs such as interpreters, native libraries, class libraries, etc. that are preinstalled in application execution devices.

[0031] (UO detection device 10)

The UO detection device 10 detects and notifies a user operation performed on an input device such as a remote control or a front panel of a playback device. This notification is made by generating a UOP according to the interrupt generated by the interrupt handler in the device driver corresponding to these input devices. UOP is a key matrix provided on the remote control or front panel. This is an event (UOP event) that occurs when a key press is detected in a service, and has an attribute corresponding to the pressed key. Specifically, when the interrupt handle of the device driver corresponding to the remote control or front panel detects a key press by key sense for the key matrix, the UOP event is generated by generating an interrupt signal based on the key press. Is generated.

The above is the hardware configuration of the application execution apparatus. Next, the software configuration based on the above hardware configuration will be described.

FIG. 4 shows a layer model for playback control.

(1st layer)

The first layer in the figure is a physical layer, and includes a supply control layer for the JAR file to be processed and a hardware control layer. The internal structure of the playback device shown in Fig. 3 exists in this physical layer. For supply control of Java (TM) applications, the target JAR file is not only BD-R OM but also any recording media such as HD, memory card, network, embedded program ROM, and communication media. Control of these HDs, memory cards, networks, and embedded program ROM (disk access, card access, network communication) is called “supply control”. There are several types of supply sources. In the following explanation, BD-ROM is selected as the JAR file supply source.

[0033] (Second layer)

The second layer is a middleware layer. It is this second layer that specifies how to execute the JAR file supplied in the first layer! /. For example, operating systems, Java (TM) virtual machines, native libraries, and executable files exist in the middleware layer. The native library consists of native code, is in a format dependent on the first layer CPU, and is executed directly by the CPU. As this native library, the middleware loader described later exists in the second layer.

[0034] The virtual machine includes a user class loader that reads a class file from a BD-ROM, a heap memory that stores an instance corresponding to the class file as a Java (TM) application, a thread, and a Java (TM) stack. Here, a thread is a logical execution subject that executes a method in a Java (TM) application. Operates using arguments stored in the command stack as operands, and stores the result in a local variable or operand stack. Method execution by a thread is performed by converting the byte code that forms the method into the CPU's native code and then issuing it to the CPU.

(3rd layer)

Layer 3 is a Java (TM) layer. The Java (TM) application, class library, and class loader executed on the Java (TM) virtual machine exist in the third layer.

[0035] The Java (TM) application performs processing based on the described command and user input, and outputs a certain output, for example, audio or video. As described above, the Java (TM) application is supplied by the BD-ROM while being stored in the JAR file.

(Java (TM) application)

A Java ™ application is composed of a plurality of class files. In this class file, Java (TM) applications and class libraries are defined in Java (TM) intermediate code. A class object is generated by converting such intermediate code into Neut code.

[0036] (Class library)

The class library provides an application product programming interface (API) for Java (TM) applications. This API is defined in the Java (TM) profile. The class library is stored in ROM9 for embedded programs and is loaded as necessary.

A characteristic of this layer structure is that it has the same function as a class loader composed of bytecode, and exists in the second layer of middleware loader power composed of native code.

FIG. 5 is a diagram in which software elements related to the class loader 14 and the middleware loader 15 are added to the control layer shown in FIG. The arrows in the figure symbolically indicate the plaintext class file, the encrypted class file, the encrypted AV stream power, and the power provided to the heap memory 13 or AV playback engine 7 via any path. The arrows yl and y2 are the supply path of the encrypted AV stream, and the encrypted AV stream is transmitted to the AV via the decryptor Chip6. It can be seen that it is supplied to the playback engine 7 and used for playback output.

Arrows y3 and y4 symbolically indicate the supply path of the plaintext class file. The plain text class file is supplied to the heap memory 13 by the class loader 14. Arrows y5, y6, and y7 schematically show the supply path of the encrypted class file. The encrypted class file is supplied to the heap memory 13 via the decryptor Chip 6—middleware loader 15 and is received. Hereinafter, the interpreter 12, heap memory 13, class loader 14, and middleware loader 15 will be described.

(Interpreter 12)

The interpreter 12 interprets and executes the byte code constituting the class object, and instructs the class loader 14 and the middleware loader 15 to load in response to the class file being called by the class object. Interpreter 12 is an important part that directly affects the execution speed of Java (TM) applications, and can be implemented as an interpreter with a JIT compiler that converts bytecode into native code. . By having such a JIT compiler, it is possible to speed up interpretation execution. A part of the interpreter can be implemented using hardware.

(Heap memory 13)

The heap memory 13 is a memory in which class objects are stored by the class loader 14 and the middleware loader 15. Since the class object is stored in the heap memory 13 in the form of a structure that depends on the Java (TM) virtual machine, the class object is restored to the class file even if the information on the heap memory 13 is intercepted. It is difficult.

(Class loader 14)

The class loader 14 is a system application and is defined by a class structure according to the grammar of the object-oriented programming language. When calling a class file from the heap memory 13, the plaintext class file is converted into a corresponding class object and loaded onto the heap memory 13.

(Middleware loader 15)

Like the interpreter 12, the middleware loader 15 is a middleware program composed of native code, and the encrypted class file is decrypted by the decryptor Chip6. If so, a class object is generated on the heap memory 13. There are two types of encrypted class files that can be loaded: those that make up a Java (TM) application and those that make up a class library. The middleware loader 15 uses the decrypted plaintext class file because it is difficult to intercept information in the heap memory 13 and it is necessary to shorten the period during which the decrypted plaintext class file is allocated to the heap memory. After the above is completed, the plain text class file is deleted from the cache of the heap memory 13 immediately. This deletion is done by overwriting the plain text class file in the heap memory with, for example, a null code (value 0).

[0039] The middleware loader 15 is configured by native code, and is directly executed by the CPU in the application execution device. Therefore, the application operating on the virtual machine does not correspond to the class library. Since it is written in native code, it corresponds to a component of a virtual machine, just like an interpreter. That is, it can be seen that the middleware loader 15 is incorporated as a component inside the virtual machine that does not exist on the virtual machine. In a general implementation of a BD-ROM playback device, a strong tamper-resistant technology is applied to the platform portion of the virtual machine. Therefore, the middleware loader 15 in this embodiment is part of this strong tamper-resistant technology. Will enter. By placing a loader for reading class files into a tamper-resistant technology, the protection of encryption format class files is as strong as the protection of AV streams.

[0040] The class loader 14 of this embodiment is characterized in that a new method inheriting the function of the class loader 14, that is, a loading determination method is provided. FIG. 6 is a diagram showing the relationship between the class loader 14 and the loading determination method 16 in more detail. In other words, the class loader 14 according to the present embodiment has the same function as the conventional class loader, but the loading determination method 16 is newly added as a method inheriting the function of the class loader 14! / The point is new!

Hereinafter, the loading determination method 16 will be described.

(Loading judgment method 16)

The loading determination method 16 is a successor class of the ClassLoader class that is the base of the class loader 14, and when a class file is called, the class object to be executed is loaded. The power to load the project from its own internal cache 17, the force to be loaded by the middleware loader 15, and the force to be loaded by the class loader 14 are determined.

[0042] Specifically, the loading determination method 16 includes a program area that defines the processing to be performed by the virtual machine, and a variable area. This variable area is used in the program area. Various local variable storage areas are secured on the RAM 8. Within the variable area, a cache area of 17 that can store a predetermined number of class objects is declared, and the cache is allocated on the RAM 8 when the loading judgment method 16 is executed. . Since the loading determination method 16 has a cache 17 therein, the latest predetermined number of class objects loaded in the past can be stored in the cache 17. When a class file is called, a search is performed to determine whether the class object to be called exists in this cache. If the class object to be called exists in this cache 17, For example, loading is omitted by transferring this class object from the cache 17 to the heap memory 13 as indicated by an arrow cl. By doing this, the same class file that has been loaded once can be loaded at high speed. As a result, access to the BD-ROM, etc. can be omitted, so the time from when the LoadClass method is called until the target class object is obtained in the heap memory 13 can be greatly reduced. Can do.

Here, the class file is called by, for example, calling a method loadClass (class name) of the ClassLoader class with the class name in parentheses as an argument.

If the target class file does not exist in the cache 17, it is determined whether the target class file is in encrypted format or plain text format. If the target class file is in the encrypted format and the extension attached to it is “.secure”, it is sent to the call interpreter 12 of the API de fmeEncryptedClass (class name, encrypted class file), Request the middleware loader 15 of the middleware layer to load the encryption class file. If the target class file is in plain text format and the extension is ".class", the interpreter 12 is called to call the API defineClass (class name, plain text class file), and the plain text class file is loaded. Ask loader 14. [0044] An arrow gO in the figure symbolically shows a call to the method LoadClass. Arrows gl, g2, and g3 in the figure symbolically indicate the flow of instructions to the class loader 14. It can be seen that the instruction to the class loader 14 is made by calling define Class via the interpreter 12—loading determination method 16—interpreter 12. Calling this defineClass, as indicated by an arrow y 4, the class loader 14, this generating a class object in the heap memory 13 and the force ^s Wakakaru.

[0045] Arrows gl, g2, and g4 in the figure symbolically indicate the flow of instructions to the middleware loader 15. It can be seen that the middleware loader 15 is instructed by calling defmeEncryptedClass via the interpreter 12—loading determination method 16—interpreter 12. By calling this defmeEncryptedClass, the middleware loader 15 can generate a class object in the heap memory 13 as indicated by an arrow y7.

[0046] Regardless of whether the class loader 14 or the middleware loader 15 is instructed, the class object that constitutes the currently executing application calls the method LoadClass as indicated by the arrow gO to the interpreter 12. Thus, it can be seen that whether the class loader 14 or middle loader 15 is loaded is determined by the loading judgment method 16 in the class loader 14. Based on this determination result, it can be seen that interpreter 12 is calling defineEncryptedClass and defineClass.

[0047] There is a loading determination method 16 that is a powerful inheritance method of the class loader 14, and this loading determination method 16 determines which of the class loader 14 and the middleware loader 15 generates a class object. Therefore, Java (TM) applications executed in a virtual machine need only be loaded without paying particular attention to whether the class file to be loaded is in encrypted form or compared. .

[0048] This completes the description of the loading determination method 16.

(Procedure of Talking Determination Method 16)

Hereinafter, the software implementation of the loading determination method 16 will be described. The loading decision method 16 can be implemented by describing the algorithm of the flowchart in Fig. 7 in the Java (TM) language, which is an object-oriented programming language, compiling, and generating a class file. FIG. 7 is a flowchart showing a processing procedure of the loading determination method 16. When this flow chart is executed, the process proceeds to the determination steps of Step S1, Step S2, and Step S3. Step S1 is a determination of whether or not a class object with the class name corresponding to the argument exists in the cache. Step S2 has a file name corresponding to the argument and has an extension of “.secure”. This is a determination of whether or not a class file with is present in the JAR file.Step S3 has a file name corresponding to the argument and a class file with an extension of “.class” Judgment whether or not it exists in the JAR file.

[0050] The determination in step S 1 is that the loading determination method 16 has its own power cache, and the loaded class object may be stored in the cache. This is the force that prevents heap memory 13 from being loaded.

To determine whether it exists in the JAR file, add the extension of .class or .secure to the name of the class, determine the file name of the class file to be loaded, This is done by searching for a file with the file name.

[0051] For example, if the class name is “Abracadabra”, the file name of the encrypted class file will be “Abracadabra. Secure”, and the class name of the unencrypted class file (“Abracadabra” , class "ί こ d.

If step S I is Yes, the class object in the cache is sent to the heap memory in step S4. If step S2 is Yes, the API of defmeEncryptedClass (class name, encrypted class file) is called in step S5. If step S3 power Wes, API of defmeClass (class name, encryption class file) is called in step S6. After making an API call in either step S5 or step S6, wait for the class object to be obtained in the heap memory in step S7, and if the class object is obtained, the class object is cached in step S8. After storing, the address of the class object in the heap memory is returned to the interpreter 12 in step S9.

[0052] The determination in steps S2 and S3 is performed by first searching for an encrypted class file. The plaintext class file is searched first, so if both the encrypted class file and the plaintext class file exist in the JAR file, the loading judgment method 16 is preferentially encrypted class file. Select. By such priority selection, for example, if it exists in the plaintext class file of the trial version, the class file of the encrypted version of the product version, and the SJAR file, it is automatically based on the class file of the encrypted form. A class object will be created. In this way, even when a call to a class file with the same class name is issued, an encrypted class file can be preferentially loaded. The processing procedure of the loading determination method 16 has been described above.

[0053]

(Processing procedure of middleware loader 15)

Next, the processing procedure of the middleware loader 15 will be described with reference to the flowchart of FIG.

FIG. 8 is a flowchart showing the procedure of the middleware loader 15. In step S11, issue a command to instruct the BD-ROM drive to open the file specified by the argument. As a result, the encrypted class file is read into the file reading area in the RAM 8, and in step S12, the decryptor Chip 6 is instructed to decrypt the encrypted file. In this decryption instruction, the address of the memory area where the plain text class file is to be stored is delivered to the decryptor Chip6. As a result of this decryption, a plaintext class file is obtained in the RAM 8. In step S13, the plaintext class file is awaited to be obtained in the memory.

[0054] When the decryption by the decryptor Chip6 is completed, the plaintext class file is verified in step S15, and it is checked whether the class file has been tampered with! /, NA! /, Etc. Thereafter, the process proceeds to a loop process from step S16 to step S20. In this loop process, the intermediate code i indicates the intermediate code to be processed. In step S16, the intermediate code existing at the head of the file reading area in which the plain text class file is stored is set as the intermediate code i, and the process proceeds to a loop process including steps S17 to S20. In this loop processing, the intermediate code i is converted to byte code i (step S17), and byte code i is stored in the heap memory (step S 18). Repeat until it is done. Step S 19 is a determination of whether the intermediate code i is the last intermediate code of the plaintext class file. If it is not the last intermediate code, the next intermediate code in the plaintext class file is As the intermediate code i, the process from step S17 to step S20 is repeated. If the intermediate code i is the last intermediate code in the plaintext class file, the process of this flowchart is terminated. Since class objects are stored in the heap memory 13 in the form of bytecode structures that depend on the Java (TM) virtual machine, the class object can be restored to a class file even if information on the heap memory 13 is intercepted. Have difficulty.

[0055]

(Create middleware loader 15)

A procedure for creating the middleware loader 15 will be described. As described above, the software developer uses a programming language to write a source program that realizes the flowchart of FIG. In this description, the software developer describes the source program that implements each flowchart and functional components using class structure, variables, array variables, and external function calls according to the syntax of the programming language. .

[0056] The described source program is given to the compiler as a file. The compiler translates these source programs to generate an object program.

Translation by the compiler consists of processes such as syntax analysis, optimization, resource allocation, and code generation. In syntax analysis, lexical analysis, syntax analysis, and semantic analysis of the source program are performed, and the source program is converted into an intermediate program. For optimization, the intermediate program is divided into basic blocks, control flow analysis, and data flow analysis. In resource allocation, variables in the intermediate program are allocated to registers or memory of the processor of the target processor in order to adapt to the instruction set of the target processor. In code generation, each intermediate instruction in the intermediate program is converted into program code to obtain an object program.

Of the translation process by the compiler, in the resource allocation process, variables in the source program are allocated to hardware resources such as registers and memories provided in the CPU of the application execution apparatus. In the code generation process, the CPU generates native code that can be deciphered directly. The middleware loader 15 can be configured by compiling the CPU as described above.

[0058] When object programs are generated, the programmer activates the linker for these. The linker allocates these object programs and related library programs in memory space and combines them into one. Through the above processing, the middleware loader 15 can be created with the power S.

As described above, according to the present embodiment, since the loader program is configured by native code, when a call to the load class API is instructed, the middleware layer delivers the plain text class file from the decryptor to the loader. In addition, a class object will be generated in the heap memory. Since the class object consists of bytecodes and depends on the internal format of the virtual machine, it is difficult to analyze the program structure.

[0059] In the present invention, in the layer structure of the BD-ROM playback device, a place where the confidentiality of the plaintext class file is maintained is selected for delivery of the plaintext class file, so that the confidentiality of the plaintext class file is enhanced. Can be kept in.

(Second embodiment)

In the first embodiment, the middleware loader 15 configured by native code is provided in the second layer, but in this embodiment, a loader (hardware loader) configured by hardware elements is provided in the application execution device. An improvement is disclosed. FIG. 9 is a diagram illustrating a hardware configuration of the application execution device according to the second embodiment. This figure is based on the hardware configuration shown in Fig. 3. Compared to this base hardware configuration, the hardware loader 22 is newly added between the decryptor Chip6 and RAM8. Different from the hardware configuration in Figure 3.

This figure is drawn based on the control layer of FIG. 5. Compared to this control layer, the middleware loader 15 does not exist in the second layer. Instead, the hardware loader 22 is used. Is present in the first layer, which is an improvement specific to this embodiment. Arrows in the figure The marks hi and h2 schematically show the supply path of the encrypted class file in this embodiment. It can be seen that the class file in the encrypted format is supplied to the heap memory 13 via the decryptor Chip6—hardware loader 22.

[0061] Since the hardware loader 22 exists in the first layer, the delivery of the plaintext class file is performed in the first layer. As a result, the contents of the plain text class file will not be scammed by reverse technology that only knows the class file delivery interface.

Next, the internal configuration of the hardware loader 22 will be described.

[0062] The hardware loader 22 is a hardware module including hardware elements such as a ROM, a decoder, and a DMA controller. The ROM stores a plurality of byte codes in association with addresses. The decoder incorporates wire logic indicating the correspondence between individual addresses in the ROM and multiple intermediate codes, decodes each intermediate code making up the plaintext class file, converts it into an address, and outputs it to the ROM To do. By doing this, the byte code corresponding to the intermediate code is read from the ROM.

The DMA controller stores each byte code in the heap memory 13 by performing DMA transfer for the byte code read from the ROM.

Through the decoding by the decoder, reading from the ROM, and DMA transfer by the DMA controller, the individual intermediate codes that make up the plaintext class file are converted to byte codes and sent to the heap memory 13. .

As described above, according to the present embodiment, since the loader is configured using hardware elements, when a call to the load class API is instructed, a plaintext from the decryptor to the loader is generated in the hardware layer. After passing the class file, the class object is generated in the heap memory.

In the present invention, in the layer structure of the BD-ROM playback device, a place where the confidentiality of the plaintext class file is maintained is selected for delivery of the plaintext class file, so that the confidentiality of the plaintext class file is kept high. Can do.

[0065] (Third embodiment)

In the first embodiment, the loading judgment method 16 is provided in the class loader 14. The embodiment relates to an improvement in which a middleware loader 15 has a routine (loading determination routine 18) for determining loading.

FIG. 11 is a diagram showing the positioning of the loading determination routine 18 according to the third embodiment. This figure is based on FIG. 6. Compared to this base configuration, the class loader 14 does not exist in the heap memory 13, and instead, the loading judgment routine is inside the middleware loader 15. 18 exists. In other words, the loading judgment method 16 force in the class loader 14 is replaced with the loading judgment routine 18, which is an improvement specific to this embodiment.

[0066] The loading judgment routine 18 is a middleware loader written in native code.

If there is a call to the load class in 15 subroutines, it is determined whether the class file corresponding to the call argument is a plain text class file or an encrypted class file. Do. If it is a plaintext class file, middleware loader 15 loads the plaintext class file. If the class file is in the encrypted format, the middleware loader 15 causes the decryptor Chip6 to decrypt the encrypted format class file, and then receives the plaintext class file obtained by the decryption from the decryptor Chip6. The middleware loader 15 loads the plaintext class file.

The instruction to the middleware loader 15 is made when the method LoadClass calling force S interpreter 12 as indicated by an arrow g0 is issued. When loading LoadClass, the loading judgment routine ₁₈ determines whether the plaintext class file should be loaded and whether the plaintext class file obtained by decryption by the CPU 5 should be loaded, as in the first embodiment. The arrow il symbolizes the loading of a plain text class file based on the result of this determination, and the arrow i2 symbolizes the loading of the encrypted class file.

[0068] The arrow i3 in the figure symbolically indicates the flow of instructions to the middleware loader 15 and the class file vocabulary.

As described above, according to the present embodiment, the middleware loader 15 can perform processing for loading a plaintext class file and processing for loading an encrypted class file, and the software configuration of the application execution device can be made compact. If you can! Also, by writing the plaintext class file load in native code, The plaintext class file can be loaded at high speed.

(Fourth embodiment)

The middleware loader 15 in the first embodiment has the ability to load the class files that make up the Java (TM) application.In this embodiment, the embodiment loads the class files that make up the class library. It is. Since the class library is stored in the ROM 9 for embedded programs, the loading judgment routine 18 has the capability that the class file of the call destination is a plaintext class file when the load class API is called. It is determined whether it is a class file in the format.

[0069] If it is a plain text class file, interpreter 12 issues an instruction (defmeClasss) to class loader 14 to convert the intermediate code constituting the plain text class file stored in ROM 9 for embedded programs into byte code. To get a class object in the heap memory.

If it is an encrypted class file, the interpreter 12 issues an instruction (defmeEncryptedClass) to the middleware loader 15. This allows the decryptor Chip6 to decrypt the encrypted class file, and the plaintext class file can be obtained on the memory by decryption. A class object is obtained on the heap memory by converting the intermediate code constituting the plain text class file on the memory into byte code.

[0070] As described in the first embodiment, the load determination routine 18 is configured as a base for the loading determination routine 18, that is, the flow chart algorithm shown in FIG. Write a source program that In this description

The software developer follows the syntax of the programming language and uses the class structure, variables, array variables, and external function calls to describe each flowchart and the source program that defines the functional components.

[0071] The described source program is given to the compiler as a file. The compiler translates these source programs to generate an object program.

Among the translations by the compiler, in the resource allocation process, variables in the source program are allocated to hardware resources such as registers and memory that the CPU in the application execution device has. [0072] Then, in the code generation process! /, The CPU generates a native code that can be directly decoded by the CPU. The loading judgment routine 18 can be created by compiling the CPU as described above.

When object programs are generated, the programmer invokes the linker for these. The linker allocates these object programs and related library programs in memory space and combines them into one. Through the above processing, the middleware loader 15 incorporating the loading determination routine 18 according to the present embodiment can be created.

[0073] (Fifth embodiment)

In the first embodiment, the internal configuration of a playback device using a BD-ROM as a supply source has been disclosed. It is embodiment regarding production.

BD-ROM production involves the following planning process, material creation process, and mastering process. In this process, the scenario for determining the BD-ROM playback power is determined.

[0074] Next, a material creation step is performed. This process involves creating materials such as video recording and audio recording.

Then, a mastering process is performed. In this process, an overall image (generally called a volume image) of data to be recorded in the volume area of the BD-ROM is obtained from the scenario created in the planning process and the material obtained in the material creation process. After that, the volume image is converted into a physical data string, and the master disk is cut based on the physical data string to obtain a disk master disk.

[0075] Thus, once the master disc is created, BD-ROM is industrially produced in large quantities. This production mainly consists of various processes such as substrate molding, reflection film formation, protective film coating, bonding, label printing and labeling.

Through the above process, the recording medium (BD-ROM) shown in each embodiment can be manufactured. FIG. 12 is a block diagram showing a rough functional configuration of a mastering apparatus that performs BD-ROM mastering. As shown in this figure, the mastering device has a class file acquisition module. It consists of a yule 51, an encryption determination unit 52, a key generation unit 53, a class file encryptor 54, an ichiichi kino 55, a master key acquisition module 56, a decryption key encryptor 57, and a BD-ROM burner 58.

[0076] The class file acquisition module 51 sequentially acquires the class files constituting the Java (TM) application.

The encryption determination unit 52 determines the necessity of encryption of the class file acquired from the class file acquisition module 51. The necessity of encryption can be determined by using the attribute information of the class file or by asking the user before encryption.

[0077] The key generation unit 53 generates a decryption key and an encryption key. It is desirable to use symmetric key cryptography such as AEs (Advanced Encryption Standard) A ^ DES (Data Encryption Standard) in order to speed up decryption on playback devices. When using symmetric key cryptography, since the signature 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 54 encrypts the class file determined to be encrypted by the encryption determination unit 52 with the encryption key generated by the key generation unit 53.

The archiver 55 stores the class file in one JAR file. Here, the class file that does not need to be encrypted is attached to the JAR file with the extension “class”. On the other hand, the encrypted class file obtained from the class file encryptor 54 is stored with the extension “secure” in the JAR file.

The master key acquisition module 56 holds the master key of the playback device inside and passes it to the decryption key decryptor 57.

[0079] The decryption key encryptor 57 encrypts the decryption key with the master key. Since the decryption key is encrypted with the master key, the BD-ROM created by this mastering is extremely difficult to decrypt without the master key.

The BD burner 58 converts the JAR file and decrypted decryption key into a file and directory structure as shown in Fig. 2, and covers the data that should be stored in BD-ROM— Is obtained. An optical disc created by the mastering device has the configuration shown in FIG. To decrypt an encrypted class file in a JAR file without using a master key, the class file encryptor must analyze the encryption algorithm used for encryption. Since the analysis of this encryption algorithm takes a lot of time, it can be considered that analysis using reverse engineering technology is impossible.

(Sixth embodiment)

The present embodiment relates to an improvement in which decryption key information is stored in a manifest file, and the decryptor Chip 6 decrypts an encrypted class file based on the decryption key information.

FIG. 13 is a diagram showing an example of the storage contents of the XXX.KEY file and the manifest file according to the sixth embodiment.

(1) XXX.EY ("XXX" is variable, extension "KEY" is fixed)

This XXX.KEY file is an encryption format file that stores one or more decryption keys necessary for decrypting the class file. XXX. KEY file can store multiple decryption keys. The right side of Fig. 13 shows the contents stored in the XXX.KEY file according to this embodiment. This XXX.KEY file stores a chain consisting of multiple decryption keys. These decryption key chains have KEY-ID = 0 for the first key and K for the second key. KEY-ID is set in the order of appearance, such as EY-ID = 1 and KEY-ID = 2 for the second key. Multiple decryption keys included in the manifest file are individually specified using this Key-ID. The XXX.KEY file itself is also encrypted, and can only be decrypted by a legitimate device. Here, a legitimate device refers to a device that can use Copy Protection for Recordable Media (CPRM) and obtain a decryption key unique to an optical disk based on the device key that the device itself has. This decryption key unique to the optical disc is a decryption key that is determined by the title producer, and is called a title key in CPRM.

[0082] A plurality of decryption keys are stored in the XXX.KEY file. Which of these is used for decryption is specified in the manifest file in the JAR file shown on the left side of FIG. In the MAMFEST.MF file, the information as described in the first embodiment is described by the grammar according to the JAR file specification. The MAMFEST.MF file according to the present embodiment is characterized in that the ID of the decryption key necessary for decryption can be designated. The MAMFEST.MF file contains a main session (Manifest-Version: 1.0 in the figure) and an individual session (Name: Protected. Secure). The default KEY-ID is assigned to this main session. It is possible to describe, and the KEY-ID of individual files can be described in individual sessions. Of the internal structure of the MAMFEST.MF file in Figure 13, it is Manifest-Version: 1.0. The main S session shows that Key_ID: 0 is described here. Power of Name: Protected.secure This is an individual session for Protected.secure, and it can be seen that Key-ID: 1 is listed here. These “Key_IDs” specify individual decryption keys that exist in the XXX.KEY file. For example, in the example of FIG. 13, the Key_ID of the key chain that exists in the XXX.KE Y file The decryption key corresponding to = 0 is used as the default decryption key. The decryption key corresponding to this Key_ID = 0 is used when decrypting the encrypted class files that are not specified individually among the encrypted class files in the JAR file.

The decryption key corresponding to Key_ID = l will be used to decrypt the “Protected.secure” file. By specifying multiple keys “Key_ID” in the MAMFEST.MF file, multiple class files with different encryption formats can be decrypted.

The above is the improvement on the BD-ROM according to this embodiment. Next, the improvements of the application execution device will be described in detail. In the application execution apparatus according to the present embodiment, there are improvements in the BD-ROM drive 1, the decryptor Chip 6, the middleware loader 15, and the opening determination method 16. FIG. 14 is a diagram in which constituent elements to which improvements specific to the sixth embodiment are applied are extracted, and exchanges between these constituent elements are added. In other words, the arrow force added between the components in this figure schematically shows the interaction between these components.

(Improved points of BD-ROM drive 1)

BD-ROM drive 1 holds the device key defined by CPRM inside. BD-ROM drive 1 reads the encoded title key from the BD-ROM and The title key is decrypted using the chair key.

(Decryptor Chip6 improvements)

The decryptor Chip 6 receives the plaintext title key from the BD-ROM drive 1 and decrypts the encrypted decryption key in the XXX / KEY file using the title key. After that, the encryption class file is decrypted using this decryption key. In delivering the title key, the decryptor Chip 6 performs mutual authentication with the BD-ROM drive 1. This mutual authentication is performed because the key may be intercepted when the BD-ROM drive 1 passes the title key to the decryptor Chip6. If the BD-ROM drive 1 and the decryptor Chip6 authenticate each other's validity, they open each other's encrypted channel (SAC: Secure Authenticated Channel) and receive the plaintext title key through the opened encrypted channel. At this time, the Ellipic Curve Cryptosy stem (ECC) and the Diffie-Hellman algorithm can be used to realize the encrypted channel. After passing the title key and the encrypted decryption key, the decryptor Chip 6 decrypts the encrypted class file.

In the present embodiment, since a plurality of decryption keys can be specified in the MAMFEST.MF file, the decryptor Chip 6 receives the key-ID from the middleware loader 15 when the decryption is ordered from the middleware loader 15. And decrypts the encrypted class file into a plain text class file using the decryption key corresponding to this Key-ID. For example, if an encrypted class file to be read is associated with Key_ID = "l" in the MAMFEST.MF file, it is associated with Key_ID = "l" for decryption of the encrypted class file. The obtained decryption key is used. If Key-ID is not associated in the MAMFEST.MF file, the decryption key associated with Key-ID = 0 is used as the default decryption key.

[0085] If the encryption key, title key, decryption key, etc. used in the SAC in the decryptor Chip6 are intercepted by a third party, the copyright protection of the entire system becomes impossible. In addition, there is a risk that a plain text class file temporarily stored inside may be intercepted, and security is taken into consideration, such as mounting the descriptor chip 6 itself as a single system LSI. [0086] Further, when decrypting the encrypted class file, the decryptor Chip 6 caches the decryption key extracted from the XXX.KEY file, and thereafter decrypts the same encrypted class file. This cached decryption key is used. In this way, when performing the same decryption process as the encrypted class file once decrypted, the mutual authentication with the BD-ROM drive 1 as described above can be omitted. become. The use of such a cache can significantly reduce the time required to decrypt an encrypted class file.

[0087] The arrow u0 in FIG. 14 symbolically shows the transfer of the encrypted title key from the BD-ROM to the BD-ROM drive 1, and the arrow ul indicates the SAC between the decryptor Chip66 and the BD-ROM drive 1. Symbolically shows mutual authentication by. The arrow u2 in the figure symbolically indicates the delivery of the plaintext title key from the BD-ROM drive 1 to the decryptor Chip 6. The arrow u3 in the figure symbolically indicates the passing of the encrypted XXX.KEY file from BD-ROM drive 1. The encrypted XXX.KEY file delivered in this way will be decrypted using the plaintext title key delivered earlier.

(Improvement of middleware loader 15)

The middleware loader 15 generates a class object on the heap memory 13 after the encrypted class file is decrypted into a plain text class file.

(Improvements of interpreter 12)

The interpreter 12 instructs the class loader 14 and the middleware loader 15 to load the class file according to the determination result of the loading determination method 16. In this embodiment, since multiple decryption keys can be specified in the MAMFEST.MF file, the interpreter 12 determines that the class file to be loaded by the loading determination method 16 is encrypted. The class name, encrypted class file, and key-ID must be specified as arguments. In other words, it is necessary to call defmeEncryptedClass which is API as defmeEncryptedClass (class name, encryption class file, Key-ID).

Here, “class name” is the name of the class object to be reproduced. The encryption class file is a file obtained from the JAR file. Key-ID is the Key-ID corresponding to the class name obtained from the MAMFEST.MF file. A call to defineEncryptedClass like this The middleware loader 15 is requested to load the encryption class file. On the other hand, when the loading determination method 16 determines that the class file to be loaded is not encrypted, it makes an API call defmeClass (class name, plain text class file), specifies the class name and class file as arguments, and class Request class loader 1 4 to load file

The arrow u4 in the figure symbolically shows the output of the determination result from the loading determination method 16 to the interpreter 12. An arrow u5 symbolically indicates a call to defineEncryptedClass (class name, encryption class, Key-ID) based on the determination result. The arrow u6 in the figure symbolically indicates the decryption instruction to the decryptor Chip6 based on the Key-ID specified by the argument.

[0089] An arrow u7 in the figure symbolizes the delivery of an encrypted class file. The encrypted class file delivered in this way is decrypted using the decryption key corresponding to the Key-ID instructed to be used for decryption. The arrow u8 in the figure symbolically shows the delivery of the plaintext class file obtained by decryption from the decryptor Chip6 to the AV playback engine 7. As described in the first embodiment, this delivery is performed in the first layer or the second layer. As described above, according to this embodiment, the information for extracting the decryption key corresponding to the encrypted class file is obtained. Is described in the MAMFEST.MF file, the description of this MAMF EST.MF file makes it possible to use multiple decryption keys, and one of the multiple decryption keys is known to the attacker by cryptanalysis. However, unless the attacker knows the other decryption key, it can be difficult to decrypt the encrypted class file that is decrypted using the other decryption key. Can increase confidentiality

[0090] (Seventh embodiment)

In the present embodiment, BD-ROM mastering provided to the application execution device shown in the sixth embodiment will be described.

FIG. 15 is a diagram illustrating an example of a configuration of a mastering apparatus that performs BD-ROM mastering used in the application execution apparatus illustrated in the sixth embodiment. [0091] This figure is drawn based on FIG. 12, and compared to this base configuration, the key generation unit 53, the class file encryptor 54, the archiver 55, the CPRM module 56, and the decryption key encryptor. A new feature is that 57 has been replaced with a key generator 63, class file encryptor 64, archiver 65, CPRM module 66, and decryption key encryptor 67. Constituent elements already described in the previous embodiment are denoted by the same reference numerals, and description thereof is omitted. Hereinafter, components that appear for the first time in the present embodiment will be described.

[0092] (Key generator 63)

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

(Class File Entrepter 64)

The class file encryptor 64 encrypts the class file that needs to be encrypted with the encryption key generated by the key generation unit 63. Key-ID is attached to the encryption key, and the class file cryptor 64 stores the ID of the key used.

(Archiba 65)

Archiver 65 adds the extension “class” to the file name of the class file that does not require encryption, and adds the extension “secure” to the file name of the encrypted class file obtained from class file encryptor 64. As a result, a JAR file containing these plaintext class files and class files in encrypted format is obtained. In addition, the key-ID information of the key number used for the key number is received from the class file encryptor 64, and the information is stored in the metafile. The metafile is a MANIFEST.MF file in the META-INF directory of the JAR file.

(CPRM module 66)

The CPRM module 66 performs key generation and information holding necessary for CPRM. CPRM module 66 passes the title key to decryption key encryptor 67. In addition, the information specified in the CPRM specifications is passed to the BD burner 58. The specification of CPRM is disclosed, for example, at “http: 〃 www.4centity.com/tech/cprm/J”.

(Decryption key encryptor 67)

The decryption key encryptor 67 encrypts the necessary decryption key with the title key. In this encryption, the decryption keys with Key-ID = 0 are headed and the decryption keys are connected in order, Create a chain. The decryption key file is generated by encrypting the chain of decryption keys created in this way with the title key.

[0093] An optical disc created by the mastering apparatus according to the present embodiment 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 specified 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.

[0094] (Remarks)

As described above, the best embodiment that the applicant can know at the time of filing of the present application has been described. However, the technical topics shown below can be further improved or modified. It should be noted that the implementation as shown in each embodiment or whether these improvements or changes are made is arbitrary and depends on the subjectivity of the practitioner.

(Decryptor implementation by software)

If the master key held by the decryptor Chip6 is known to the third party, detailed information on the decryption key encrypted with the master key is known, and the copyright can be protected for the third party. Disappear. In that case, there is a risk that information on the master key may be disclosed by a third party, and there is a risk that the decryption key, its intermediate data, and the plaintext class file will be intercepted. In consideration of security for the master key, the decryptor in each embodiment is implemented by hardware. However, if there is a guarantee that the security of the master key can be ensured, the decryptor may be implemented by software! /, .

[0095] In order to realize such a guarantee, it is desirable to apply software obfuscation technology for software decryptors to avoid interaction with other modules such as interpreter 12.

In addition to applying software obfuscation technology, confidentiality can be enhanced by executing a software-based decryptor in a secure execution mode. By executing the secure decryptor in the secure execution mode, the confidentiality of the master key is kept high. (Room for tuning)

The class loader 14 and the middleware loader 15 have a lot in common in the generation of class objects, but the class objects generated by the class loader 14 do not need to pay special attention to copyright protection. There is room for tuning to speed up the implementation. Therefore, by tuning the class loader 14, it is possible to speed up the process of loading the plaintext class file among the class files that constitute the application.

[0096]

(Heap memory dump countermeasures)

If the middleware loader 15 is placed in the middleware layer of the second layer, there is a risk that the heap memory will be dumped while the middleware loader 15 is processing and the class file will be intercepted. In order to avoid force and interception, it is desirable that the middleware loader 15 avoids interaction with other modules such as the interpreter 12 and applies software obfuscation technology.

In addition to the application of software obfuscation technology, confidentiality can be enhanced by executing the middleware loader 15 in a secure execution mode by the CPU. Software running in secure execution mode makes it more difficult to intercept heap memory, so it is desirable that middleware loader 15 be executed in secure execution mode.

(Shared)

The processing after the middleware loader 15 converts the encrypted class file into a plain text class file is the same as the processing by the class loader 14. Of the processing of the class loader 14, an implementation that uses a part of the middleware loader 15 may be realized for the part that converts the plain text class file into a class object and stores it in the heap memory. This can be realized by, for example, sharing a common library between the processing by the class loader 14 and the processing by the middleware loader 15. The class loader 14, loading judgment method 16, and hardware loader 22 load class files based on application signaling by the application manager. You may be fi.

The application manager is a system application that operates in a heap area in the virtual machine, and executes application signaling. 〃Application signaling〃 is a control that starts and executes an application using a service 〃 as a life cycle in MHP (Multimedei Home Platform) defined by GEM1.0.2. The application manager in the BD-R OM playback device Instead of this “service”, the “Title on BD-ROM” is used as the life cycle, and application startup and execution control is realized. Here, the “title” is a playback unit of video and audio data recorded on the BD-ROM, and an application management table (AMT) is arbitrarily assigned.

[0099] When the title selection is performed by the BD-ROM playback device, the title boundary application signaling includes an application management table (AMT) corresponding to the previous title and an application management table corresponding to the current title ( Signaling performed using (AMT). This signaling is written in the AMT corresponding to the previous title! /, And the power is written in the AMT corresponding to the current title! /, Na! /, And terminates the operation of the application. This is a control that is not described in the AMT corresponding to the title, but is described in the AMT corresponding to the current title! Each time this application signaling is performed, the class loader 14, the middleware loader 15, and the hardware loader 22 shown in each embodiment generate a class object from the class file that configures the application to be started, and Used for machine execution.

(Directory structure in local storage)

The HD drive 2 and the memory card drive 3 shown in FIG. 3 may be a local storage that can be accessed by using a method from Java (TM) 10 Package. This local storage has a plurality of domain areas. Here, the domain area is a directory corresponding to a disk root certificate unique to the BD-ROM, and a directory for each organization is stored under these directories.

[0100] The disk root certificate is a BD-ROM assigned to the BD-ROM by the creator who created this BD-ROM and the root certificate distributed by the root certificate authority. Disk root certificate Is encoded in the X.509 format, for example. The X.509 specification is published by the International Telegraph and Telephone Consultative Committee and is listed in CCITT Recommendation X.509 (1988), "The Directory-Au thentication Framework"! / ヽ o.

[0101] The directory for each application in the organization is the same as that of MHP. In other words, in the local storage, the directory for each application of each organization specified in MHP is arranged under the directory corresponding to the root certificate. In this way, compatibility with the MHP storage method can be maintained. Here, the part corresponding to the root certificate in the file path for accessing the directory structure of the local storage is called “local storage storage rate”.

[0102] Then, the class loader 14, the middleware loader 15, and the hardware order 22 shown in the respective embodiments use the local storage root from the directory corresponding to the disk root certificate in the BD-ROM. It is desirable to create a class object based on this class file and execute it on the virtual machine! /.

In addition, the recorded contents of BD-ROM and local storage are encrypted with Advancend Access Content System (AACS), signed information is added, and usage rights are expected to be specified in the permission file. Masle.

For example, whether or not the desired file exists in the file path “/ Persistent / l / l / streams /” is confirmed by using the exitsO method of java (TM) .io. An example of using the exitsO method of java (TM) .io when the file is 0.m2ts is shown below.

new javau'M) .io.File (/ Persistent / 丄 / up / streams / 0.m2ts) .exists ();

(Java (TM) application)

If the virtual machine includes a standard library for displaying JFIF (JPEG), PNG, and other image data, the Java (TM) application includes the HAVi framework specified in GEM1.0.2, The remote control navigation mechanism in GEM1.0.2 may be realized. As a result, the Java (TM) application can realize a screen display that combines the display such as button display, text display, and online display (for example, BBS contents) based on the HAVi framework with the display of moving images. Remote control Operations for this screen display can be performed using the roll.

The Java (TM) application may be, for example, an electronic commerce (EC) client application or an online online game. In addition, it provides various online services to users in cooperation with search engines.

(Variation of application execution device)

The application execution apparatus which is effective in the present invention may be a Java (TM) platform incorporated in a device for receiving satellite broadcasting. In addition, the application execution apparatus which is effective in the present invention may be a Java (TM) platform incorporated in a device for processing control of a mobile phone. Other than that, Java ™ platform built into digital cameras and digital TVs!

(Package to be mounted)

When implementing the application execution device, it is desirable to implement the following BD-J Extension on the application execution device. The BD-J Extension includes various packages specialized to give the Java (TM) platform functionality beyond GEM [1.0.2]. The packages supplied with BD-J Extension are as follows.

• org.bluray.meaia

This package provides special functions that should be added to Java (TM) Media FrameWork. Control over the selection of angles, audio, and subtitles Added to this package. Org.bluray.ti

This package selects APIs for mapping "services" to "titles" in GEM [1.0.2] and operating, title information from BD-ROMs, matching mechanisms, and new titles. Including a mechanism.

• org. Bluray. Application

This package includes an API for managing the lifetime of an application. It also includes an API for inquiring information necessary for signaling when executing the application.

• org. Bluray. Ui This package defines constants for key events specific to BD-ROM, and includes classes that realize synchronization with video playback.

Org.bluray.vrs

In order to seamlessly play back data regardless of the location of this data, this package can be recorded on BD-ROM (on-disc content) and recorded on BD-ROM! /, NA! / 、 Provides a mechanism (Binding Scheme) for binding content on local storage (off-disc content).

[0105] The Binding Scheme associates content (AVClip, subtitles, BD-J application) on BD-ROM with related content on Local Storage. This Binding Scheme realizes seamless playback regardless of the location of the content.

(Decryption request for decryptor Chip6)

When decryptor Chip6 is operated as a task on a real-time OS such as Linux, it is desirable that the decryption request for decryptor Chip6 be realized by a system call via the kernel of the real-time OS.

[0106] When a system call for a device I / O request is issued from a task, the kernel allocates a memory block from the memory pool and creates a parameter block used for the call in that block. Then, the request processing unit of the device driver corresponding to the decrypter Chip 6 is called by using the head address of the parameter block and the address of the device table in which device information is described as arguments.

The device driver corresponding to the decryptor Chip 6 includes an “interrupt handler section”, an “interrupt task section”, and a “request processing section” that are activated by a hardware interrupt signal. The request processing unit of the device driver registers the parameter block in the I / O queue, enables interrupts, and returns to the kernel.

[0108] When the interrupt handler receives an interrupt signal from the hardware corresponding to the decryptor Chip6, it performs the requested input / output with the device. When the scheduled I / O is completed, interrupts are disabled and the interrupt task section is activated. If not completed, return to the device driver. When the next I / O request is made, the interrupt handle is activated again and the remaining I / O continues. [0109] The interrupt task unit notifies the kernel of input / output completion by a system call using the input completion state as an argument. Upon receiving such notification, the kernel notifies the requesting decryptor Chip6.

Midoreware loader 15 Descriptor Decryptor that does not use the interface described in Non-Patent Document 1 at all if the plaintext class file is handed over on RAM8 by performing input / output as described above with Chip6 device driver. The plaintext class file can be transferred from to the middleware loader 15. Such exchange between the middleware driver 15 and the device driver of the decryptor Chip 6 is performed under the tamper-resistant technology in the BD-ROM playback device, so the confidentiality of the plaintext class file is guaranteed. .

Industrial applicability

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

Claims

The scope of the claims

[1] An application execution device,

A decryptor that obtains a plaintext class file by decrypting the encrypted class file;

A loader that converts the intermediate code constituting the plaintext class file obtained by decryption into bytecode, and stores the bytecode obtained by the conversion in heap memory;

An interpreter that converts the bytecode stored in the heap memory into native code and causes the CPU in the device to execute it.

The loader is

A middleware program written in native code, or a hardware module composed of hardware elements

An application execution device.

[2] The loader is a decryptor loader for an encrypted class file, and the application execution device includes:

With a class loader defined by a class structure,

The class loader converts intermediate code constituting a plain text class file into byte code, stores the byte code obtained by the conversion in a heap memory, includes a determination method,

When the load class is called, the determination method determines whether the class file corresponding to the argument of the call is a plain text class file or an encrypted class file. If the class file is a class file, let the class loader convert it to byte code. If it is an encrypted class file, let the descriptor loader convert it to byte code.

The application execution device according to claim 1, wherein:

[3] The determination method secures the cache for storing the class object once stored in the heap memory in the memory of the application execution device, and corresponds to the class file to be called by the load class. If the class object to be created does not exist in the cache, bytecode is stored in the descriptor loader and class loader. Order conversion to

The application execution device according to claim 2, wherein:

[4] The plain text class file to be converted to Neut code contains

There are those that make up the application supplied on the recording medium, and those that make up the class library built into the device.

The application execution device according to claim 1, wherein:

[5] The loader

When a load class is called, it is determined whether the class file corresponding to the argument of the call is a plain text class file or an encrypted class file. If so, the intermediate code that makes up the class file is converted to byte code. If it is an encrypted class file, the decrypted class file is decrypted by the decryptor. The specified plain text class file into bytecode

The application execution device according to claim 1, wherein:

[6] The encrypted class file is recorded on a recording medium,

On the recording medium, a decryption key for decrypting an encrypted class file is recorded in a state encrypted with a master key,

The decryptor is

If the master key is held in advance and the class file in the encrypted format is to be decrypted, the decryption key in the encrypted state corresponding to the class file in the encrypted format is acquired from the recording medium,

The decryption key used by the decryptor to decrypt the encrypted class file is

A decryption key obtained by decrypting the encrypted decryption key using the master key held in advance.

The application execution device according to claim 1, wherein:

[7] The decryptor is:

Before the encrypted class file is read from the recording medium, the encrypted decryption key is decrypted using the master key and stored in the cache. 7. The application execution device according to claim 6, wherein

[8] The encrypted class file is recorded on a recording medium,

The recording medium includes a title key, an decryption key for decrypting an encrypted class file, which is encrypted with the title key, and information for extracting the decryption key. With the metafile you have written,

The loader reads information for extracting a corresponding decryption key from the metafile when the application is executed, and sends the information to the decryptor.

The decryptor obtains the encrypted decryption key from the drive based on the information for extracting the decryption key,

Obtaining a title key from the recording medium, decrypting the decryption key using the obtained title key, and decrypting the class file in the encrypted format using the decryption key selected by decryption The application execution device according to claim 1.

9. The application execution device according to claim 8, wherein the decryptor holds a decryption key acquired from the recording medium.

[10] An application execution method,

Decrypting the encrypted class file to obtain a plaintext class file Decryption code that obtains a plaintext class file Converts the intermediate code that makes up the plaintext class file obtained by decryption into bytecode, and converts the bytecode obtained by the conversion into heap memory A loader step that stores data in the heap memory, and a conversion step that converts the byte code stored in the heap memory into a native code and causes the CPU in the device to execute it.

The loader step includes

An execution method characterized by being realized by causing a CPU to execute a middleware program described in native code, or operating a hardware module composed of hardware elements.

[11] A program for causing a computer to execute a prescription,

Decryption class that obtains a plaintext class file by decrypting an encrypted class file The intermediate intermediate code that constitutes the plaintext text class file obtained by the decryption code is converted into a byte code. Then, a loader code step that stores the stored byte code obtained by the transformation conversion in a hi-pe memory memory, and Convert the stored code stored in the hi-pe memory memory into a native code and convert it into a device. In this case, the computer is allowed to execute the conversion step and the conversion step that causes the CCPPUU to execute the actual execution.

Whether to allow the CCPPUU of the computer to execute the program that was written in the native code as described in the native program code , Or, or to operate a hardwired module composed of hardwired elements. According to the above, the above-mentioned Rolloda dashes step will be realized.

*