KR20110013197A - Method for communicating based on ums, host terminal, and medium recorded program thereof - Google Patents

Abstract

PURPOSE: A USB-based communication method, a host terminal, and a recording medium which records a program for the same are provided to use a storing device as a UMS type and use a file operation through UMS, thereby enabling a PC to communicate with a storing device without a separate device. CONSTITUTION: An interface unit communicate with a storing device(60). An API wrapper(520) provides an API for exchanging an APDU(Application Protocol Data Unit) message with a storing device. If a host program calls the API, the API wrapper receives data for performing calculation about a file in a storing device from the host program. If the data is received from the API wrapper, an APDU agent(530) generates thread using the received data.

Description

WMS-based communication method, host terminal, recording medium recording a program therefor {Method for communicating based on UMS, host terminal, and medium recorded program approximately}

The present invention relates to a UMS (USB Mass Storage) based communication method, and more particularly, to a UMS-based communication method, a host terminal, and a recording medium for recording a program therefor, which can communicate without a separate driver using a storage device in the form of a UMS. .

Conventional PCs and storage devices, such as smart cards, communicate using the APDU (Application Protocol Data Unit) protocol through a reader. However, there is a disadvantage in that it is much slower in terms of communication speed. Therefore, the communication speed is complemented by using a universal serial bus (USB).

However, in order to use the USB type storage device in the host PC, a separate device driver must be installed in the host, which is inconvenient.

In addition, the Windows operating system requires administrator privileges to directly open UMS devices due to its security mechanism.However, if a user simply accesses a file on a UMS device, the file can be accessed even if it is not an administrator. There is a problem in that communication with the storage device can be performed through operations on such a file without a user mistake or a file can be deleted arbitrarily.

The present invention has been proposed to solve the above-mentioned conventional problems, by using a storage device in the form of UMS (USB Mass Storage) for communication with the storage device in a PC to enable communication without installing a separate driver, all users It is an object of the present invention to provide a UMS-based communication method, a host terminal, and a recording medium recording a program therefor, which allows a user to use a storage device regardless of authority.

The host terminal for UMS (USB Mass Storage) based communication of the present invention for achieving the above object, the interface unit for communication with the storage device, the API (Application) for exchanging storage device and APDU (Application Protocol Data Unit) messages Protocol Interface), and when a host program calls an API, it receives the data from an API wrapper and an API wrapper that receives and delivers data for performing an operation on a file in a storage device. A thread is created using one data to perform an operation on a file in a storage device through an interface, and when the operation is completed, the received data is returned to the API wrapper, and data processing uses a FIFO queue. Contains an APDU agent.

In the host terminal for UMS-based communication of the present invention, the API wrapper and the APDU agent transmit and receive data using a UDP socket (User Datagram Protocol Socket).

In the host terminal for the UMS-based communication of the present invention, the UDP socket is characterized in that the asynchronous method.

In the host terminal for UMS-based communication of the present invention, the API wrapper is characterized by transmitting the data encrypted.

 In the host terminal for UMS-based communication of the present invention, the API wrapper is characterized in that the data is encrypted using an XOR operation.

In the host terminal for the UMS-based communication of the present invention, the FIFO queue is characterized in that the circular queue.

In the host terminal for the UMS-based communication of the present invention, the APDU agent, when inserting or deleting data in the FIFO queue received from the API wrapper, it characterized in that it uses a mutex (Mutex) algorithm.

In the host terminal for the UMS-based communication of the present invention, the APDU agent is characterized in that when generating a file in the storage device to create a hidden file form.

In the host terminal for the UMS-based communication of the present invention, the APDU agent, if the file generated in the storage device is deleted, regenerates the generated file, and then performs a read or write operation on the regenerated file. It features.

In the host terminal for the UMS-based communication of the present invention, the file in the storage device is characterized in that it comprises a separate execution target code block.

In the host terminal for the UMS-based communication of the present invention, the host program is characterized in that the separation execution based content.

In the host terminal for the UMS-based communication of the present invention, the data is characterized in that it comprises packed stack information and register information.

In the UMS-based communication method of the present invention for achieving the above object, when the host terminal calls an API for exchanging APDU messages, the host terminal receives data for performing operations on files in the storage device from the host program A receiving step, an inserting step of inserting the data received by the host terminal into the FIFO queue, an operation performing step of reading the data inserted into the FIFO queue by the host terminal to perform an operation on a file in the storage device, and the host terminal in the storage device. Upon completion of the operation on the file, it includes a return step of extracting the inserted data and returning it to the host program.

In the UMS-based communication method of the present invention, the data is characterized by being encrypted.

In the UMS-based communication method of the present invention, data is encrypted using an XOR operation.

In the UMS-based communication method of the present invention, the FIFO queue is a circular queue.

In the UMS-based communication method of the present invention, when inserting or deleting data in a FIFO queue, a mutex algorithm is used.

In the UMS-based communication method of the present invention, the operation performing step is characterized in that when the host terminal performs an operation for generating a file in the storage device, it generates a hidden file.

In the UMS-based communication method of the present invention, in the operation performing step, when the file generated in the storage device is deleted, the host terminal regenerates the generated file and then reads or writes the regenerated file. It is characterized by.

In the UMS-based communication method of the present invention, the file in the storage device is characterized in that it comprises a separate execution target code block.

In the UMS-based communication method of the present invention, the host program is separated execution based content.

In the UMS-based communication method of the present invention, the data includes packed stack information and register information.

In the UMS-based communication method of the present invention, the separated execution target code block is located on a critical path of the executable content among a plurality of basic block groups composed of a plurality of basic blocks existing in the code area of the executable content. It is characterized in that the basic block group.

In the UMS-based communication method of the present invention, a basic block group allows entry of a control signal through an entry point and movement of a control signal between a plurality of basic blocks, and into a plurality of basic blocks except for a starting point. It is characterized in that the collection of a plurality of basic blocks associated with each other without the entry of the control signal.

In the UMS-based communication method of the present invention, a basic block is a code block having a property of a single input and a single output and a property of not allowing entry of a control signal from the outside to the inside. It is characterized by.

The present invention also provides a computer readable recording medium having recorded thereon a program implementing the above-described UMS based communication method.

According to the present invention, by using the storage device in the form of UMS, it is possible to communicate with the storage device without installing a separate driver in the PC.

In addition, by using the file operation through the UMS, it is possible to improve the existing communication speed problem, there is an advantage that all users can use the storage device regardless of permissions.

In addition, by providing the same interface to provide an API for exchanging messages between the existing PC and the storage device, it is possible to maintain compatibility with existing programs.

1 is a block diagram of a digital rights management system to which the present invention is applied.
2 is a block diagram showing a data structure of executable content in a digital rights management system to which the present invention is applied.
3 is a block diagram showing the structure of the separated execution based content in the digital rights management system to which the present invention is applied.
4 is a block diagram illustrating a separation execution based content composition module in a digital rights management system to which the present invention is applied.
5 is a diagram illustrating a stub code to be inserted into the executable content in the digital rights management system to which the present invention is applied.
FIG. 6 is a diagram illustrating a configuration of an auxiliary execution function unit in a separation execution based content of a digital rights management system to which the present invention is applied and a separation execution process through the same.
7 is an operation flowchart of a code decoding function unit in a digital rights management system to which the present invention is applied.
8 is a block diagram showing the structure of an auxiliary execution module in a storage device of a digital rights management system to which the present invention is applied.
9 is a block diagram showing a host terminal for UMS-based communication according to an embodiment of the present invention.
10 is a diagram showing a UMS-based communication method according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. However, in describing in detail the operating principle of the preferred embodiment of the present invention, if it is determined that the detailed description of the related known functions or configurations may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. In addition, the same reference numerals are used for parts having similar functions and functions throughout the drawings.

In the present specification, when one component 'transmits' data or a signal to another component, it may directly transmit data or a signal, and may transmit data or a signal through at least one other component. it means.

1 is a block diagram of a digital rights management system to which the present invention is applied.

Referring to FIG. 1, the digital rights management system to which the present invention is applied includes a content providing terminal 10, a content registration server 30, a digital rights management server 40, a host terminal 50, and a host terminal ( 50) is configured to include a storage device 60 connected via a wired or wireless interface. The UMS (USB Mass Storage) based communication method of the present invention is applied to communication between the host terminal 50 and the storage device 60.

In the present invention, the executable content 11 is a digital work that is stored and distributed in a digital form, and includes an application program, a game program, and a variety of software including a plurality of instructions to enable the executed device to perform any function. can do.

In addition, "separate execution" means that the executable content 11 is executed through the interworking of two different devices, more specifically, the host terminal 50 and the storage device 60. In order to implement such separation execution, the host terminal 50 stores the separation execution base content 37 from which a selected code block (hereinafter referred to as a separation execution target code block) in the code area is removed, and the storage device 60 stores the separation execution base content 37. A portion of the host terminal 50 removed from the separated execution based content 37 in a state in which the separated execution target code block 35 removed from the executable content 11 and converted into executable in the storage device 60 is stored ( Request to the storage device 60 a result value for the separation execution target code block).

In FIG. 1, the network 70 performs a series of data transmission / reception operations for data transmission and information exchange between the content providing terminal 10, the content registration server 30, the DRM server 40, and the host terminal 50. . The network 70 is an IP network providing a large data transmission / reception service and a seamless data service through IP, and may be an ALL-IP network, which is an IP network structure integrating different networks based on IP. In addition, the network 70 includes a wired communication network, a mobile communication network, a wireless broadband network (WiBro), a high-speed downlink packet access (HSDPA) network, a satellite communication network, or other well-known or future-developed wired or wireless networks or a combination thereof.

The content providing terminal 10 is a terminal operated by a content provider. The content providing terminal 10 communicates with the content registration server 30 through the network 70 and stores the executable content 11 developed by the content provider. The executable content 11 is transmitted to the registration server 30.

The content providing terminal 10 executes the profiling and analysis tool 33 downloaded from the content registration server 30 to perform dynamic profiling and static analysis on the executable content 11 to be registered. Profile data is generated from the executable content 11 to be separated and executed through analysis (hereinafter, referred to as 'profiling and analysis'), the code block selection rule is input, and the generated profile data and input are executed. The received code block selection rule and the executable content 11 to be separated are transmitted to the content registration server 30.

More specifically, the profiling and analysis tool 33 reads user preference information, determines which part to profile, and loads the corresponding PIN tool. Thereafter, the target executable content 11 is loaded into the memory, the PIN tool is inserted and executed, and the result (profile data) is stored.

Profile data essentially includes a code block start address, a code block end address, a code block call count (which is the number of times called during a profile), a code block size, and the presence or absence of a floating point operation. In addition, optionally, the number of host memory references of a code block, the number of calls to an OS API of the code block, the execution time of the code block, the total number of instructions performed on the code block, the parameters passed for the execution of the code block. The number and type, and the type of the value returned after execution of the code block may be included.

The code block selection rule is for setting weights to be given for each item of profile data. The user priority information for which weights can be set is a call to the separated execution target code block 35 to be selected by profiling. Frequency, call location, host memory reference frequency, and OS API reference frequency, and the hardware element of storage 60 in which the separate execution target code block 35 is to be stored.

Here, the call frequency indicates the degree of the call frequency of the code block to which the separate execution target code block 35 is selected among the executions of the executable content 11. In general, the higher the call frequency, the higher the security effect. The load on the device 60 may increase to reduce the overall execution speed of the executable content 11. Therefore, it is desirable to set an appropriate call frequency in accordance with the characteristics of the executable content 11. The call position indicates whether to select a code block to be called at the beginning of execution or to select a code block to be called at the time of setting a specific function in the selection of the separate execution target code block 35. The host memory reference frequency indicates the number of times the code block to be selected as the separated execution target code block 35 refers to the memory of the host terminal 50, and the OS API reference frequency refers to the OS API reference of the host terminal 50 in the code block. Frequency. In general, the higher the memory reference frequency and the OS API reference frequency, the higher the dependency on the host terminal 50. The code block having the high memory reference frequency and the OS API reference frequency is referred to as the separated execution code block 35. When selected, the security efficiency increases, but on the contrary, the execution speed decreases. Therefore, the memory reference frequency and the OS API reference frequency should be appropriately set according to the desired security level. The hardware elements of storage 60 include, for example, the amount of DRAM, NAND flash size, CPU speed, etc. of storage 60 in which separate execution target code block 35 is stored and executed.

By differently weighting each item of the profile data according to the above code block selection rule, the extracted execution target code block 35 is different, and thus the security level is changed.

Meanwhile, the code block selection rule may be set according to the nature of the executable content 11. For example, if the executable content 11 is a game program, execution speed is important, so it is desirable to reduce the host memory reference frequency and the OS API reference frequency to a minimum, in which case, the host memory and the OS API are referred to as a minimum. By selecting the basic code block to be the separated execution target code block 35, the execution speed of the executable content 11 can be minimized. In addition, in the sale of the separated execution based content 37, if the price of the storage device 60 is to be lowered as much as possible, the weight of the hardware element of the storage device 60 may be specified as low. According to this, while the price of the storage device 60 can be lowered, it should be taken into account that the execution speed can be somewhat lowered.

Of course, the above-described code block selection rules can further diversify the settable items.

The content registration server 30 provides the executable content 11 information received from the content providing terminal 10 to the host terminal 50 through a web page, and the separated execution based content 37 and the separated execution target code block. Create 35 and transmit it to the DRM server 40. In this case, the separated execution target code block 35 may be included in a program for the storage device 60 such as an applet and provided to the storage device 60.

Meanwhile, the executable content 11 is converted into the separated execution based content 37, and the DRM server 40, which will be described later, packages the separated execution based content 37 into the encrypted content 41 and the host terminal 50. Since the object provided to the user may be the encrypted content 41, an object that the user checks through a web page and decides to purchase is referred to as the executable content 11 for convenience of description below. .

The content registration server 30 generates the separation execution base content 37 and the separation execution target code block 35 based on the execution content 11 through the separation execution base content configuration module 31, and a detailed process will be described later. do.

The content registration server 30 provides a list of the executable content 11 and detailed information about the corresponding executable content 11 so that a user can purchase the executable content 11 through a web page.

Specifically, upon receiving a request signal for downloading the executable content 11 displayed on the web page from the host terminal 50, the content registration server 30 downloads DD (Download Descriptor) information of the corresponding executable content 11. To the host terminal 50.

The DD information refers to brief information about the executable content 11 or the rights object 43 such as a file name, file size, file provider, URL information of the corresponding executable content 11 or the rights object 43, and the like. It is received before downloading the type content 11 or the rights object 43 and temporarily stored in a buffer, and is automatically deleted when the execution type content 11 or the rights object 43 is downloaded.

In addition, when the content registration server 30 receives a purchase and repurchase request signal of the rights object 43 for the selected executable content 11 from the host terminal 50, the content registration server 30 triggers a purchase or repurchase to the DRM server 40 ( Trigger and, upon receiving the trigger and DD information for the rights object 43 from the DRM server 40, transmits to the host terminal 50. In addition, when the content registration server 30 receives a refund or transfer request signal of the rights object 43 for the selected executable content 11 from the host terminal 50, the content registration server 30 triggers a refund or transfer trigger to the DRM server 40. When the request is received and the corresponding trigger is received from the DRM server 40, the host device 50 transmits the trigger.

 The trigger is a message for starting the protocol execution for the purchase or repurchase, refund or transfer of the rights object 43 between the DRM server 40 and the host terminal 50, and the registration of the storage device 60.

The DRM server 40 packages the separated execution based content 37 received from the content registration server 30, and stores the details of the rights object 43 that created, managed, issued and issued the rights object 43. Server.

Here, the rights object 43 specifies a purchase relation and usage rights between the executable content 11 and the user with respect to the executable content 11 purchased by the user.

Specifically, the DRM server 40 generates a Contents Encryption Key (CEK), and separates execution based content 37 received from the content registration server 30 from an Open Mobile Alliance (OMA), a Digital Media Project (DMP), The package is packaged into encrypted content 41 according to technical standards set forth by DRM standardization organizations such as Moving Picture Experts Group (MPEG) -21 and Internet Streaming Media Alliance (ISMA). At this time, the DRM server 40 generates the decryption key included in the rights object 43 for decrypting the encrypted content 41, such as CEK used during packaging. In this case, the separation execution target code block 35 received from the content registration server 30 may be included in the rights object 43 and generated.

That is, the encrypted content 41 is a result of packaging the separated execution based content 37 in which the separated execution target code block 35 is replaced with the stub code in the executable content 11.

Here, when generating a CEK and packaging it with encrypted content 41, Advanced Encryption Standard (AES), Rivet-Shamir-Adelman (RSA), Elliptic Curve Cryptosystem (ECC), SEED block encryption algorithm, and DES (DES) Encryption algorithms such as Data Encryption Standard) may be used, but are not limited thereto.

In addition, the DRM server 40 generates a trigger and DD information for the rights object 43 when the user requests a purchase or trigger for the rights object 43 to be purchased or repurchased from the content registration server 30. When a request is made to the content registration server 30 and a refund or transfer trigger for the rights object 43 to be refunded or transferred from the content registration server 30 is requested, the trigger for the rights object 43 is triggered. It generates and transmits to the content registration server 30.

Subsequently, when the content download request is received from the host terminal 50, the corresponding encrypted content 41 is transmitted. When the request for purchase or repurchase of the rights object 43 is received, the rights object 43 is transmitted, and the rights object 43 is transmitted. When request for a refund or transfer of) is requested to delete the rights object 43 stored in the storage device (60).

The host terminal 50 may be a computing device having an independent central processing unit (CPU) capable of executing the executable content 11, such as a PC, a laptop, a workstation, a kiosk, an automated teller machine, an PDA, and a PDA. Personal Digital Assistants) and the like, and include a public computer that is accessible by a large number of users. The host terminal 50 communicates with the content registration server 30 and the DRM server 40 through the network 70, and communicates with the storage device 60 connected via a wired or wireless interface.

Here, the wired / wireless interface is a wired communication method using USB, USB2, Serial / Parallel Port, Ethernet, TCP / IP, communication cable, Bluetooth, Zigbee, Rubee, Infrared; A short range wireless communication method using Data Association, Ultra Wide Broadband (UWB), Near Field Communication (NFC), Wibro, or the like may be used.

Specifically, the host terminal 50 accesses a web page provided by the content registration server 30, selects the executable content 11 displayed on the web page, and requests a download from the content registration server 30. Subsequently, when the DD information of the executable content 11 is received from the content registration server 30, the encrypted content 41 for the executable content 11 is obtained by accessing the DRM server 40 using the DD information. Receive.

In addition, when the user wants to purchase and repurchase the rights object 43, the host terminal 50 transmits a request for purchase or repurchase of the rights object 43 to the executable content 11 to the content registration server 30. send. Subsequently, when the trigger and DD information for the rights object 43 are received from the content registration server 30, the rights object 43 is requested by accessing the DRM server 40 using the trigger. Thereafter, the received right object 43 is transmitted to the storage device 60 connected through the wired / wireless interface. In addition, when the user wants to purchase and repurchase the rights object 43, the host terminal 50 transmits a refund or transfer request signal for the rights object 43 to the content registration server 30. Subsequently, when a trigger for the rights object 43 is received from the content registration server 30, the trigger is connected to the DRM server 40 to request a refund or transfer.

For example, the user of the host terminal 50 already has the rights object 43 for the executable content 11 to be used, so only the encrypted content 41 for the executable content 11 is needed. It may be necessary, such as when purchasing the first executable content (11) or when the right object 43 expires and repurchases, only the rights object 43 for the executable content (11) may be needed. It may also require both encrypted content 41 and rights object 43.

In addition, when the host terminal 50 starts to execute the encrypted content 41, the host terminal 50 checks whether the right object 43 is stored in the storage device 60. When the rights object 43 is stored in the storage device 60, the decryption key included in the rights object 43 is requested from the storage device 60 to decrypt the encrypted content 41. On the other hand, if the rights object 43 is not stored in the storage device 60, the content registration server 30 may transmit a purchase or repurchase request signal. In addition, when the separation execution target code block 35 is stored in the storage device 60, the host terminal 50 decrypts the encrypted content 41 using the decryption key as the separation execution based content 37. Thereafter, in association with the storage device 60 connected through the wired / wireless interface, separation of the encrypted content 41 may be performed.

The storage device 60 may be any of a variety of portable devices incorporating a processor, such as a USB memory, a flash memory card, and various portable and portable storage media (e.g., a Secure Digital (SD) memory card, a microSD memory card, an ISO 7816 standard). Portable storage devices). The storage device 60 is connected to the host terminal 50 through a wired or wireless interface, and stores the rights object 43 for the encrypted content 41 installed in the host terminal 50.

As described above, the rights object 43 may include a decryption key for decrypting the encrypted content 41, and may include a separate execution target code block 35 for the separated execution based content 37. have. At this time, the storage device 60 performs an operation on the separation execution target code block 35 at the request of the host terminal 50 and returns a result value to the host terminal 50.

The basic concept of the above-described separation execution based content 37 will be described with reference to FIGS. 2 and 3.

2 is a block diagram showing a data structure of executable content in a digital rights management system to which the present invention is applied.

Referring to FIG. 2, the executable content 11 to which the present invention is applied may include a plurality of files, for example, a file such as an API provided by an operating system, an API provided by a developer, or a dynamic linking library (DLL). Include. The executable content 11 including the plurality of files may be divided into a code region 21 and a data region 23, and the actual executable content 11 may include a code region 21 and a data region 23. Are mixed with each other. The code area 21 includes a plurality of basic blocks 25, and includes a plurality of basic block groups 27 selected for extraction of the separated execution target code block 35.

Here, the basic block 25 is a sequence of instructions having attributes of a single input and a single output, and a code block having an attribute that does not allow entry from the outside to the inside. Can be defined as That is, the basic block 25 means a continuous sentence (a collection of codes) that is always executed all the time from the beginning to the end, and is a group of statements in which execution is not stopped due to flow control.

3 is a block diagram showing the structure of the separated execution based content in the digital rights management system to which the present invention is applied.

1 and 3, the detached execution based content 37 to which the present invention is applied includes a code region 21a in which stub codes are inserted in place of one or more detached execution target code blocks 35. ) And a data area 23. In this case, the stub code 26 is inserted in place of the separated execution target code block 35 extracted for the separation execution and connects the separation execution based content 37 and the separation execution target code block 35. Specifically, when the stub code 26 performs a separate execution on the executable content 11, the stub code 26 calls the separate execution target code block 37 and calculates by performing an operation on the separated execution target code block 37. Return the result.

 The separated execution target code block 35 includes a plurality of basic block groups 27 extracted from the code area 21 of the executable content 11 through profiling and analysis of the executable content 11. Preferably, the separate execution target code block 35 allows the entry of the control signal through the entry point of the separation execution target code block 35 and the movement of the control signal between the basic block 25, but the separation execution target. The basic block group 27 includes a plurality of basic blocks 25 associated with each other without entry of a control signal to the basic block 25 except for the start point of the code block 35.

On the contrary, when the basic block group 27 in which the control signal enters the basic block 25 except for the starting point is selected as the separate execution target code block 35, the corresponding separation execution code block 35 is extracted. The control signal may enter the middle of the inserted stub code 26, not at the beginning. In this case, the stub code 26 may not process the control signal, and thus execution of the executable content 11 may not be performed. It may be stopped or an error may occur.

The above-described separated execution target code block may be extracted 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 11 to be separated. The selection of the plurality of basic block groups 27 starts execution of the executable content 11 to be separated, collects basic information about the code area 21 during run-time, and uses the collected basic information. This is accomplished by performing a static analysis of the code region 21 through dynamic profiling that extends the scope of analysis. The basic information is at least one indirect address among a branch address, a jump address, a call address, and an indirect address of the RET. From the basic information, the basic information related to the published API of the executable content 11 is removed, and based on the basic information from which the basic information related to the published API is removed, the code region 21 of the executable content 11 is removed. By performing a static analysis of the analysis, the scope of analysis can be extended. By substituting indirect addresses from among the collected basic information on the control flow, more basic block groups 27 can be selected as compared to performing dynamic profiling or static analysis by extending the analysis range alone.

In addition, when a control signal entering the basic block group 27 is generated among the plurality of selected basic block groups 27, the basic block group 27 is divided and redefined based on the instruction address of the control signal. do. At this time, the basic block group 27 to be redefined is redefined as a first basic block group before and a second basic block group after 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 properties of a single input and a single output and an attribute which does not allow entry from outside to inside is finally obtained. define.

Subsequently, the separation execution target code block 35 is selected from the plurality of basic block groups 27, and the separation execution target code block 35 is separated from the code area 21, instead of the separation execution target code block 35. Insert the stub cord 26.

In this case, the separate execution target code block 35 may select a basic block group 27 on a critical path of the executable content 11 among the plurality of basic block groups 27. In addition, the separate execution target code block 35 may be selected from the plurality of basic block groups 27 in consideration of the number of calls, the size, and the execution time. For example, a basic block group 27 having a large number of calls, a small size, and a short execution time is selected as the separate execution target code block 35.

According to this, in the executable content 11, the basic block group 27 existing on the critical path, having a large number of calls, a small size, and a short execution time is separated into the target block of execution code 35 for security. By selecting and separating the execution target code block 35 from the executable content 11, the security performance related to copy protection of the executable content 11 can be improved.

In addition, by performing a static analysis using the basic information of the code area 21 collected through dynamic profiling to extract the basic block group 27, the code of the executable content 11 The extraction range of the basic block group 27 may be improved by extending the analysis range of the region 21.

In addition, by providing the flexibility to redefine the once defined basic block group 27, a single input and a single output that can be candidates for the separate execution target code block 35 It is possible to generate a basic block group 27 having an inadequate basic block group 27 with the entry of the control signal to the inside except for the entry point (entry point) is selected as a separate execution target code block 35 As a result, it is possible to suppress the occurrence of an error while separating and executing the separated execution target code block 35.

4 is a block diagram illustrating a separation execution based content composition module in a digital rights management system to which the present invention is applied. 5 is a diagram illustrating a stub code to be inserted into the executable content in the digital rights management system to which the present invention is applied.

In the DRM system illustrated in FIG. 1, the separation execution based content configuration module 31 to be described below includes a separation execution based content 37 and a separation execution target to be stored in the host terminal 50 and the storage device 50, respectively. The module for generating the code block 35.

1, 4, and 5, the separation execution based content composition module 31 includes a module control unit 311, a code analysis unit 313, a code operation unit 315, and a code conversion unit 317. And a code encryption unit 319.

The module controller 311 controls the overall process for generating the separated execution based content 37. That is, the separated execution target code block 35 is selected from the inputted executable content 11 to be separated, and the selected separated execution target code block 35 is separated from the executable content 11, and the separated execution target code block is executed. Converts the executable content 11 to enable separate execution of the 35, converts the separated executable execution code block 35 into a form that can be processed in the storage device 60, The code analyzing unit 313, the code manipulating unit 315, and the code converting unit extract the initial code block from the code area and encrypt the initial code block to decrypt and execute the encrypted initial code block when executing the executable content 11. 317 and the code encryption unit 319 is controlled.

The code analyzer 313 analyzes a code region of the executable content 11 and selects one or more separated execution target code blocks 35 from the code region. More specifically, the code analyzing unit 313 receives the content to be separated, the profile data for the content, and the code block selection rule received from the content providing terminal 10 to receive the profile data and the code block selection rule. Based on the determination, the code block 35 to be separated is executed in the code area of the content.

Specifically, the code analyzer converts the selection rule of the profile data and the separation target code block 35 into an internal data format. For example, the profile data and rules may be implemented in XML form, in which case the selection rule of the profile data and the separated execution code block is an XML parser that converts the XML data into an internal data format. Then, the profile data and code block selection rules are loaded, and one or more separate execution target code blocks 35 are selected in the code area of the executable content 11 based on the loaded profile data and code block selection rules.

In addition, the code analyzing unit 313 updates a code block selection rule, which becomes a reference when the separation target code block 35 is selected. The code block selection rule means to select a code block to be separated with the largest weight among the information of the profile data. As described above, the code block selection rule may be represented by a weight for each item of the profile data. However, since the code block selection rule is highly likely to change according to the type, size, etc. of the content, the rule for selecting the code block to be separated is continuously updated by receiving a verification result of the selected code to be separated. do. For example, if an issue such as execution speed occurs by performing a test on the selected separated execution target code block 35, the detailed weight of the selection rule of the separated execution target code block 35 is changed based on this.

The code manipulation unit 315 converts the executable content 11 to connect the separated execution target code block 35 selected by the code analysis unit 313 and the separated execution based content 37 in which the separated execution target code block is separated. do.

More specifically, the code operation unit 315 generates an auxiliary execution function unit for interworking with the separated separated execution target code block 35, and the separated execution target code block 35 jumps to the auxiliary execution function unit from the front. After the execution of the auxiliary execution function unit is completed, the stub code that jumps to the position to be executed next to the separation execution target code block 35 is generated and inserted into the position of the separation execution target code block 35.

Here, the auxiliary execution function calls the separate execution target code block 35 by packing the parameters passed from the stub code, that is, the information of the stack and the register, and when the call ends, the result value of the separate execution target code block 35. Restore the stack and register information.

For example, the separate executable code block 35 stored in the storage device 60 is implemented as Java bytecode based on the platform of the storage device 60, more specifically, a Java applet embedded with a Java applet and ARM instructions. In this case, the auxiliary execution function unit is implemented as a native launcher for executing the above-described Java applet. In addition, the auxiliary execution function is implemented as a DLL (Dynamic Link Library) file so that it can be loaded and executed only when necessary. This auxiliary execution function will be described in more detail later.

Referring to FIG. 5, (a) shows the executable content 11 before inserting the stub code, that is, the separated execution target code block 35, and (b) is inserted at the position of the separated execution target code block 35. Shows the stub code.

When comparing (a) and (b) of Fig. 5, the stub code jumps to a specific function of the auxiliary execution function unit (jmp NativeLauncher) from the front position of the separate execution target code block 35, and calls the function of the auxiliary execution function unit. After that, it is generated to jump to the endpoint to return a function value, and is inserted at the position of the separated execution code block 35. According to this, code conversion is possible without changing the caller code.

The code manipulation unit 315 inserts a native launcher function unit (Native Launcher DLL) into an import table of an idata section for the insertion of the stub code and for loading the auxiliary execution function unit. The insertion of the auxiliary execution function into the import table is for the auxiliary execution function to be loaded by the loader of the OS when the separate execution base content 37 is driven in the host terminal 50.

In this way, the interaction with the separated separate execution target code block 35 is possible without modifying the source code of the separated execution based content 37.

The code conversion unit 317 converts the separation execution target code block 35 separated from the separation execution base content 37 into an executable form in the storage device 60. In this case, the separation execution target code block 35 may be converted into instructions of a processor included in the storage device 60 in order to improve the separation execution speed. For example, when the storage device 60 is a Java-based smart card, the separate execution target code block 35 is converted to Java byte code, in particular, to Java byte code containing an ARM instruction. That is, when the host terminal 50 has an X86 series processor structure and the storage device 60 is an ARM structured processor, the code conversion unit 317 may execute the X86 instruction of the separate execution target code block 35. Convert Java bytecode and ARM instructions to embedded Java bytecode.

At this time, the code conversion unit 317 preferably converts the separation execution target code block 35 into a plurality of machine codes so that the separation execution of the executable content 11 can be applied to various processor environments. To this end, the code conversion unit 317 may be implemented using a compiler infrastructure, in particular, a low level virtual machine (LLVM). With LLVM, you can use a variety of proven open source solutions, code optimization independent of the target, i.e., the processor of the storage device 60, high code reusability, and a variety of source code I can convert it.

In detail, the code conversion unit 317 converts a separate execution target code block formed of a source, that is, a language based on the platform of the host terminal 50, into an intermediate level language (LLVM IR), and then the intermediate level language. Optimizes the separate execution target code block 35 converted into a second, and finally separates the optimized execution target code block 35 of the intermediate language into a plurality of machine codes based on the processor of the storage device 140, for example, Java bytecode, converted to ARM instructions.

The code encryptor 319 encrypts the initial code block selected under the control of the module controller 311 with a specific key, and decrypts and executes the initial code block through the specific key when executing the executable content 11. The executable content 11 is converted.

Specifically, the code encryptor 319 encrypts the selected initial code block with a designated key, and then inserts the encrypted initial code block into the security area additionally generated in the executable content 11, and at the position of the initial code block. A start stub code is inserted which causes the secondary execution function to be loaded to obtain the key, decrypt and execute the encrypted initial code block.

More specifically, the code encryptor 319 generates a startup stub code that calls a function of an auxiliary execution function to decrypt and execute the encrypted initial code block instead of the initial code block to be encrypted and moved, thereby initial block. Insert it in the position of. The code encryptor 319 creates a new secure section in the executable content 11, encrypts the selected initial block code with a specified key, and loads the encrypted initial code block in the generated secure area. do.

In this case, since the key used for encryption is necessary for decryption at the time of execution of the executable content 11, the key used for encryption may be managed in the form of a Contents Encryption Key (CEK) of the rights object 43 and stored in the storage device 60. .

The initial code block encrypted through the code encryption unit 319 is then decrypted by the auxiliary execution function unit as in the case of the separate execution target code block 35 and driven in an on-memory state. (Running) According to this, the first-level security technology is applied to the executable content 11 at the time of initial driving, and the two-level security technology is applied through separate execution, thereby more illegally using and copying the executable content 11. You can block.

FIG. 6 is a diagram illustrating a configuration of an auxiliary execution function unit in a separation execution based content of a digital rights management system to which the present invention is applied and a separation execution process through the same.

Referring to FIG. 6, a separate execution target digital content 37 stored in the host terminal 50 and a separate execution target stored in the storage device 60 and converted into an executable form in the storage device 60 according to the present invention. The code blocks 35 interoperate with each other via the auxiliary execution function unit 300. In particular, the auxiliary execution function unit 300 allows the host terminal 50 implemented as a heterogeneous processor and the storage device 60 to implement separate execution.

To this end, the auxiliary execution function unit 300 may include an interface function unit 310, a packing function unit 320, an unpacking function unit 330, a memory mapping function unit 340, and the like. In addition, the OS API mapping function 350 may be included, and in addition, the code decoding function 360 may be further included.

The interface function unit 310 provides a communication channel with the separation execution target code block 35 to exchange data with the separation execution target code block 35 stored in the storage device 60. For example, the interface function unit 310 may provide a communication channel with the separate execution target code block 35 through an application protocol data unit (APDU) defined in ISO-7816. The interface function unit 310 may provide a network bearer transparent interface so that the other function unit of the auxiliary execution function unit 300 is not changed even when another type of interface such as TCP / IP Over USB is applied in the future. . The interface function 310 has a function of the same type as general I / O functions.

The packing function unit 320 receives the stack and register information from the stub code 234 and packs it, and transmits the packing function unit 320 to the separate execution target code block 35 through the interface function unit 310. Here, the stack information is a collection of stack values used as parameters starting from the stack position designated by the SP register, and the register information is transmitted when the separate execution target code block 35 is called in the stub code 234. Register information.

The unpacking function unit 330 unpacks the packed data transferred from the separate execution target code block 35 through the interface function unit 310 and returns the packed data to the stub code 234. The unpacking function unit 330 simply sets a return value to a value of a corresponding register if the return value of the separated execution target code block 35 is a Primitive Data Type, and if the return value is a memory address, Change the corresponding values according to the return value.

The memory mapping function unit 340 records the data transmitted from the separate execution target code block 35 through the interface function unit 310 in the memory of the host terminal 50, or the data in the memory of the host terminal 50. And dispatch to the separate execution target code block 35. The separate execution target code block 35 of the storage device 60 may be executed by referring to the memory of the host terminal 50 through the memory mapping function 340.

The OS API mapping function unit 350 receives the API name and parameter values from the separate execution target code block 35 through the interface function unit 310, calls the OS API of the host terminal 50, and as a result, Received is returned to the code execution target block 35 to be separated. As a result, the separated execution target code block 35 stored in the storage device 60 may call the OS API of the host terminal 50 to receive the result.

The code decryption function 360 obtains a specific key from the storage device 60, decrypts the encrypted initial code block 271 loaded in the security area 270, and executes the decrypted initial code block. .

7 is an operation flowchart of a code decoding function unit in a digital rights management system to which the present invention is applied. Referring to FIG. 7, the code decryption function unit 360 receives an encrypted initial code block and a key CEK used for encryption, and decrypts an initial code block with a key (S361). The runtime code executioner directly executes the decoded initial code block on the memory (S362). More specifically, the runtime code executor maps an instruction pointer to the decoded initial code block and jumps to execute the decoded initial code block. According to this, only when the initial code block is executed, the decrypted initial code block exists in the memory, and after execution, it is immediately destroyed, thereby increasing the security effect.

6 and 7, the separation execution operation using the auxiliary execution function unit 300 will be described as follows.

First, when the separated execution based content 37 starts to be driven, the auxiliary execution function unit 300 is loaded by the start stub code 233 located at the beginning of the code region 230 (①), and the code decoding function unit is executed. 360 is called to retrieve an encrypted initial code block 271 loaded in the secure area 270 (2), obtain a key (CEK) necessary for decryption (3), and initialize the initial code block 271. Decode and execute (④). Subsequently, the next program code of the code area is executed in order, and when the stub code 234 is entered, the packing function 320 is called by the stub code 234, and the called packing function 320 is stubbed. The stack and register information delivered from the code 234 is packed and transferred to the separate execution target code block 35 of the storage device 60 through the interface function unit 310 (⑤). In this case, the separate execution target code block 35 is executed. In this case, the separate execution target code block 35 is executed by the memory of the host terminal 50 through the memory mapping function 340 and the OS API mapping function 350. You can access the OS API (⑥). When the execution of the separate execution target code block 35 is completed, the result value is transmitted to the auxiliary execution function unit 300 through the interface function unit 330, and the unpacking function unit 330 freezes the result value again. It is packed and returned to the stub code 234 (⑦).

According to this, the separation execution based content 37 and the separation execution target code block 35 may operate normally through interworking between the host terminal 50 and the storage device 60.

8 is a block diagram showing the structure of an auxiliary execution module in a storage device of a digital rights management system to which the present invention is applied. 6 and 8, the separated execution target code block 35 stored in the storage device 60 to which the present invention is applied and the separated execution based content 37 stored in the host terminal 50 may include an auxiliary execution function unit. It is interlocked through the 300 and the auxiliary execution module 610.

The auxiliary execution module 610 includes an execution function unit 611, a task management function unit 613, a loading function unit 615, a device memory mapping function unit 617, a device OS API mapping function unit 619, and a device memory. The management function unit 621 and the ROM management function unit 623 are included.

The loading function 615 loads the separate execution target code block 35 to fix all unfixed references (hereinafter referred to as linking) and load the references to an arbitrary area in the memory. Refer to reference information to link unresolved reference.

The execution function unit 611 communicates with the host terminal 50, parses the data received from the host terminal 40, executes the contents, and transmits the contents to the host terminal 50. In this case, the protocol may be processed by standardizing between the auxiliary execution function unit 300 and the auxiliary execution module 610.

Specifically, the separation execution target code block 35 included in the RO is received, the separation execution target code block 35 is loaded through the loading function unit 615, and the separation execution is performed by manipulating an IP (interrupt priority) resist. The entry point of the target code block 35 is forcibly called and executed. In addition, when it is necessary to wait for a response from the host terminal 50 due to a call of the device memory mapping function 619 or the device OS API mapping function 621, an instruction pointer and register values that are currently being executed are contextually displayed. After temporary storage in the form of (context), when a response arrives from the host terminal 50, the process is executed again from the corresponding position.

The device memory mapping function 617 packs the instructions loaded by the loading function 615 to the auxiliary execution function 300 of the host terminal 50 when the instructions refer to the memory of the host terminal 50. When the response is received from the auxiliary execution function unit 300, the packet is unpacked and transferred to the execution function unit 611.

Here, the loading function 615 links the code having the memory reference of the host terminal 50 to call the device memory mapping function 617 during the initial loading process, and thus the host in the loaded code. When the memory reference of the terminal 50 is made, the device memory mapping function unit 617 is called.

The device OS API mapping function 619 packs an instruction loaded by the loading function 615 when the OS API of the host terminal 50 calls the OS execution function of the host terminal 50. 300, and when receiving a response from the auxiliary execution function unit 300, unpacks and transmits the response to the execution function unit 611.

Here, the loading function unit 615 links the code that calls the OS API of the host terminal 50 to call the device OS API mapping function unit 619 during the initial loading process, and thus the loaded code When calling the OS API of the host terminal 50 in the device OS API mapping function unit 619 is called.

The task management function unit 613 may include a plurality of separated execution based content 37 executed in the host terminal 50, and when the plurality of separated execution based content 37 are executed at the same time, a task of the storage device 60 may be executed. Create a task to match 1: 1 with. In addition, it is connected to other components of the execution function unit 611 and the auxiliary execution module 610.

When the auxiliary execution module 610 is executed, the device memory management function 621 receives the start address of the heap allocated to the auxiliary execution module 610 and the available memory size from the storage device 60 OS, and performs separate execution. Memory for execution of the target code block 35 is allocated, released, data inserted, deleted, and the like. In this case, the allocated memory is fixed and preferably allocated such that only the auxiliary execution module 610 may be used. In addition, the memory management function unit 621 requests the job management function unit 613 when the memory size referred to by the separated execution target code block 35 is larger than the available memory size of the storage device 60, and the host terminal 50. ) Memory is allocated.

When the number of writes of the NOR or NAND memory in the ROM management function unit 623 storage device 60 is limited, the original equipment manufacturer (OEM) may minimize the access when referring to the NOR or NAND memory due to the small amount of RAM. Provides a file system that can implement cash by allocating a certain area of ROM. Such a file system is provided with APIs such as open, read, and write files as in the existing file system.

9 is a block diagram showing a host terminal for UMS (USB Mass Storage) based communication according to an embodiment of the present invention. Referring to FIG. 9, the host terminal 50 of the present embodiment includes an API wrapper 520, an APDU agent 530, and an interface unit 540.

The interface unit 540 has an interface for performing data transmission and reception with the storage device 60 connected by wire or wirelessly.

The API wrapper 520 provides an application protocol interface (API) for communicating an APDU (Application Protocol Data Unit) between the host terminal 50 and the storage device 60, and may be used by calling an API from the host program 510. To provide an interface.

Here, the host program 510 refers to various programs including a document work program, a multimedia playback program, and the like, which may be executed in the host terminal 50. In this case, the host program 510 is not limited to an application program.

In detail, the API wrapper 520 operates on a file, such as creating a file, reading a file, or writing a file to the storage device 60 while executing the host program 510, in the host program 510, or by receiving a user input. Upon receiving an API call provided by the API wrapper 520 to perform the API, the API wrapper 520 provides the called API and performs an operation on a file in the storage device 60 from the host program 510. Data to be received from the host program 510 is delivered to the APDU agent 530.

Since the API wrapper 520 is present in the host terminal 50 such as the APDU agent 530, the API wrapper 520 may transmit and receive data through IPC (inter process communication) communication, and at this time, may communicate using a UDP socket (User Datagram Protocol Socket). have. When communicating using a UDP socket, the APDU agent 530 functions as a UDP server, and the API wrapper 520 functions as a UDP client.

At this time, when performing communication between the UDP wrapper 520 and the APDU agent 530 by using a UDP socket, when capturing packets transmitted and received using a malicious tool, data may be exposed, thereby transmitting and receiving mutual data. Encrypted data can be sent, decrypted after receiving data, and verified. An algorithm for encrypting and decrypting data may be decrypted by performing an XOR operation with the same key value, but is not limited thereto.

In addition, when the API wrapper 520 communicates with the APDU agent 530, the API wrapper 520 preferably maintains the block state until there is a change in the state of the socket, such as transmitting or receiving data after creating the socket. For this purpose, you can use asynchronous socket events.

The APDU agent 530 communicates with the storage device 60 through the interface unit 540 using the data received from the API wrapper 520 to perform a file operation, and returns the processed data to the API wrapper 520. do.

In this case, the APDU agent 530 may also communicate with the API wrapper 520 using the UDP socket, and may use a socket event that is an incompatible method.

Since the APDU agent 530 communicates between the storage devices 60 at a ratio of 1: 1, the APDU agent 530 must first process data received from the API wrapper 520. For this purpose, the APDU agent 530 has a structure of FIFO (First In First Out). Using a queue, the data first received from the API wrapper 520 is first stored.

In this case, the APDU agent 530 may use a circular queue to effectively manage the queue, and the data received and inserted into the queue is not deleted until processing of the data is completed.

In detail, the APDU agent 530 stores the data received from the API wrapper 520 in the queue in order, reads the data stored in the queue, and creates a thread using the read data to store the storage device 60. A) and executes an operation on a file in the storage device 60 and dequeues data processed after the file operation in the storage device 60 is completed, that is, data received from the API wrapper 520 and inserted into a queue. Return to

In this case, the APDU agent 530 preferably synchronizes a plurality of data received from the API wrapper 520, that is, a plurality of requests for file operations received from the API wrapper 520. The mutex algorithm can be used to insert or delete inserted data.

The APDU agent 530 executes the created thread to communicate with the storage device 60 through the interface unit 540 and creates, deletes, and reads files in the storage device 60. File operations such as file write, file seek, and file truncation. The storage device 60 is displayed as a drive name in the host terminal 50, and the files in the drive may be displayed in a hidden file form to prevent a user from accidentally or arbitrarily deleting a file. In addition, when creating a file in the storage device 60, the file can be generated in the form of the above-described hidden file, and if the created hidden file is deleted, regenerates the hidden file created in the storage device 60 and You can then perform file operations, such as reading or writing files.

FIG. 10 is a diagram illustrating a UMS (USB Mass Storage) based communication method according to an embodiment of the present invention. For convenience of description, the configuration shown in FIGS. 1 to 8 described above will be described with reference to the corresponding reference numerals. 1 and 10, when the API wrapper receives an API call for performing an operation on a file in the storage device 60 in the host program 510 or receives a user input, the API wrapper receives an API wrapper. 520 provides the called API, and receives data for performing an operation on a file in the storage device 60 from the host program 510 (S71).

In step S71, the API wrapper 520 that receives data for performing an operation on a file in the storage device 60 transfers the received data to the APDU agent 530 (S73), and the APDU agent 530. Inserts the data received from the API wrapper 520 into the queue (S75).

At this time, the API wrapper 520 may encrypt and transmit the data, and the APDU agent 530 decrypts the encrypted data when it is received. Here, the API wrapper 520 and the APDU agent 530 may perform encryption and decryption through an XOR operation.

Subsequently, the APDU agent 530 reads the data inserted into the queue and generates a thread for performing an operation on a file in the storage device 60 using the read data (S77).

At this time, the APDU agent 530 uses a mutex algorithm when inserting data into the FIFO queue or deleting the inserted data to synchronize a plurality of requests for file operations received from the API wrapper 520. Can be.

The APDU agent 530 that created the thread in step S77 executes the thread to communicate with the storage device 60, and performs an operation on a file in the storage device 60 (S79).

At this time, when the file is created in the storage device 60, the file may be generated in the form of a hidden file. If the generated hidden file is deleted, the file is regenerated and read from the file created in the storage device 60. You can then perform file operations, such as writing and writing.

Subsequently, the APDU agent 530 extracts the processed data, that is, data received from the API wrapper 520 and inserted into the queue after the file operation is completed, and returns it to the API wrapper 520 (S81).

9 to 10 may include a separate execution target code block 35 separated from the executable content 11, and the host program may separate the execution target code block from the executable content 11. It may be separate execution based content 37 replacing 35 with stub code 26. The separation execution target code block 35 may be called while executing the separation execution based content 37 on the host terminal 50 to perform the separation execution. Detailed description thereof has been described above with reference to FIGS. 1 to 8, and thus description thereof will be omitted.

In addition, the UMS (USB Mass Storage) based communication method according to the present embodiment may be implemented in the form of program instructions that may be executed by various computer means, and may be recorded on a computer-readable recording medium. The recording medium may include program instructions, data files, data structures, etc. alone or in combination. Program instructions recorded on the recording medium may be those specially designed and constructed for the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts. For example, the recording medium may be magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, or magnetic-optical media such as floptical disks. magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

As described above and described with reference to a preferred embodiment for illustrating the technical idea of the present invention, the present invention is not limited to the configuration and operation as shown and described as such, without departing from the scope of the technical idea It will be understood by those skilled in the art that many changes and modifications to the present invention are possible. And all such modifications and changes as fall within the scope of the present invention are therefore to be regarded as being within the scope of the present invention.

According to the present invention does not require a separate device to perform the UMS-based communication, thereby minimizing the additional cost. In particular, considering that the demand for storage devices increases because modern people want to be able to access contents regardless of time and place, the UMS-based communication scheme of the present invention may not be useful.

10: content providing terminal 11: executable content
21: code area 23: data area
25: basic block 26: stub cord
27: basic block group 30: content registration server
31: Separation run based content configuration module 33: Profiling and analysis tool
35: Detach Execution Target Code Block 37: Detach Execution Based Content
40: DRM server 41: encrypted content
43: rights object 44: history of rights object issuance
45: server transmission and reception unit 47: server storage unit
49: server control unit 50: host terminal
51: terminal communication unit 55: output unit
57: terminal controller 60: storage device
61: communication unit 63: storage unit
65: Program 67: Communication bus
69: control unit 70: network
210: DOS header 220: PE header
233: start stub code 230: code area
234: stub code 240: data area
250: Import region 251: Startup DLL
260: export area 270: security area
271: Initial encrypted code block 300: Secondary execution functionality
310: interfacing function unit 311: module control unit
313: code analysis unit 315: code operation unit
317: code conversion unit 319: code encryption unit
320: packing function unit 330: unpacking function unit
340: memory mapping function 350: OS API mapping function
360: code decoding function 510: host program
520: API wrapper 530: APDU agent
540: interface unit 610: auxiliary execution module
611: execution function unit 613: job management function unit
615: loading function 617: device memory mapping function
619: Device OS API mapping function 621: Device memory management function
623: ROM management function

Claims (26)

An interface unit for communicating with a storage device;
An application protocol interface (API) for exchanging an application protocol data unit (APDU) message with the storage device; and when a host program calls the API, the host receives data for performing an operation on a file in the storage device. An API wrapper for receiving and passing from a program;
When receiving data from the API wrapper, a thread is created using the received data to perform an operation on a file in the storage device through the interface, and when the operation is completed, the received data is read. An APDU agent that returns to an API wrapper, the data processing using a FIFO queue;
Host terminal for UMS (USB Mass Storage) based communication comprising a. The method of claim 1,
The API wrapper and the APDU agent is a host terminal for UMS-based communication, characterized in that for transmitting and receiving the data using a UDP socket (User Datagram Protocol Socket). The method of claim 2,
The UDP socket is a host terminal for UMS-based communication, characterized in that the asynchronous method. The method of claim 1, wherein the API wrapper,
Host terminal for UMS-based communication, characterized in that for transmitting the data encrypted. The method of claim 4, wherein the API wrapper,
Host terminal for UMS-based communication, characterized in that for encrypting the data using an XOR operation. The method of claim 1,
The FIFO queue is a host terminal for UMS-based communication, characterized in that the circular queue. The method of claim 1, wherein the APDU agent,
When inserting or deleting the data in the FIFO queue received from the API wrapper, a host terminal for UMS-based communication, characterized in that using a mutex (Mutex) algorithm. The method of claim 1, wherein the APDU agent,
Host terminal for UMS-based communication, characterized in that for generating a file in the storage device to create a hidden file form. The method of claim 8, wherein the APDU agent,
And when the file generated in the storage device is deleted, re-generate the generated file and perform a read or write operation on the regenerated file. The method of claim 1,
And a file in the storage device includes a separate execution target code block. The method of claim 1,
The host program is a host terminal for UMS-based communication, characterized in that the separated execution based content. The method of claim 11,
And the data includes packed stack information and register information. A receiving step of receiving, by the host terminal, data for performing an operation on a file in a storage device from the host program when the host program calls an application protocol interface (API) for exchanging an application protocol data unit (APDU) message;
An insertion step of inserting, by the host terminal, the received data into a FIFO queue;
Performing a calculation on a file in the storage device by the host terminal reading data inserted into the FIFO queue;
A return step of extracting the inserted data and returning the inserted data to the host program when the host terminal completes an operation on the file in the storage device;
UMS (USB Mass Storage) based communication method for performing the. The method of claim 13,
UMS-based communication method characterized in that the data is encrypted. The method of claim 14,
The data is UMS-based communication method characterized in that the encrypted using an XOR operation. The method of claim 13,
The FIFO queue is a circular queue, characterized in that the UMS-based communication method. The method of claim 13,
When inserting or deleting the data in the FIFO queue, a mutex (Mutex) algorithm, characterized in that for using a communication method. The method of claim 13, wherein the operation performing step,
UMS-based communication method characterized in that when the host terminal performs the operation to create a file in the storage device to form a hidden file. The method of claim 18, wherein the operation performing step,
If the file generated in the storage device is deleted by the host terminal, regenerate the generated file and perform a read or write operation on the regenerated file. The method of claim 13,
The file in the storage device comprises a UMS-based communication method characterized in that it comprises a separate execution target code block. The method of claim 13,
The host program is a UMS based communication method, characterized in that the separated execution based content. The method of claim 21,
And the data includes packed stack information and register information. The method of claim 20, wherein the separated execution target code block,
UMS-based communication method, characterized in that the basic block group on the critical path of the executable content of the plurality of basic block group consisting of a plurality of basic blocks existing in the code area of the executable content. The method of claim 23, wherein the basic block group,
The entry of a control signal through an entry point and the movement of the control signal between the plurality of basic blocks are permitted, and the plurality of basics associated with each other without entry of a control signal into the plurality of basic blocks except for the starting point. UMS-based communication method characterized in that the collection of blocks. The method of claim 24, wherein the basic block,
UMS-based communication method characterized in that the code block having a property of a single input (single input) and a single output (single output), and a property that does not allow the entry of the control signal from the outside to the inside. A computer-readable recording medium having recorded thereon a program for executing the method according to any one of claims 13 to 25.

Images