JP2009059008A - File management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To operate each encrypted file without altering an application program. <P>SOLUTION: The application program 32 is provided with an API calling code 321 for operating a file. A monitoring layer 34 hooks AP calling from the application program 32, and transmits a decryption instruction for decrypting an encrypted file 14 to a decryption control module 36. The decryption control module 36 requests the decryption processing to an OS kernel 37 based on the decryption instruction transmitted from a monitoring layer 34. The OS kernel 37 decrypts the file 14 based on the request from the decryption control module 36, and creates the decrypted file, and returns the decrypted file to the decryption control module 36. Furthermore, the decryption control module 36 returns the decrypted file returned from the OS kernel 37 to the application program 32. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a technique for safely operating an encrypted file by a computer.

  In order to share information, there is a demand that only related parties want to safely browse data such as documents, images, and moving images.

  In order to protect such information, there is a corresponding method in which data is encrypted and only a person who has the right acquires and browses the decryption key. For this purpose, conventionally, processing for decrypting encrypted data has been incorporated into an application program (hereinafter also referred to as “application”). In this case, when the application is started, the data is decrypted by the decryption processing incorporated therein, and processing by the application (for example, opening or printing a file) becomes possible.

  On the other hand, depending on the application, there are cases where modification is difficult. In this case, it is necessary for the user himself to perform decryption processing of the encrypted file using another application. This method also allows the decrypted file to be used in the original application. However, in this case, there is a problem that the decrypted data may be leaked or tampered with. Further, such processing has a problem that it takes much time and effort for the user.

  There is also a solution for encrypting the entire HDD (Hard Disk Drive) for storing data. In this case, when the user uses the data, all data files recorded on the HDD are decrypted. In other words, in this state, all files can be operated. Then, in this technique, there is a possibility that a decrypted data file flows out to the outside due to the use of file exchange software or the like.

  The present invention has been made in view of the above situation. The present invention provides a technique capable of operating an encrypted file in units of files without modifying an application program.

  In order to solve the above-described problems, the present invention has a configuration described in any of the following items.

(Item 1)
A file management system comprising the following (a) to (d):
(A) application program,
(B) the monitoring layer,
(C) a decoding control module;
(D) OS kernel,
here,
The application program includes an API call code for operating a file,
The monitoring layer hooks an API call from the application program, and sends a decryption instruction for decrypting the file to the decryption control module.
The decryption control module requests the OS kernel to perform decryption processing based on the decryption instruction sent from the monitoring layer,
The OS kernel decrypts the file based on a request from the decryption control module, generates a decrypted file, and returns the decrypted file to the decryption control module.
Further, the decryption control module is configured to return the decrypted file returned from the OS kernel to the application program.

  According to the present invention, an API call code for file operation can be hooked, the file can be decrypted, and returned to the application program. In the present invention, since only the API call code is operated, it is not necessary to modify the application program body. In addition, since the decryption is performed for each file that needs to be operated, the risk of information leakage is lower than when the entire HDD is decrypted. In the present invention, the file to be decrypted includes the case of a part of data in the file. That is, decoding in units of files does not necessarily mean decoding of the entire file, but includes decoding of only necessary data in the file.

(Item 2)
further,
(E) a supervisory control module;
The file management system according to item 1, comprising:
The monitoring control module is configured to be able to hook an API call from the application program by rewriting the API call code included in the application program.

  By rewriting the API call code in this way, the hook of the API call code can be easily and reliably implemented.

(Item 3)
further,
(F) The file management system according to item 1 or 2, comprising a secondary storage device,
The secondary storage device stores the encrypted file.

(Item 4)
further,
(G) The file management system according to any one of items 1 to 3, comprising a key transmission server,
The file management system according to any one of Items 1 to 3, wherein the decryption control module is configured to perform the decryption process using a key received from the key transmission server.

(Item 5)
The file management system according to any one of items 1 to 4, wherein the API call code is for opening a file.

(Item 6)
6. The file management system according to item 5, wherein the API call code further includes one for printing a file.

(Item 7)
further,
(H) The file management system according to any of items 1 to 6, comprising a cryptographic processing module,
The monitoring layer is configured to send an encryption command to the cryptographic processing module based on the hooked API call;
The cryptographic processing module is configured to perform processing of encrypting data necessary for the operation of the application program and writing it to a temporary file after receiving the encryption command.

(Item 8)
A file management method using a file management system comprising the following (a) to (d):
(A) application program,
(B) the monitoring layer,
(C) a decoding control module;
(D) OS kernel,
here,
The application program includes API call code for manipulating files;
This method comprises the following steps:
The monitoring layer hooks an API call from the application program and sends a decryption instruction for decrypting the file to the decryption control module;
The decryption control module requests the OS kernel to perform a decryption process based on the decryption instruction sent from the monitoring layer;
The OS kernel decrypts the file based on a request from the decryption control module to generate a decrypted file, and returns the decrypted file to the decryption control module;
Furthermore, the decryption control module returns the decrypted file returned from the OS kernel to the application program.

(Item 9)
A computer program for causing a computer to execute the method according to item 8.

  According to the present invention, the present invention makes it possible to operate an encrypted file on a file basis without modifying an application program.

  Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.

(System configuration example)
First, a file management system according to an embodiment of the present invention will be described with reference to FIG. This system includes a content provider's internal environment 1, a public server environment 2, a user computer 3, and the Internet 4 as functional elements.

(Internal environment)
The internal environment 1 includes a content encryption system 11 and a content storage 12.

  The content encryption system 11 encrypts the content file 13. In addition, the content encryption system 11 generates a content ID and a decryption key and sends them to the public server environment 2. Here, as the content file 13, various types such as a document, an image, a moving image, and an execution file can be used. That is, the format of the target file in the system of this embodiment is not limited.

  Further, the content encryption system 11 stores the encrypted content file 14 in the storage 12.

  The content storage 12 can deliver the encrypted content file 14 to the public server environment 2.

(Public server environment)
The public server environment 2 includes a content distribution server 21, a key transmission server 22, and a key recording storage 23.

  The content distribution server 21 receives the encrypted file 14 from the content storage 12 and sends it to the user computer 3 via the Internet 4.

  The key transmission server 22 can receive the content ID and the decryption key from the content encryption system 11 and send them to the user computer 3.

  The key recording storage 23 stores the content ID received by the key transmission server 22 in association with the decryption key.

(User computer)
The user computer 3 includes a content downloader 31, an application program (application) 32, a monitoring control module 33, a monitoring layer 34, a standard API 35, a decryption control / encryption processing module 36, an OS kernel 37, and a device driver 38. And a secondary storage device 39.

  The content downloader 31 receives the encrypted content file 14 from the content distribution server 21 via the Internet 4. Such a function can be provided by appropriate computer software such as a browser. However, the means by which the user computer 3 receives the content file 14 is not limited to via the Internet, but may be via a medium such as a CD or DVD, for example. In this case, instead of the content downloader 31, a recording medium reading device can be used.

  The application program 32 is computer software for executing functions such as file operations and printing. In this embodiment, various viewer applications are assumed as the application program 32, but the application program 32 is not limited thereto. Examples of the application program 32 include an Internet explorer, a Flash player, a PDF viewer, and MS-Office. These are trademarks or registered trademarks. The application program 32 includes an API call code 321 (see FIG. 2) for operating a file.

  The monitoring control module 33 is a computer program having a function of realizing an API hook by rewriting an API call code in the application program 32.

Furthermore, the supervisory control module 33 is from the user side.
・ Decryption permission application ・ Encryption exportable folder ・ Print restriction by application ・ Screen capture restriction data can be received.

  Detailed operation of the monitoring control module 33 will be described later.

  The monitoring layer 34 hooks an API call from the application program 32 and sends a decryption command for decrypting the file to the decryption control module 36. In the present embodiment, the decoding of data in a file is also included in the concept of file decoding. Of course, the entire file can also be decrypted. It is also possible to decrypt a plurality of files as a result of an API call from the application program 32. Detailed operation of the monitoring layer 34 will be described later.

  The standard API 35 is a standard API group provided along with the OS (for example, Windows (registered trademark)). Since such an API is already well known, detailed description is omitted.

  The decryption control / encryption processing module 36 is a functional block in which a decryption control module and an encryption control module are combined. As an actual program code, both modules may be an integrated file or a separate file. In short, any configuration that can exhibit both functions is acceptable.

  The decryption control / encryption processing module 36 requests the OS kernel 37 to perform decryption processing based on the decryption instruction sent from the monitoring layer 34 as a decryption control function. Further, the decryption control / encryption processing module 36 is configured to return the decrypted file returned from the OS kernel 37 to the application program 32.

  Further, as a function of encryption processing, the decryption control / encryption processing module 36 performs a process of encrypting data necessary for the operation of the application program and writing it to a temporary file after receiving an encryption command from the monitoring layer 34. It is configured to do.

  Detailed operation of the decryption control / encryption processing module 36 will also be described later.

  Based on the request from the decryption control module 36, the OS kernel 37 sequentially decrypts necessary data from the file and returns the result to the decryption control module 36.

(File management method according to this embodiment)
Next, an example of a file management method using the above-described system will be described with reference to FIGS. The method described below can be executed by a computer program for operating a computer.

(Step 0 in FIG. 2)
First, by user operation,
-Target decryption permission application (specifically, its binary hash value),
・ Encryption exportable folder,
Information on whether the restriction on printing and capture is valid or invalid is registered in the control monitoring module 33 as a list 331 of the list. This registration is performed before the operation of the application.

  Here, the “target decryption permitted application” is an application for which decryption processing is permitted. This information is recorded using the binary hash value of the application. As the application information, for example, the name of the application and the binary path can be used. However, since these are generally environment dependent, they are not used in this embodiment. In other words, environment dependency can be reduced by specifying an application by its binary hash value. . Here, the binary hash value is a hash value generated from an application file (execution file) using an appropriate hash function.

  The “encrypted / writable folder” is information on a folder used in an encrypted writing process to be described later. In this embodiment, the folder is in the secondary storage device 39, but may be a folder in another appropriate storage device.

  “Valid / invalid restriction on printing and capture” is information on whether printing by the application or screen capture by the system is permitted. In the following example, it is assumed that the restriction on capture is effective. If the restriction is invalid, no restriction is imposed on the capture.

(Step 1 in FIG. 2)
The monitoring control module 33 activates the decryption permission application 32 corresponding to the file to be opened. Specifically, for example, a file to be opened (encrypted file) is associated with a decryption permission application, and when the file is double-clicked, the decryption permission application 32 is activated. Such association can be easily realized by using a service in the OS.

  Furthermore, the monitoring control module 33 checks whether or not the decryption permission application 32 has been tampered with based on the hash value when the decryption permission application 32 is activated. At the same time, the decryption permission application 32 registered in the list 331 can be specified by using the hash value. Only when there is no problem as a result of the check, the decryption permission application 32 is activated. Also, applications that are not registered in the list 331 or applications that do not have a hash value are not activated.

  In addition, after starting the application 32, the monitoring control module 33 monitors an event of the entire desktop, and returns an error when a screen capture event occurs.

  Further, the monitoring control module 33 checks the application code on the memory after the application 32 is activated. Specifically, when the activated application 32 is a decryption processing application recorded in the list 331, the monitoring control module 33 displays the file operation API call code and the print operation API call code in the application as a monitoring layer. It is rewritten to call 34 code. Here, when the activated application is not a decryption processing application, such API rewriting is not performed. For this reason, according to the present embodiment, an application other than the decryption processing application cannot call the monitoring layer 34. As a result, the decryption of the encrypted file by such an application can be prevented, and there is an advantage that unauthorized access to the encrypted file can be prevented.

(Step 2 in FIG. 2)
Next, the application 32 makes an API call. Here, when the API call code is a file operation or a print operation, since the code is rewritten in the above-described step 1, the monitoring layer 34 is actually called. In this example, the file operation API is an API for opening a file.

  The monitoring layer 34 reads the rewritten code to check whether the request from the application 32 is a print operation or a file operation.

  In the case of a printing operation, if it is a call from the application 32 that is permitted to print, the standard printing API is called as it is. As a result, the file can be printed. Here, as a premise for printing, it is assumed that a file has already been opened by a file operation described later. On the other hand, in the case of a call from the application 32 in which printing is not permitted, printing can be prohibited by returning an error to the application 32.

(Step 3 in FIG. 2)
In the case of a file operation API, the monitoring layer 34 checks the API call parameters before being rewritten, and determines whether or not decryption processing or encrypted writing is actually required (encrypted writing will be described later). . For example, in the case of an API that opens a file, the file access method is specified in the API parameter. There are the following types of access method designations.
・ Read only ・ Write only ・ Read / write ・ No read / write (Used to get file attributes)

  When the parameter is “no read / write”, encryption related processing (including decryption) is not performed, and the monitoring layer 34 calls the standard API. When “read only” is designated, a process for decoding is performed.

  The parameter is “write only”, and the process for encrypted writing described later is performed. When the parameter specifies “read / write”, processing for decryption and encrypted writing is performed.

  When decryption processing or encryption writing is necessary based on the parameters, the monitoring layer 34 calls the decryption control / encryption processing module 36. That is, the monitoring layer 34 sends to the decryption control / encryption processing module 36 a decryption command for decrypting data necessary for processing from the encrypted file.

(Steps 4 to 9 in FIG. 2)
Next, the decryption control / encryption processing module 36 calls the OS kernel 37 based on the decryption instruction from the monitoring layer 34. The OS kernel 37 acquires the encrypted content 14 (decryption target file) from the secondary storage device 39 via the device driver 38. Further, the decryption control / encryption processing module 36 acquires the content ID embedded in the encrypted content 14.

  Here, the decryption control / encryption processing module 36 communicates only with the “monitoring layer 34 called from the application activated by the monitoring control module 33”. The monitoring layer 34 and the monitoring control module 33 are connected using an individual communication path (pipe) when the application is activated, and only perform communication with each other using this communication path. Since the monitoring layer 34 can be implemented as a DLL, an application that illegally incorporates the monitoring layer 34 can also be expected. However, even if a monitoring layer (DLL) is incorporated in another application that is not started from the monitoring control module 33 (that is, not a decryption permission application), the monitoring layer is not connected to the decryption control / encryption processing module 36 for the above reason. Communication is not possible. For this reason, according to the present embodiment, the monitoring layer 34 is not illegally used.

  Next, the decryption control / encryption processing module 36 acquires the decryption key corresponding to the acquired content ID by matching the decryption key table 231 sent from the key transmission server 22. In this embodiment, the decryption / encryption module 36 can obtain a decryption key from the key transmission server 22 using a secure procedure. It is also possible to obtain the decryption key by means other than the Internet (for example, via a recording medium).

(Step 11 in FIG. 2)
The decryption control / encryption processing module 36 decrypts the data to be decrypted and the decryption key by calling the decryption function of the OS kernel 37. That is, the OS kernel 37 sequentially decodes data necessary for processing from the file 14 based on a request from the decryption control module 36 (so-called “on-the-fly”) to generate decrypted data, Further, the decoded data is returned to the decoding control module 36. The module 36 returns the decrypted result to the monitoring layer 34. As described above, in this embodiment, decryption is performed in units of data blocks in the file. Thereby, according to this embodiment, only a necessary part in a file can be decoded.

(Step 12 in FIG. 2)
The monitoring layer 34 returns the decrypted result (that is, the decrypted file) as a result of the API call to the application 32. As a result, the application 32 can safely acquire the contents of the file. Therefore, the user can open the encrypted file by the application 32 and browse the file by the display device.

  According to the method of the present embodiment, it is possible to perform processing such as opening or printing an encrypted file in units of files. In the method of processing the file by decoding the entire HDD, the file may be leaked by file exchange software or the like. On the other hand, in the method of the present embodiment, since decryption is performed in units of files, there is no such concern and the safety of the file can be improved.

  Furthermore, in the method of this embodiment, the decoding process as described above can be performed only by rewriting the API call code without modifying the program. For this reason, it can respond to various programs. In addition, there is an advantage that there is no restriction on the type of file to be handled.

(Temporary file export processing)
Next, the procedure for temporarily writing the data in the decrypted file will be described with further reference to FIG. However, the description of the same processing as that described above will be omitted or simplified.

(Step 0 in FIG. 3)
First, the user registers in advance the decryption permission application and the encrypted writeable folder in the list. This is the same as step 0 in FIG.

(Step 1 in FIG. 3)
Further, the monitoring control module 33 checks the application code on the memory when executing the application. Further, the monitoring control module 33 rewrites the API call code for file operation in the application registered in the list that requires decryption processing or encrypted writing so as to call the code of the monitoring layer 34. This operation is basically the same as step 1 in FIG. However, in the example of FIG. 3, whether or not writing can be controlled can be controlled by the monitoring layer 34 that is called as a result of rewriting the code.

(Step 1 ′ in FIG. 3)
Further, in the processing of FIG. 3, the monitoring control module 33 provides the decryption control / encryption processing module 36 with information on folders that are permitted to be encrypted and
-Pass the key information used for encryption in this encrypted export.

(Step 2 in FIG. 3)
The application 32 makes an API call. However, since the code has been rewritten in step 1, the monitoring layer 34 is actually called.

(Step 3 in FIG. 3)
The monitoring layer 34 checks the parameters of the API call code before rewriting (explained in step 3 in FIG. 2), and determines whether encryption writing is necessary. When these processes are necessary, the decryption control / encryption processing module 36 is called. That is, the monitoring layer 34 sends the encryption command to the decryption control / encryption processing module 36.

(Steps 4 to 10 in FIG. 3)
Upon receiving the encryption command, the decryption control / encryption processing module 36 determines whether or not the save destination folder in the writing process obtained from the application matches the encrypted writing permission folder that has been passed as the list 331 in advance. . If they match, the decryption control / encryption processing module 36 calls the OS kernel 37 and acquires data to be written out. Further, the decryption control / encryption processing module 36 encrypts and stores the acquired data in an authorized storage location. This encryption key is generated and used differently for each process and file (ie, the same file has different keys for different processes. Also, the same process has the same key for different files. .).

  If the save destination folder specified by the application 32 does not match the encrypted write permission folder, the decryption control / encryption processing module 36 returns an error to the application 32. In the present embodiment, this processing can inhibit the application 32 from saving data in an arbitrary folder. Thereby, the safety | security of the data in a file can be improved.

  According to the method of the present embodiment, writing of a temporary file, which is an operation necessary for the operation of the application program 32, can be realized. Further, since the data is written out in an encrypted state, the security of the file contents can be improved.

(Step 11 in FIG. 3)
Next, the monitoring layer 34 returns the saved result (specifically, for example, a “save complete” message) to the application 32 as a result of the API call.

(API call processing that does not require decryption)
Next, an API call processing procedure that does not require a decoding process will be schematically described with reference to FIG. This process is basically the same as a normal API call. Further, the description of the same processing as the processing already described is omitted.

(Step 1 in FIG. 4)
Of the API call codes in the decryption permission application 32, the monitoring control module 33 does not rewrite the codes that are not related to the decryption process or printing. When the application 32 calls such a code, the standard API code 35 is called as usual. In this case, the monitoring layer 34 is not called. That is, the API call code passes through the monitoring layer 34.

(Steps 2 to 7 in FIG. 4)
The called standard API 35 calls the OS kernel 37 as usual and acquires the processing result.

(Step 8 in FIG. 4)
After obtaining the processing result, the standard API 35 returns the result of the API call to the application 32.

  In the present embodiment, a standard API can be called as usual for API call codes not related to file decryption processing or printing. The called standard API can operate normally and return the processing result to the application 32.

(Processing of API parameters that do not require decryption processing)
Next, an API parameter processing procedure that does not require a decoding process will be schematically described with reference to FIG. This process is also basically the same as a normal API call. Further, the description of the same processing as the processing already described is omitted.

(Step 1 in FIG. 5)
The monitoring control module 33 checks the application code on the memory when the decryption permission application 32 is executed. Further, the monitoring control module 33 rewrites the file operation API call code so as to call the code of the monitoring layer 34. This is the same as the above example.

(Steps 2 and 3 in FIG. 5)
Next, the application 32 makes an API call. However, since the code has been rewritten in step 1, the monitoring layer 34 is actually called.

  The monitoring layer 34 checks the parameters of the API call and determines whether or not the decoding process is actually necessary. Examples of parameters are as described in step 3 of FIG. If the decryption process is not actually required, a standard API is called.

(Steps 4 to 9 in FIG. 5)
The standard API calls the OS kernel 37 as usual and acquires the processing result. Thereafter, the standard API returns the result of the API call to the monitoring layer 34.

(Steps 10 and 11 in FIG. 5)
The monitoring layer 34 returns the processing result received from the standard API 35 to the application 32 as a result of API call.

(Processing API calls from applications that are not decryption target applications)
Next, API call processing from an application that is not described as a decryption target application in the list 331 will be schematically described with reference to FIG. This process is basically the same as a normal API call. Further, the description of the same processing as the processing already described is omitted.

(Step 1 in FIG. 6)
For APIs for file operations (including printing) from applications not listed in the list 331 as applications to be decrypted, the monitoring control module 34 does not rewrite the code. Therefore, the API call code for file operation in the application 32 calls the standard API 35 as it is.

(Steps 2 to 7 in FIG. 6)
The called standard API 35 calls the OS kernel 37 as usual, and acquires the processing result.

(Step 8 in FIG. 6)
The standard API 35 returns the result of the API call to the application 32.

  According to the file management method of the present embodiment, by changing the contents to be written to the monitoring control module 33 (for example, decryption permission application, encrypted writable folder, API call code to be rewritten, rewrite contents, etc.) There is an advantage that it can be used for various applications and is very versatile.

  It should be noted that the scope of the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the scope of the present invention.

  For example, each component described above may exist as a functional block, and may not exist as independent hardware. As a mounting method, hardware or computer software may be used. Furthermore, one functional element in the present invention may be realized by a set of a plurality of functional elements. A plurality of functional elements in the present invention may be realized by one functional element.

  Moreover, the functional element may be arrange | positioned in the position physically separated. In this case, the functional elements may be connected by a network.

1 is an overall functional block diagram of a file management apparatus according to an embodiment of the present invention. It is explanatory drawing for demonstrating the procedure (decoding process) of the file management method which concerns on one Embodiment of this invention. It is explanatory drawing for demonstrating the procedure (encryption write-out process) of the file management method which concerns on one Embodiment of this invention. It is explanatory drawing for demonstrating the procedure (process of a non-target API call) of the file management method which concerns on one Embodiment of this invention. It is explanatory drawing for demonstrating the procedure (process of a non-target API parameter) of the file management method which concerns on one Embodiment of this invention. It is explanatory drawing for demonstrating the procedure (process of a non-target application) of the file management method which concerns on one Embodiment of this invention.

Explanation of symbols

1 Internal environment (content provider internal environment)
DESCRIPTION OF SYMBOLS 11 Content encryption system 12 Content storage 13 Content file 14 Encrypted content 2 Public server environment 21 Content distribution server 22 Key transmission server 23 Key recording storage 231 Content ID and decryption key 3 User computer 31 Content downloader 32 Application program 321 API call code 33 Monitoring control module 331 List 34 Monitoring layer 35 Standard API
36 Decryption / Encryption Module 37 OS Kernel 38 Device Driver 39 Local Disk (Secondary Storage Device)
4 Internet

Claims (9)

A file management system comprising the following (a) to (d):
(A) application program,
(B) the monitoring layer,
(C) a decoding control module;
(D) OS kernel,
here,
The application program includes an API call code for operating a file,
The monitoring layer hooks an API call from the application program, and sends a decryption instruction for decrypting the file to the decryption control module.
The decryption control module requests the OS kernel to perform decryption processing based on the decryption instruction sent from the monitoring layer,
The OS kernel decrypts the file based on a request from the decryption control module, generates a decrypted file, and returns the decrypted file to the decryption control module.
Further, the decryption control module is configured to return the decrypted file returned from the OS kernel to the application program. further,
(E) a supervisory control module;
The file management system according to claim 1, comprising:
The monitoring control module is configured to be able to hook an API call from the application program by rewriting the API call code included in the application program. further,
(F) The file management system according to claim 1 or 2, comprising a secondary storage device,
The secondary storage device stores the encrypted file. further,
(G) The file management system according to any one of claims 1 to 3, comprising a key transmission server,
The file management system according to any one of claims 1 to 3, wherein the decryption control module is configured to perform the decryption process using a key received from the key transmission server.   The file management system according to claim 1, wherein the API call code is for opening a file.   The file management system according to claim 5, wherein the API call code further includes one for printing a file. further,
(H) The file management system according to claim 1, comprising a cryptographic processing module,
The monitoring layer is configured to send an encryption command to the cryptographic processing module based on the hooked API call;
The cryptographic processing module is configured to perform processing of encrypting data necessary for the operation of the application program and writing it to a temporary file after receiving the encryption command. A file management method using a file management system comprising the following (a) to (d):
(A) application program,
(B) the monitoring layer,
(C) a decoding control module;
(D) OS kernel,
here,
The application program includes API call code for manipulating files;
This method comprises the following steps:
The monitoring layer hooks an API call from the application program and sends a decryption instruction for decrypting the file to the decryption control module;
The decryption control module requests the OS kernel to perform a decryption process based on the decryption instruction sent from the monitoring layer;
The OS kernel decrypts the file based on a request from the decryption control module to generate a decrypted file, and returns the decrypted file to the decryption control module;
Furthermore, the decryption control module returns the decrypted file returned from the OS kernel to the application program.   A computer program for causing a computer to execute the method according to claim 8.

Images