KR101544731B1 - Storage device capable of separating execution of executable content, and device for configuring native execution environment in storage device - Google Patents

Abstract

The present invention relates to a storage device for separately executing executable contents for copyright protection of executable contents and an apparatus for implementing the native execution environment. In the storage apparatus according to the present invention, the native execution environment implementing apparatus loads the code block to be executed through the loader and performs linking to fix a reference value of a code whose reference value of the code block is not fixed. The execution point of the code block loaded by the loader is forcibly called and executed. It generates and manages a TCB (Task Control Block) for each code block through the task manager, transfers the data transferred from the host terminal to the executor through the TCB, and returns the execution result to the host terminal. Through this native execution environment implementing device, it is possible to improve the execution speed of executing executable contents.

Description

Technical Field [0001] The present invention relates to a storage device capable of executing executable content, and a storage device capable of performing a separating execution of an executable content,

The present invention separates and executes the executable content through interoperation between the host terminal and the storage device to protect the copyright of the executable content. The code block separated from the code area of the executable content is separated An executable storage device, and an apparatus for implementing the native execution environment.

2. Description of the Related Art [0002] Recently, as the use of various host terminals such as a personal computer (PC) and a personal digital assistant (PDA) has been increasing, various digital contents used in host terminals have been developed accordingly.

Digital contents refers to characters, sounds, sounds, images, and the like, which are made in a digital format. Recently, with the development of digital technology, the kinds of digital contents have become more diverse. These digital contents are freeware that can be freely used, but most of them are developed for commercial use, and they are used after purchasing a license or a program at a predetermined price. However, there are many cases in which some users illegally copy or use them through cracking.

Therefore, in order to protect the rights of developers, digital rights management technology that protects copyright on digital contents is becoming more important.

DRM refers to technologies and services that prevent the unauthorized use of digital contents, protect the rights and interests of digital contents providers, prevent illegal copying, charge fees, settle and distribute contents, and support distribution and management. Include digital rights management technology that allows only legitimate users to use content and pay appropriate fees, software and security technology for copyright approval and enforcement, and payment / billing technology.

Particularly, in such a DRM system, various methods are used to prevent illegal copying and use of digital contents. The most common method is to use an authentication key. In this method, digital content can be installed or executed only when an authentication key is input. However, illegal use or illegal copying is still performed by users sharing the authentication key with each other or by reverse engineering the key verification algorithm.

In a more powerful way, there is a way to provide a hardware key lock so that it is executed only when the provided key lock is present when the program is executed. However, this method can also be disabled by modifying the program to bypass only the portion of the key lock.

As a result, the illegal use of digital contents is still being performed, and the damage caused by content developers due to unauthorized use of digital contents is increasing. Unauthorized use of digital contents is a factor that deteriorates the desire to develop application programs of content developers. In addition, when developing digital contents, it increases the development cost of digital contents due to development of security technology for suppressing illegal copy and use , Which is a burden on the content provider.

The present invention has been proposed in order to solve the problems of the related art, and it is an object of the present invention to separate and execute executable contents for protection of copyright by separating code blocks separated from the code area of executable contents through interlocking with the host terminal A storage device and an apparatus for implementing the native execution environment.

As a means for solving the above-mentioned problems, the present invention provides a storage device including an operating system and a native execution environment implementing device and performing a separate execution of executable contents in cooperation with a host terminal. The operating system manages and operates the hardware elements of the storage device to perform at least one of communication with the host terminal, reading and writing data to the internal memory, file access control, user authentication, and execution of an application program. The native execution environment implementation device is implemented as an extension of the operating system, loads the code block to be executed, links it at runtime, and provides the execution result to the host terminal.

The storage device according to the present invention is a storage device for performing installation and management functions for RO (Right Object) of executable contents and for exchanging information for separation execution by connecting the host terminal with a secure channel And a DRM (Digital Right Management) agent.

An apparatus for implementing a native execution environment according to the present invention includes a loader, an executor, and a task manager. The loader loads the code block to be executed and performs linking to fix the reference value of the code for which the reference value is not set. The executor forcibly invokes the entry point of the code block loaded by the loader to execute the code block. The task manager generates and manages a task control block (TCB) by mapping 1: 1 to a plurality of applications of the host terminal, transfers the data transferred from the host terminal to the executor through the TCB, Return.

The apparatus for implementing a native execution environment according to the present invention may further include a memory mapper. When a memory reference of a host terminal is required during execution of a code block, the memory mapper delivers a memory reference request to the host terminal, and returns the result of the memory reference request to the host terminal.

An apparatus for implementing a native execution environment according to the present invention includes an OS API mapper that, when an OS API call is required during execution of a code block, calls an OS API of a host terminal in cooperation with a host terminal, As shown in FIG.

The apparatus for implementing a native execution environment according to the present invention may further include a memory manager that allocates and manages a memory to be used for execution of a code block from an operating system of the storage device.

In the native execution environment implementing apparatus according to the present invention, the executor further performs a function of calling a loader when a code block to be executed is transmitted from the host terminal.

In an apparatus for implementing a native execution environment according to the present invention, when an executor needs to wait for a response from a host terminal during execution of a code block, an execution instruction point and a register value, which are currently being executed, And when the response of the host terminal arrives, it refers to the stored value and restarts it from the corresponding instruction point.

In the native execution environment realization device according to the present invention, the task manager generates a TCB when the right terminal has a use right at the time of checking the RO (Right Object) at the host terminal, terminates the corresponding application at the host terminal, The TCB generated is removed.

In the native execution environment implementation apparatus according to the present invention, the loader links the memory mapper to call the memory block when the code block refers to the memory of the host terminal during the linking process, , The call is packaged and transferred to the host terminal, and the processing result is received from the host terminal and is analyzed and transmitted to the executor.

In the native execution environment implementing apparatus according to the present invention, the loader links the OS API mapper to the code referring to the OS API of the host terminal in the code block during the linking process, and the OS API mapper links the OS API mapper When invoked during execution, the call is packaged and delivered to the host terminal, and the response of the host terminal is interpreted and transmitted to the implementer.

In the apparatus for implementing a native execution environment according to the present invention, the memory manager allocates 4-byte aligned dynamic memory from the operating system, divides the allocated dynamic memory into a plurality of groups (size-class) It supports partial memory compaction for dynamic memory and performs the function of merging physically adjacent free memory blocks.

In the native execution environment implementation apparatus according to the present invention, the memory block managed by the memory manager is composed of a dynamic allocation memory in which real data is stored, and a header located in front of the dynamic allocation memory, A first section in which a size of a memory block located at a front side and a check bit for a memory group are recorded, a size of the memory block, a second section in which whether or not the memory block is used is recorded, A third section in which a pointer and an application ID to which the memory block is allocated are recorded, and a fourth section in which the addresses and indirect addresses of the free memory blocks in front of the memory block are recorded.

In the native execution environment implementing apparatus according to the present invention, the code block is a code block for a storage device in which a code block to be separated from the code area of the execution-based execution content is converted into a form executable in the storage device.

Here, the detachment object code block is a basic block group on a critical path of executable contents among a plurality of basic block groups made up of a plurality of basic blocks existing in the code area of the executable contents.

The basic block group allows entry of a control signal through an entry point and movement of a control signal between the plurality of basic blocks and allows the control signals to be transferred to the plurality of basic blocks without entry of control signals into the plurality of basic blocks Is a group of the plurality of basic blocks.

A basic block is a block of code with attributes of single input and single output and attributes that do not allow entry of control signals from outside to inside.

In the storage device and the native execution environment realization apparatus according to the present invention, the code block for the storage device is a code block containing a processor instruction word of the storage device.

An apparatus for implementing a native execution environment according to the present invention implements a file system by allocating a specific area in a ROM of a storage device.

1 is a diagram showing a schematic structure of a digital rights management system to which the present invention is applied.
2 is a diagram schematically showing the structure of an executive content to which the present invention is applied.
3 is a diagram schematically illustrating the structure of an execution-based execution content according to the present invention.
FIG. 4 is a block diagram illustrating a structure of a separation-based execution content and a separation execution process in the digital rights management system to which the present invention is applied.
5 is a block diagram illustrating a configuration of a storage device capable of separately executing executable content according to the present invention.
6 is a block diagram showing a configuration of a native execution environment implementation apparatus according to the present invention.
7 is an exemplary diagram illustrating a function of a loader in a native execution environment realization apparatus according to the present invention.
8 is a diagram for explaining the operation of the task manager in the native execution environment realization apparatus according to the present invention.
9 is a message flow diagram illustrating a TCB generation operation of a task creator in the native execution environment realization device according to the present invention.
10 is a message flow diagram illustrating a TCB termination operation of a task creator in the native execution environment realization device according to the present invention.
11 is a diagram for explaining the function of the memory manager in the native execution environment realization apparatus according to the present invention.
12 is a block diagram of a memory block managed by a memory manager in the native execution environment realization device according to the present invention.
13 is a diagram illustrating a structure of a file system of a native execution environment implementing apparatus according to the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description and the accompanying drawings, detailed description of well-known functions or constructions that may obscure the subject matter of the present invention will be omitted. It should be noted that the same constituent elements are denoted by the same reference numerals as possible throughout the drawings.

1 is a block diagram showing the entire structure of a digital rights management system (hereinafter referred to as DRM system) to which the present invention is applied.

1, the DRM system 10 to which the present invention is applied includes a content providing server 12 and a host terminal 13 connected via a network 11, a wired / wireless interface And an intermediately connected storage device 14.

In the present invention, 'separate execution' means that the executable content is executed through two different apparatuses, more specifically, interworking of the host terminal 13 and the storage device 14. In order to implement such separate execution, the host terminal 13 stores the execution execution-based executable content 15a from which a code block selected as a code area (hereinafter, referred to as a separation execution object code block) is removed, 14 stores a code block 15b for a storage device converted so as to be executable in the storage device 14 as a code block to be separated. The separation execution in the above state is a form in which the host terminal 13 requests the storage device 14 to return the result of the part removed from the execution execution based on the execution execution content 15a .

Accordingly, the executable content to which the present invention is applied refers to content including an executable file, for example, a game program and an application program.

1, the network 11 performs a series of data transmission / reception for data transmission and information exchange between the content providing server 12 and the host terminal 13. [ For this purpose, the network 11 may be an IP network providing large capacity data transmission / reception service and seamless data service through IP, and may be an ALL-IP network having an IP network structure in which different networks are integrated based on IP. The network 11 includes a wired communication network, a mobile communication network, a wireless broadband (WiBro) network, a high-speed downlink packet access (HSDPA) network, a satellite communication network or other well-known or future wired or wireless networks or a combination thereof.

The content providing server 12 stores separate execution execution type content 15a and a storage device code block 15b and provides the same to the host terminal 13 at the request of the customer. The content providing server 12 may further perform a function of converting executable content into separate execution execution type content 15a and a storage device code block 15b so that the executable content can be separately executed.

The host terminal 13 collectively refers to a computing device having an independent CPU capable of executing executable content, such as a PC, a notebook, a workstation, a PDA, and the like. The host terminal 13 includes a public computer which is accessible by a plurality of users. The host terminal 13 is provided with an execution-based execution content 15a. When the storage device 14 is connected to the host terminal 13 via the wired / wireless interface, the host terminal 13 performs separation execution of the executable content in cooperation with the storage device 14. [ In addition, the host terminal 13 requests the content providing server 12 to purchase the executable content at the request of the user, and transmits the execution-based content 15a and the storage device The code block 15b is downloaded and the execution execution based executive content 15a is stored in its own memory and the storage code block 15b is transferred to the storage device 14. [

The wired / wireless interface connecting the host terminal 13 and the storage device 14 may be implemented using a wired communication method using USB, USB2, Serial / Parallel Port, Ethernet, TCP / IP, . Bluetooth, Zigbee, Ruby, Infrared Data Association (IrDA), and Ultra Wide Broadband (UWB) may be used as the short-range wireless communication method. In addition, various technologies to be developed in the future can be applied.

The storage device 14 is connected to the host terminal 13 via a wired / wireless interface and receives and stores and manages the storage device code block 15b through the host terminal 13. [ In order to safely store the code block 15b for the storage device, the storage device 14 preferably has a security function. In addition, the storage device 14 preferably includes a processor for performing a separate execution in conjunction with the host terminal 13. [ Thus, the storage device 14 executes the storage device code block 15b at the request of the host terminal 13 and returns the resultant value to the host terminal 13.

In the DRM system described above, the content provider provides separate execution-based execution content 15a to the host terminal 13 of a legitimate user through the content providing server 12, And stores block 15b. Thereafter, when a legitimate user connects the storage device 14 in which the storage device code block 15b is stored to the host terminal 13, the execution execution based on the execution execution based content 15a provided in the host terminal 13, Execution-based content is normally executed through interlocking between the host terminal 13 and the storage device 14, so that when the storage device code block 15b is not present, the execution-type content is normally executed I can not.

The basic concept of the execution-based execution content according to the present invention will be described with reference to FIGS. 2 and 3. FIG.

2 is a diagram schematically illustrating a data structure of an executive content to which the present invention is applied. Referring to FIG. 2, an executable content 20 to which the present invention is applied includes a plurality of files, for example, an executable file, Such as an application program interface (API), an API provided by the developer, or a dynamic linking library (DLL). Such an executive content 20 includes a code area 21 and a data area 23. Actually, the code area 21 and the data area 23 are mixed with each other. The code area 21 includes a plurality of basic block groups 27 made up of a plurality of basic blocks 25.

Here, the basic block 25 means a sequence of instructions having attributes of a single input and a single output, and is a property that does not allow entry from the outside to the inside As shown in Fig. That is, the basic block 25 is a continuous sentence (a group of codes) executed at a time from the beginning to the end, and is a group of sentences whose execution is not stopped due to the flow control in the middle.

3 is a diagram schematically illustrating the structure of an execution-based execution content according to the present invention.

Referring to FIG. 3, the execution-based execution content according to the present invention includes executable content 30 and at least one separate execution object code block 37.

The executive content 30 includes a code area 31 and a data area 33 in which a stub code 39 is inserted in place of one or more separate execution object code blocks 37. [ At this time, the stub code 39 is a code to be inserted in place of the extracted separation execution object code block 37, and connects the execution contents 30 and the separation execution object code block 37. More specifically, when executing the executable content 30, the stub code 39 calls the corresponding detached execution object code block 37, and the result of the called detached execution object code block 37 Returns a value.

One or more separate execution object code blocks 37 are one of a plurality of basic block groups 27 extracted from the code area 31 through dynamic profiling and static analysis of the original executive contents 20, And includes a plurality of basic blocks 35. More preferably, the detachment object code block 37 permits the entry of the control signal through the entry point and the movement of the control signal between the basic blocks 35 contained therein, 35, which are not related to each other.

Alternatively, when the basic block group in which the control signal enters the basic block 35 excluding the starting point is selected as the separation execution object code block 37, the separation execution object code block 37 is extracted and inserted The control signal may enter the stub code 39 in the middle of the stub code 39. In this case, the stub code 39 can not perform processing for the corresponding control signal, It may be stopped or an error may occur.

An extraction method of the separation execution object code block 37 having such a characteristic is as follows.

First, a plurality of basic block groups 27 are selected through dynamic profiling and static analysis of the code area 21 of the executable content 20 to be separated. The selection of the plurality of basic block groups 27 is performed by executing the executive content 20 to collect basic information about the code area 21 during the run-time, and using the collected basic information, And performing static analysis on the code area 21 through extended dynamic profiling. Here, the basic information is at least one indirect address among a branch address, a jump address, a call address, and an indirect address of RET. The basic information related to the published API of the executive content 20 is removed from the basic information and the basic information related to the published API is removed from the code area 21 of the executive content 20 based on the removed basic information By performing a static analysis on the subject, the scope of analysis can be extended. The analysis range can be extended by substituting the indirect address among the collected basic information on the control flow. As a result, more basic block groups 27 can be selected than performing dynamic profiling or static analysis alone have.

In addition, when a control signal for entering the inside of the basic block group 27 is generated among the selected plurality of basic block groups 27, the corresponding basic block group 27 is divided based on the command address of the control signal, do. At this time, the basic block group 27 to be redefined redefines the previous first basic block group and the subsequent second basic block group including the command address of the control signal based on the command address of the control signal.

By repeating this redefinition process, a basic block group 27 including a plurality of basic blocks 25 having attributes of a single input and a single output and an attribute not allowing entry from the outside to the inside is finally obtained More precisely defined.

Then, the separation execution object code block 37 is selected from among the plurality of basic block groups 27. [ Then, the separation execution object code block 37 is separated from the code area 31, and the stub code 39 is inserted instead of the separation execution object code block 37.

At this time, it is preferable that the separation execution object code block 37 selects a basic block group on the critical path of the executive contents 20 among the plurality of basic block groups 27. [ In addition, it is possible to select the code block 37 for separation execution in consideration of the number of calls, the size, and the execution time among the plurality of basic block groups 27. [ For example, the basic block group 27 having a large number of calls, a small size, and a short execution time is selected by the separation execution object code block 37.

According to the present invention, in the executable content, a basic block group existing on an important path and having a large number of calls, a small size, and a short execution time is selected as a separation execution target code block for security, The execution performance of the executable content can be improved.

Further, by performing static analysis using the basic information of the code area collected through dynamic profiling to extract a basic block group, the scope of analysis of the code area of the executable content is extended, The extraction rate of the group can be improved.

In addition, by providing flexibility to redefine a once-defined basic block group, a basic block group having a single input and a single output, which can be candidate candidates for a separate code block, It is possible to inhibit selection of an unsuitable basic block group having an entry of the control signal into the inside thereof excluding the entry point as a code block to be detached. As a result, It is possible to suppress the occurrence of an error during execution.

Referring again to FIG. 1, the content providing server 12 selects the separation execution object code block 37 to separate the separation execution object code block 37, In converting the separation execution object code block 37 into the storage device code block 15b, the content is converted so that the executable content 15a and the storage device code block 15b can be executed in cooperation with each other.

FIG. 4 is a diagram for explaining a structure of a separation-based execution content and a separation execution method in the digital rights management system to which the present invention is applied. Hereinafter, the process of configuring the execution-based execution content based on the separation will be described.

First, an auxiliary execution code 158 for mutual interoperation between the execution-based execution content 15a and the storage device code block 15b is generated, a stub code 153b is generated, Insert at the location of the block. The auxiliary execution code 158 is executed by a call of the stub code 153b to pack the information of the stack and the register transferred at the time of the call, 15b, and restores the information of the stack and registers to the execution result value of the storage device code block 15b returned from the storage device 14 when the call is terminated. The stub code 153b jumps to the auxiliary execution code 158 at the beginning of the corresponding detachment execution target code block and then when the execution of the auxiliary execution code 158 is completed, Jump.

The storage device code block 15b is based on the platform of the storage device 14. For example, when the storage device 14 is implemented as a Java Card, it is a code block for Java and a code block for ARM. The storage device code block 15b may be implemented as an applet or may be included in an RO. Specifically, it can be implemented as a Java applet and a Java applet with an embedded ARM instruction. At this time, the auxiliary execution code 158 is a native launcher for executing the Java applet described above. In addition, the auxiliary execution code 158 can be implemented as a dynamic link library (DLL) file so that it can be loaded and executed only when necessary.

In addition to the insertion of the stub code 153b, an import table 155a of the import area 155 is loaded in the native launcher DLL 155a for loading the auxiliary executable code 158, . The insertion of the auxiliary execution code 158 into the import table is performed by the loader of the OS when the detachment execution based executive content 15a is executed in the host terminal 13 To be loaded.

Through this method, it is possible to interact with the separate execution target code block without making large modifications to the source code of the execution-based execution content.

Then, the separation execution object code block 37 separated from the execution execution-based executive content 15a is converted from the storage device 14 into a executable code block 15b for a storage device. At this time, the storage device code block 15b can be converted into the instruction word of the processor provided in the storage device 14, thereby improving the execution speed. It is also preferable to convert the code block to be divided into a plurality of machine codes so as to be able to apply separate execution of executable contents to storage devices of various environments.

In addition, an initial code block to be initially executed in the separation execution based executive content 15a is selected, the selected initial code block is encrypted with a specific key, and then the encrypted initial code block 157a is added to the generated security area And a start stub code (hereinafter referred to as a " start code ") 157 for calling a specific function of the auxiliary execution code 158 to decrypt the encrypted initial code block 157a after acquiring the key at the position of the initial code block 153a.

At this time, the key used for encryption is provided to the user in the form of a content encryption key (CEK) of a right object (RO) since it is required for decryption at the time of execution of executable content. .

The encrypted initial code block 157a is thereafter decoded by the auxiliary execution code 158 and is run in an on-memory state. According to this, the first level security technique through encryption can be applied to the executable content at the initial driving, and the second level security technique can be applied at the same time through separate execution. As a result, illegal use and duplication of the executable content can be prevented It can be blocked more strongly.

The content illustrated in FIG. 4 is a PE format file, which includes a DOS header 151 and a PE header 152, a code area 153, a data area 154, and an import section 155 , And an export section 160. [ The code area 153 is a group of actually executed program codes. The data area 154 is a group of initialized program data. The import area 155 is used when the PE file is executed, Functions, and the export area 156 exposes functions that can be used externally.

The auxiliary execution code 158 includes an interface function unit 158a, a packing function unit 158b, an unpacking function unit 158c, a memory mapping function unit 158d, an OS API Mapping function 158e, and in addition, may further include a code decoding function 158f.

The interface function unit 158a provides a communication channel with the storage device 14, and more specifically with the storage device code block 15b, to exchange data over the communication channel. For example, the interface function unit 158a may provide a communication channel with the storage device code block 15b through an APDU (Application Protocol Data Unit) defined in ISO-7816. It is preferable that the interface function unit 158a provides a Network bearer transparent interface so that other functional units of the auxiliary executable code 158 are not changed even if other kinds of interfaces such as TCP / IP Over USB are applied in the future. The interface function unit 158a has the same type of function as general I / O functions.

The packing function unit 158b receives the stack and register information from the stub code 153b, packs it, and transfers it to the storage device code block 15b through the interface function unit 158a. Here, the stack information is a collection of stack values used as a parameter starting from the stack position designated by the SP register, and the register information is transmitted when the stub code 153b calls the code block 15b for storage Register information.

The unpacking function unit 158c unpacks the packing data transferred from the storage device code block 15b executed via the interface function unit 158a and returns the packing data to the stub code 153b. When the result value returned from the storage device code block 15b is a primitive data type, the unpacking function unit 158b simply sets the result value returned to the value of the corresponding register. If the result value is a memory address, To the value returned.

The memory mapping function unit 158d writes the data transferred from the storage device code block 15b to the memory of the host terminal 13 via the interface function unit 158a, And transmits it to the code block 15b for the storage device. The storage device code block 15b can refer to the memory of the host terminal 13 through the memory mapping function unit 158c.

The OS API mapping function unit 158e receives the API name and the parameter value from the storage device code block 15b via the interface function unit 158a and calls the OS API of the host terminal 13, And transfers it to the storage device code block 15b. Thus, the storage device code block 15b stored in the storage device 14 can call the OS API of the host terminal 13 and return the result.

The code decryption function unit 158e acquires a specific key from the storage device 15b, decrypts the encrypted initial code block 157a loaded in the secure area 157, and then executes the decrypted initial code block. More specifically, a decoded initial code block is immediately executed in a memory by a runtime code executioner. The runtime code executor maps an instruction pointer to the decoded initial code block, And executes the decoded initial code block. In this case, the decoded initial code block exists in the memory only at the time of execution of the execution-based real content, and the execution is immediately terminated, thereby further enhancing the security effect.

The separation execution using the auxiliary execution code 158 configured as described above is performed as follows.

First, when the execution-based execution content 15a starts to run, the auxiliary execution code 158 is loaded (①) by the startup stub code 153a located at the beginning of the code area 153 (158) is called to obtain the encrypted initial code block 157a loaded in the secure area 157 ((2)), obtains the key (CEK) necessary for decryption (3) (157) is decoded and then executed (4). Subsequently, when the next program code in the code area is executed in order and enters the stub code 153b, the packing function part 158b is called by the stub code 153b, and the called packing function part 158b The stack and register information transferred from the stub code 153b are packed and transferred to the storage device code block 15b of the storage device 14 via the interface function unit 158a (step 5). The storage device code block 15b is connected to the host device 13 via the memory mapping function 158c and the OS API mapping function 158d. Memory and OS APIs can be accessed (⑥). When the execution of the storage device code block 15b is completed as described above, the result value is transferred to the auxiliary execution code 158 via the interface function unit 158b, and the unpacking function unit 158b transfers the result The value is again unpacked and returned to the stub code 153b (7).

This makes it possible for the execution-based execution content 15a and the storage device code block 15b to operate normally through interlocking of the host terminal 13 and the storage device 14.

In this case, the code block 15b for a storage device may embed processor instructions (for example, an ARM binary) of the storage device in order to improve execution speed. On the other hand, the operating system of the smart card or USIM, which can be used as the storage device 14, can be implemented in an interpreted language (e.g., Java).

Therefore, in order to improve the separation execution speed, it is necessary to perform a native execution that implements an environment for executing a code block 15b for a storage device in which a processor instruction is embedded in a storage device 14 having an operating system based on an interpreted language Environment implementation device is needed.

FIG. 5 is a block diagram showing a detailed configuration of a storage device 14 to which a native execution environment implementation apparatus according to the present invention is applied. In FIG. 5, the apparatus for implementing a native execution environment according to the present invention is implemented in the form of a software module.

5, the storage device 14 to which the present invention is applied includes an operating system (OS) 140 and a native execution environment implementation apparatus 100, and includes a host terminal 13, And a DRM agent 142 for a storage device for managing a right object (RO) 143 in cooperation with the DRM agent 142. [ Here, when the storage device 14 is implemented on a Java Card basis, the native execution environment implementing apparatus 100 is called through a JCVM (Java Card Virtual Machine).

The operating system 140 collectively manages and operates the hardware elements (CPU, ROM, RAM, EEPROM, I / O interface, etc.) of the storage device 14 and communicates with the host terminal 13, Reading and writing data to and from a file, access control of a file, user authentication, and execution of an application program. Such an operating system 140 is implemented in different forms according to each manufacturer. To solve the problems, an open platform such as JavaCard and MULTOS is mainly used.

The DRM agent 142 for the storage device performs a function of installing and managing a right object (RO) on the detachment-based execution content 15a and provides a management function for the certificate of the storage device 14. [ In addition, when the certificate and the RO are authenticated, the DRM agent 142 for the storage device connects the host terminal 13 and the secure channel so that information for separation execution can be exchanged. More specifically, the DRM agent 142 for the storage device receives the execution request for the storage device code block 15b from the auxiliary execution code 158 of the host terminal 13, and the storage device code block 15b ) Is completed, the resultant value is returned to the host terminal 13.

The native execution environment implementation apparatus 100 executes the processor instructions built in the storage device code block 15b for improving the separation execution speed. More specifically, the native execution environment implementing apparatus 100 receives the storage device code block 15b from the DRM agent 142 for the storage apparatus and executes the same. To this end, the native execution environment implementing device 100 exists in the form of an extension module of the operating system 140, loads the transferred storage device code block 15b, and fixes all non-fixed reference variables (Hereinafter referred to as " linking "). In addition, the native execution environment implementing apparatus 100 detects and processes the memory access and OS API calls of the host terminal 13 for execution of the storage device code block 15b.

For example, when the operating system 140 of the storage device 14 is implemented as a Java Card, the native execution environment implementation apparatus 100 may be implemented using a Java Native Interface (JNI) supported by Javacard . Also, the code block 15b for the storage device is implemented as a PIB (Position Independent Binary). Accordingly, the native execution environment implementing apparatus 100 is activated through a JNI call. At first, the native execution environment implementing apparatus 100 executes runtime linking of the transferred PIB, and then operates the IP register to jump to the start address to drive the code.

FIG. 6 is a block diagram illustrating a detailed configuration of an apparatus 100 for implementing a native execution environment according to the present invention. The configuration and operation of the native execution environment implementation apparatus will be described in more detail with reference to FIG.

6, the native execution environment implementing apparatus 100 includes a loader 110, an executor 120, a task manager 130, a memory mapper 130, (OS) API mapper 150, and a memory manager 160. The OS API mapper 150 includes a CPU 140,

The loader 110 links the code block 15b for a storage device stored in a specific area of the memory at runtime and loads the code block 15b into an arbitrary area on the memory. The storage unit code block 15b is a PIB (Position Independent Binary).

Fig. 7 is a block diagram for explaining the function of the loader 110. Fig. Referring to FIG. 7, the storage device code block 15b includes a data area in which data such as parameters are recorded, a code area in which a code to be executed is recorded, a header, and reference information, which is reference information for linking, , The reference value of each code in the code area is not fixed.

Therefore, the loader 110 loads the storage device code block 15b stored in the specific area OxOfO2 of the memory into an arbitrary area (Oxee00, Oxee10) of the memory. At this time, referring to the reference information, . For example, the data area of the storage device code block 15b is stored in the Oxee 10 on the memory, and the reference value of the code Loadr1 whose reference value is not fixed is fixed to the address Oxee10 of the data area while the code area is stored in Ox0e00.

6, the executor 120 forcibly invokes the entry point of the storage device code block 15b loaded by the loader 110, and executes the code block 15b for the storage device.

The implementer 120 is the entity of the code block to be actually executed, and the JNI function interface is also placed in the executor 120 in the Java Card-based storage device.

In addition, when the implementer 120 initially receives the storage device code block 15b via the JNI from the host terminal 13, the executor 120 calls the loader 110 to load the storage device code block 15b , And then takes charge of the execution of the loaded storage device code block 15b.

If the executioner 120 is to wait for a response from the host terminal 13 through the memory mapper 140 and the OS API mapper 150, the executioner 120 may determine that the instruction point and the register value Stored in the form of a context, and when a response of the host terminal 13 arrives, it refers to the stored value and restarts it from the corresponding instruction point.

In addition, a part of the executor 120 performs communication with the host terminal 13. [ More specifically, when a value of a specific header comes from the host terminal 13 through the operating system 140, the data and the length excluding the header are transmitted to the other part of the executor 120, 120, and transfers the result to the host terminal 13. The host terminal 13 then transmits the result to the host terminal 13. [ The protocol for this can be standardized and processed between the auxiliary execution code 158 of the host terminal 13 and the native execution environment implementing apparatus 100.

The task manager 130 manages a task control block (TCB) of a plurality of storage device code blocks 15b and manages data transferred from the auxiliary execution code 158 of the host terminal 13 to each TCB And transmits the execution result to the corresponding auxiliary execution code 158 of the host terminal 13. [ Thereby, a plurality of storage device code blocks 15b can be matched with the corresponding auxiliary execution code 158 of the host terminal 13 and executed.

In the host terminal 13, a plurality of execution-based execution contents 15a can be executed according to a user's selection, and an auxiliary execution code 158 is generated and operated for each execution type content. Therefore, a plurality of storage-use code blocks 15b corresponding to the plurality of auxiliary execution codes 158 can be stored and executed on the storage device 14 side. To this end, a plurality of tasks matching 1: 1 to a plurality of auxiliary execution codes 158 of the host terminal 13 are required.

Accordingly, the task manager 130 generates and manages a plurality of task control blocks (TCBs) 1: 1 mapped to a plurality of auxiliary execution codes 158 of the host terminal 13, So that the code block 15b for the storage device can be executed in conjunction with the corresponding auxiliary execution code 158. [

8 is a diagram showing the relationship between the TCB and the host terminal 13 in the native execution environment realization apparatus according to the present invention. As shown in the figure, the plurality of TCBs 131 generated by the task manager 130 of the native execution environment implementing apparatus 100 are respectively added to a plurality of executable contents 15a executed in the host terminal 13 1: 1 with a plurality of auxiliary executable codes 158 that are executed.

In addition, this TCB 131 must be executed before the corresponding auxiliary execution code 158 is executed. In order to do this, the TCB 131 must be generated in advance according to whether or not the RO is executed before the execution of the auxiliary execution code 158 when each execution content 15a is executed.

9 is a message flow diagram illustrating a process of generating a TCB in an apparatus for implementing a native execution environment according to the present invention. 9 shows an example of a Java based storage device.

9, when the host terminal 13 requests a check of the contents of the RO (S91) due to the execution of the executable content 15a or the like, if the OS 140 checks the RO and has authority, And instructs the native execution environment implementing apparatus 100 via the JCVM 141 to generate a task (S92 to S94). The native execution environment implementing apparatus 100, more specifically, the task manager 130 creates the TCB (S95), and returns the execution result to the OS 140 and the JCVM 141 (S96, S97) .

According to the above description, the TCB is generated at the time of checking the RO in the host terminal 13, so that the corresponding TCB can be prepared before the auxiliary execution code 158 is executed.

The generated TCB is removed when the corresponding executive content is terminated in the host terminal 13 or the power of the storage device 14 is turned off.

10 is a message flow diagram illustrating a process of removing a TCB in response to an execution end of execution content in an apparatus for implementing a native execution environment according to the present invention.

The end of the executable content 15a is notified to the OS 140 of the storage device 14 by the auxiliary execution code 158 when the execution content 15a ends in the host terminal 13 (S1001) . The OS 140 transfers the end of the executable content 15a to the native execution environment implementing apparatus 100 (S1002), and the task manager 130 of the native execution environment implementing apparatus 100, (S1003), and notifies the host terminal 13 of the execution result through the OS 140 (S1004, 1005).

Referring again to FIG. 6, the memory mapper 140, when the memory reference of the host terminal 13 is required during execution of the storage device code block 15b by the executor 120, So that the host terminal 13 can be referred to via the auxiliary execution code 158 of FIG. More specifically, the loader 110 links the memory mapper 140 to the memory mapper 140 when there is a code in the storage device code block 15b, which refers to the memory of the host terminal 13, during the linking process . Accordingly, when the memory mapper 140 is called in the executing storage device code block 15b, this call is packaged and transferred to the auxiliary execution code 158 of the host terminal 13, and the auxiliary execution code 158 And transmits the result of the analysis to the performer 120.

The OS API mapper 150 calls the OS API of the host terminal 13 in conjunction with the auxiliary execution code 158 of the host terminal 13 during execution of the storage device code block 15b And to receive the results of the execution. More specifically, the loader 110 links the OS API mapper 150 to the code referring to the OS API of the host terminal 13 in the storage device code block 15b during the linking process . If the OS API mapper 150 is invoked during execution of the storage device code block 15b, the OS API mapper 150 packages the call and sends the OS API mapper 150 to the auxiliary execution code 158 of the host terminal 13 Analyzes the response from the auxiliary execution code 158, and transmits the interpreted response to the executor 120.

Finally, the memory manager 160 allocates a memory from the operating system 140 for execution of the detachment, and allocates the memory to the loader 110, the executor 120, the task manager 130, the memory mapper 140, and the OS API mapper 150, as shown in FIG.

In general, memory management in an embedded environment is optimized for developing and porting a platform, which is insufficient for use in the native execution environment implementing apparatus 100.

When the native execution environment implementing apparatus 100 is initially executed, the memory manager 160 allocates a memory from the operating system 140 to the loader 110, the executor 120, the task manager 130 ), The memory mapper 140, and the OS API mapper 150, as shown in FIG.

More specifically, the operating system 140 allocates memory for the native execution environment implementing apparatus 100, and provides the memory manager 160 with the start address and usable size of the assigned Heap. At this time, the memory allocated for the native execution environment implementing apparatus 100 should be fixed and not be used by any other apparatus except for the native execution environment implementing apparatus 100. Also, the start address of the Heap must be a multiple of four. The memory manager 160 implements functions such as malloc and free for the heap allocated in this manner and executes the functions of the loader 110, the executor 120, the task manager 130, the memory mapper 140, So that it can be used in the mapper 150.

In particular, the memory manager 160 allocates a dynamic memory with 4-byte alignment for the native execution environment implementing apparatus 100, divides the allocated dynamic memory into 10 groups (size-class) Compaction is supported. More specifically, merging physically contiguous Free memory blocks and minimizing memory fragmentation.

12 shows a structure of a memory block managed by the memory manager 160. As shown in FIG. 12, the memory block of the memory manager 160 includes a dynamic allocation memory 162 in which real data is stored, a 16-byte header 161 in front of the dynamic allocation memory 162, . The size of the memory block physically located in front of the corresponding memory block and the check bit for the memory group are recorded in the first section, The size of the memory block and whether or not the memory block is used are recorded in the section. In the third section, a pointer of a free memory block positioned next to the memory block and an application ID allocated to the memory block are recorded. In the fourth section, the address of the free memory block located in front of the memory block and the indirect address of the actual data are recorded.

The dynamic allocation memory block is managed through the header 161 having the above structure.

On the other hand, in the case of a storage device such as a smart card, the number of times of writing is limited in the NOR memory or the NAND memory. Also, a file system that can be used through a minimum access when NOR memory or NAND memory is used is implemented.

The native execution environment implementation apparatus 100 according to the present invention, as shown in FIG. 13, allocates a certain area of the ROM from the OS 141 to implement a file system.

The implementation of the cache using the file system constituted by the existing flash memory has a performance limitation due to the physical limitations of the storage device 14 itself. However, in the present invention, the file system that can implement the cache in the ROM, Thereby solving the conventional performance constraint problem. The file system includes an RFS (Remote File Storage) API such as Open, Read, Write, Attribute, Remove, and Rename as in the existing file system.

The native execution environment implementing apparatus according to the present invention may be implemented in a form of software readable by various computer means and recorded in a computer-readable recording medium. Here, the recording medium may include program commands, data files, data structures, and the like, alone or in combination. Program instructions to be recorded on a recording medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software. For example, the recording medium may be a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, an optical medium such as a CD-ROM or a DVD, a magneto-optical medium such as a floppy disk magneto-optical media, and hardware devices that are specially configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions may include machine language code such as those generated by a compiler, as well as high-level language code that may be executed by a computer using an interpreter or the like. Such a hardware device may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, It will be apparent to those skilled in the art. Furthermore, although specific terms are used in this specification and the drawings, they are used in a generic sense only to facilitate the description of the invention and to facilitate understanding of the invention, and are not intended to limit the scope of the invention.

The present invention separates arbitrary code blocks existing in the code area of the executable contents and causes them to be executed in the storage device, thereby making it impossible for the executable contents to operate normally in the absence of the separated code blocks, There is an excellent effect that the illegal copying and use of the contents can be blocked at the source.

In addition, the present invention separates and executes an arbitrary code block in the executable content, converts the processor command of the storage device into a built-in form, further generates an auxiliary execution code for separate execution, And executing the code block stored in the storage device and receiving the result of the execution of the code block, so that the executable content can be executed separately through interlocking between the host terminal and the storage device. In particular, Card or a USIM.

In addition, the present invention improves the separation execution speed for a code block for a storage device by executing the separated code block with a processor instruction through a native execution environment implementing device implemented in an extended form of an operating system in a storage device .

10: Digital Rights Management System
11: Network 12: Content providing server
13: Host terminal 14: Storage device
15a: detached execution-based executable content 15b: code block for storage device
100: native execution environment implementation device 110: loader
120: Actor 130: Task Manager
140: Memory Mapper 150: OS API Mapper
160: Memory Manager

Claims (18)

1. A storage device for storing a code block for a storage device separated from an executable content and executing separation execution of executable content in cooperation with a host terminal,
An operating system for managing and operating a hardware element of a storage device and performing at least one of communication with the host terminal, reading and writing data to and from an internal memory, file access control, user authentication, and execution of an application program; And
And a native execution environment implementation device implemented in an extended form of the operating system, loading a code block for a storage device separated from the executable content, performing runtime linking and execution, and providing the execution result to the host terminal,
Wherein the code block for a storage device is a code block to be separated from the code area of the executable content, the code block being separated from the code area of the executable content, Wherein the basic block group is a basic block group on a predetermined path among the execution paths of the executable content among a plurality of basic block groups made up of a plurality of basic blocks. The method according to claim 1,
And a DRM (Digital Right Management) agent for a storage device that performs installation and management functions for the RO (Right Object) of the executable content and connects the host terminal and the secure channel to exchange information for separation execution . An apparatus for implementing a native execution environment of a storage device connected to a host terminal,
A loader for loading a code block to be executed and performing linking to fix a reference value of a code whose reference value is not defined in a position independent binary (PIB);
An executor for forcing an entry point of a code block loaded by the loader to execute the code block;
A Task Control Block (TCB) is generated and managed by mapping the data to a plurality of applications of the host terminal in a one-to-one manner, and the data transmitted from the host terminal through the TCB is transferred to the executor, And a task manager for returning to the terminal,
Wherein the code block is a code block for a storage device in which a code block to be separated from the code area of the executable content is converted into a form executable on a storage device, Wherein the basic block group is a basic block group on a predetermined path among execution paths of the executable content among a plurality of basic block groups made up of a plurality of existing basic blocks. The method of claim 3,
And a memory mapper for transferring a memory reference request to the host terminal when the memory reference of the host terminal is required during execution of the code block and returning a result of the memory reference request to the host terminal and delivering the result to the executor Wherein the native execution environment implementation device is a native execution environment implementation device. The method of claim 3,
Further comprising an OS API mapper operable to interoperate with the host terminal during execution of the code block to call the OS API of the host terminal and to return the result to the executor. . The method of claim 3,
Further comprising a memory manager for allocating and managing a memory to be used for execution of the code block from an operating system of the storage device. 4. The method of claim 3, wherein the executor
And when the code block is transferred from the host terminal, calling the loader is performed. 4. The method of claim 3, wherein the executor
Wherein when a response of the host terminal is to be waited for during execution of the code block, an instruction point and a register value that are currently being executed are stored in a context type, and when a response of the host terminal is received, And re-driving the instruction from the corresponding instruction point. 4. The system of claim 3, wherein the task manager
When a right object is checked at the host terminal, if the right to use is authorized, the TCB is generated, and when the corresponding application is terminated at the host terminal or the power of the storage device is turned off, To the native execution environment. 5. The method of claim 4,
Wherein the loader links the memory mapper to the memory block when the code block includes a code that refers to the memory of the host terminal during the linking process,
Wherein when the memory mapper is invoked during execution of the code block, the memory mapper delivers the call to the host terminal, receives the processing result from the host terminal, and analyzes and analyzes the result of the processing to the executor. Device. 6. The method of claim 5,
Wherein the loader links the OS API mapper to a code referring to the OS API of the host terminal in the code block during a linking process,
Wherein the OS API mapper packages the call and delivers the call to the host terminal when the OS API mapper is invoked during execution of the code block and interprets the response of the host terminal and delivers the interpreted response to the executor. . 7. The system of claim 6, wherein the memory manager
The dynamic memory is allocated from the operating system with 4-byte alignment, the allocated dynamic memory is divided into a plurality of groups (size-class) and managed, partial memory compaction is supported, and physically adjacent free memory blocks are merged Wherein the native execution environment implementation apparatus comprises: 13. The method of claim 12, wherein the memory block managed by the memory manager
A dynamic allocation memory in which real data is stored, and a header located in front of the dynamic allocation memory,
The header includes a first section in which a size of a memory block physically located at a front side, a check bit for a memory group are recorded, a size of the memory block, a second section in which whether or not the memory block is used is recorded, A third section in which a pointer of a free memory block positioned next to the memory block and an application ID allocated to the memory block are recorded and an indirect address of the free memory block in front of the memory block and an indirect address of the data are recorded And a fourth section. delete 4. The apparatus of claim 3, wherein the code block for storage comprises:
Wherein the processor is a code for embedding processor instructions of the storage device. delete 4. The method of claim 3, wherein the basic block group
A plurality of basic blocks which are associated with each other and which do not allow control signals to enter into the plurality of basic blocks except for the start point, Block of the native execution environment. 18. The method of claim 17,
Wherein the basic block is a code block having attributes of a single input and a single output and an attribute of not allowing entry of an external control signal into the internal block.

Images