A file access system includes a file opening unit which opens a given file within an external storage device when a file opening request is issued by an application program. A determining unit determines whether a given file within the storage device has encrypted data when a reading request is issued by the application program. When the given file is determined as having the encrypted data, a reading unit receives a fixed length of the encrypted data from the given file and generates a block of decrypted data of the same size as the fixed length by performing a decryption wherein a position of the fixed length of the decrypted data is determined by a position indicated by the reading request.
|
13. A file accessing method, comprising:
receiving a read event in response to a reading request issued by the application program; determining whether a file contains encrypted data based on the received read event by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received read event, is set to indicate that files contained in the corresponding folder contain the encrypted data; and receiving a fixed length of the encrypted data from the file when the file contains the encrypted data and generating decrypted data of a same size as the fixed length by decrypting the received encrypted data.
14. A file accessing method, comprising:
receiving a write event in response to a writing request issued by an application program; determining whether a file contains encrypted data based on the received write event, by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received write event, is set to indicate that files contained in the corresponding folder contain the encrypted data; receiving a fixed length of the encrypted data from the file when the file contains the encrypted data and generating decrypted data of a same size as the fixed length by decrypting the received encrypted data; and overwriting new data from the application program to the decrypted data, generating encrypted data of the same size as the fixed length by encrypting the decrypted data produced by the overwriting, and overwriting the encrypted data to the file at the position indicated by the writing request.
4. A file access system in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving unit receiving a read event in response to a reading request issued by the application program; a determining unit determining whether the file within the storage device has encrypted data based on the received read event, the determining unit performing said determination by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received read event, is set to indicate that files contained in the corresponding folder have encrypted data; and a reading unit receiving a fixed length of the encrypted data from the file when the file contains the encrypted data, said reading unit generating decrypted data by performing a decryption of the received encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the received read event.
1. A file access system in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving unit receiving a read event in response to a reading request issued by the application program; a determining unit determining whether the file within the storage device has encrypted data based on the received read event, the determining unit performing said determination by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received read event, is set to indicate that files contained in the corresponding folder have encrypted data; and a reading unit receiving a fixed length of the encrypted data from the file when the file contains the encrypted data, said reading unit generating decrypted data of a same size as the fixed length by performing a decryption of the received encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the received read event.
11. A computer readable medium storing program code causing a processor to carry out a file accessing procedure in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving program means for causing the processor to receive a read event in response to a reading request issues by the application program; first program code means for causing the processor to determine whether the file within the storage device has encrypted data based on the received read event, the determination being performed by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received read event, is set to indicate that files contained in the corresponding folder contain the encrypted data; and second program code means for causing, when the file contains the encrypted data, the processor to receive a fixed length of the encrypted data from the file and generate decrypted data by performing a decryption of the received encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the by the received read event.
9. A file access system in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving unit receiving a write event in response to a writing request issued by the application program; a determining unit determining whether the file within the storage device has encrypted data based on the received write event, said determining unit performing the determination by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received write event, is set to indicate that files contained in the corresponding folder contain the encrypted data; and a writing unit receiving a fixed length of the encrypted data from the file when the file contains the encrypted data, said writing unit generating decrypted data by performing a decryption of the encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the writing request, and said writing unit overwriting new data from the application program to the decrypted data, generating encrypted data by performing an encryption of the decrypted data produced by the overwriting, and overwriting the generated encrypted data to the file at the position indicated by the writing request.
6. A file access system in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving unit receiving a write event in response to a writing request issued by the application program; a determining unit determining whether the file within the storage device has encrypted data based on the received write event, said determining unit performing the determination by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received write event, is set to indicate that files contained in the corresponding folder contain the encrypted data; and a writing unit receiving a fixed length of the encrypted data from the file when the file contains the encrypted data, said writing unit generating decrypted data of same size as the fixed length by performing a decryption of the received encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the writing request, and the writing unit overwriting new data from the application program to the decrypted data, generating encrypted data of the same size as the fixed length by performing an encryption of the decrypted data produced by the overwriting and overwriting the encrypted data to the file at the position indicated by the writing request.
12. A computer readable medium storing program code causing a processor to carry out a file accessing procedure in which a file within a storage device is accessed when a request is issued by an application program, comprising:
a receiving program means for causing the processor to receive a write event in response to a writing request issues by the application program; first program code means for causing the processor to determine whether the file within the storage device has encrypted data based on the received write event, said determination being performed by checking if a portion of a registered management table for a corresponding folder for the file, the corresponding folder being indicated by the received write event, is set to indicate that files contained in the corresponding folder contain encrypted data; second program code means for causing, when the file contains the encrypted data, the processor to receive a fixed length of the encrypted data from the file and generate decrypted data by performing a decryption of the received encrypted data, a position of the fixed length of the decrypted data being determined by a position indicated by the writing request; third program code means for causing the processor to overwriting new data from the application program to the decrypted data; fourth program code means for causing the processor to generate encrypted data by performing an encryption of the decrypted data produced by the overwriting, and overwriting the generated encrypted data to the file at the position indicated by the writing request.
2. The file access system according to
3. The file access system according to
5. The file access system according to
7. The file access system according to
8. The file access system according to
10. The file access system according to
|
(1) Field of the Invention
The present invention relates to a file access system which accesses a file within an external storage device when a request to read data from or write data to the file is issued by an application program.
(2) Description of the Related Art
In a conventional file access method, a given file within an external storage device is accessed when a request is issued by an application program in order to read data from or write data to the file. In a case in which a file having encrypted data (or ciphertext) is accessed, the whole ciphertext from the file is copied to a working file. The whole ciphertext in the working file is decrypted into plaintext (or decrypted data), and the plaintext is copied to the working file. After the decryption is performed, the working file is accessed to obtain the plaintext. After the accessing procedure is performed, the plaintext is encrypted, and the encrypted data is copied to the file within the external storage device.
More specifically, in the conventional file access method, when encrypted data of a file within the external storage device is read by an application program, all the encrypted data from the file is copied to a working file. After the encrypted data is decrypted into plaintext in the working file, the working file is accessed to return the plaintext to the application program. After the accessing procedure is performed, the plaintext is encrypted into the ciphertext and the ciphertext (or the encrypted data) is copied to the file within the external storage device.
Therefore, when a file having encrypted data within the external storage device is accessed according to the conventional file access method, it is necessary to generate a working file and decrypt the data of the file to store the result of decryption in the working file. This makes it difficult to efficiently access the file having encrypted data within the external storage device.
Further, in the case of the conventional file access method, the plaintext (or the decrypted data) in the working file remains unprotected after the accessing procedure is finished, and there is a problem in that the conventional file access method fails to provide adequate security for information of the file within the external storage device.
An object of the present invention is to provide an improved file access system in which the above-mentioned problems are eliminated.
Another object of the present invention is to provide a file access system which utilizes a simple accessing method and efficiently accesses a file within an external storage device even if the file has encrypted data.
Sill another object of the present invention is to provide a file access system which provides adequate security for information of a file within an external storage device even after the accessing procedure for the file is finished.
The above-mentioned objects of the present invention are achieved by a file access system in which a file within a storage device is accessed when a request is issued by an application program, the file access system comprising: a determining unit which determines whether a given file within the storage device has encrypted data when a reading request is issued by the application program; and a reading unit which receives a fixed length of the encrypted data from the given file when the given file is determined as having the encrypted data, the reading unit generating decrypted data of the same size as the fixed length by performing a decryption wherein a position of the fixed length of the decrypted data is determined by a position indicated by the reading request.
The above-mentioned objects of the present invention are achieved by a file access system in which a file within a storage device is accessed when a request is issued by an application program, the file access system comprising: a determining unit which determines whether a given file within the storage device has encrypted data when a writing request is issued by the application program; and a writing unit which receives a fixed length of the encrypted data from the given file when the given file is determined as having the encrypted data, the writing unit generating decrypted data of the same size as the fixed length by performing a decryption wherein a position of the fixed length of the decrypted data is determined by a position indicated by the writing request, and the writing unit overwriting new data from the application program to the decrypted data, and further the writing unit generating encrypted data of the same size as the fixed length by performing an encryption of the decrypted data, and overwriting the encrypted data to the given file at the position indicated by the writing request.
In the file access system of the present invention, a simple encryption/decryption method is utilized to carry out the read/write processing. It is not necessary for the present invention to generate a working file and encrypt/decrypt data of a given file to store the result of encryption/decryption in the working file. The file access system of the present invention can efficiently access the given file within the external storage device. Further, in the file access system of the present invention, it is difficult to discriminate between a block of encrypted data and a block of decrypted data since both blocks have the same size. Therefore, the file access system of the present invention is effective in providing adequate security for information of the given file within the external storage device even after the accessing procedure for the file is finished.
The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description when read in conjunction with the accompanying drawings in which:
A description will now be given of the preferred embodiment of the present invention with reference to the accompanying drawings.
In
A user authentication unit 2 provides authentication of a user when an encryption/decryption processing for files within the external storage device 10 is performed, which will be described later with reference to FIG. 3.
In the file system 3, the file access system driver 4 carries out a file accessing procedure when a request is issued by the application 1, so that a given file within the external storage device 10 is accessed. The file system 3 is provided with an operating system (not shown in FIG. 1). The operating system provides a software platform on top of which the application 1 can run. Further, the file system 3 is provided with a central processing unit (CPU) and a memory, both of which are not shown in FIG. 1. The CPU carries out a processing according to the application 1 on top of the operating system in the file system 3, and the memory is used by the CPU when the processing according to the application 1 is performed.
The file access system driver 4 provides execution of various fundamental operations needed for the file accessing procedure. As shown in
In the file access system driver 4, the file opening unit 5 causes the CPU to perform a file opening process to open a file within the external storage device 10, which will be described later with reference to FIG. 4.
The reading unit 6 causes the CPU to perform a reading process which will be described later with reference to FIG. 5. When a portion of a user-level management table (
The writing unit 7 causes the CPU to perform a writing process which will be described later with reference to FIG. 6. When a portion of the user-level management table for a folder containing a given file indicates that files in the folder have encrypted data, the writing unit 7 receives a fixed length of the encrypted data from the file, generates a block of decrypted data of the same size by performing the decryption, and overwrites new data from a write buffer to the decrypted data. Further, the writing unit 7 receives a fixed length of the decrypted data from the data produced by the overwriting, and generates a block of encrypted data of the same size by performing the encryption, so that the resulting data is written to the file within the external storage device 10. When the portion of the user-level management table for the folder indicates that the files in the folder have plaintext, the writing unit 7 overwrites new data to the plaintext read from the file and writes the resulting data to the file within the external storage device 10 without performing the decryption/encryption.
The file closing unit 8 causes the CPU to perform a file closing process which will be described later with reference to FIG. 7.
In the file access system driver 4 of the present embodiment, a file accessing program related to the flowcharts of
Further, in the present embodiment, the memory of the file system 3 may store encoded or non-encoded instructions. The instructions may first be installed from a floppy disk or a CD-ROM to a secondary memory (not shown) of the file system 3, transferred to a main memory (not shown) of the file system 3 and then read by the CPU. The memory of the file system 3 may store either all or a part of the program code instructions related to the flowcharts of
Referring back to
Next,
The file access system driver 4 of the present embodiment is, for example, a driver #1 which causes the CPU to perform a file accessing process according to the present invention. In the following, the file access system driver 4 of the present embodiment will be called the driver #1, for the sake of simplicity of description.
As shown in
When the result of the above S2 is negative, the driver #1 causes the CPU to return a negative acknowledgement of the received driver verification to the operating system. The operating system performs an error process when the negative acknowledgement is received (S3).
On the other hand, when the result of the above S2 is affirmative, the driver #1 causes the CPU to return an acknowledgement of the received driver verification to the operating system. When the acknowledgement is received, the operating system accepts entry of the driver #1 into the operating system (S4). After the entry of the driver #1 in the above S4 is performed, the operating system transmits an initialization start command to the driver #1 (S5).
When the initialization start command is received, the driver #1 causes the CPU to issue to the operating system a request to hook the event in the file system 3 (S6). Specifically, when the event in the file system 3 is hooked, the driver #1 causes the CPU in the above step S6 to notify the operating system of a hook address ("FSHook ( ); ") of a program being called.
When the request in the above S6 is received, the operating system sets a corresponding portion of a file management table (
As shown in
After the portion of the hook address in the above S7 is performed, the operating system transmits an acknowledgement of the received request to the driver #1.
After issuing of the request in the above S6 is performed, the driver #1 causes the CPU to determine whether the acknowledgement from the operating system is received (S8). When the result of the above S8 is affirmative, the initialization process of
As shown in
After input of the user ID and the password in the above step S11 is performed, the user authentication unit 2 causes the CPU to determine whether the input user ID and password accords with a registered user ID and password (S12).
When the result of the above S12 is affirmative, the user authentication unit 2 causes the CPU to set a corresponding portion of the user-level management table (
When the result of the above S12 is negative, the user authentication unit 2 causes the CPU to perform an error process so as to ask the user to re-try the inputting of a user ID and a password, or to provide the user with an error message.
After setting of the user-level management table in the above S13 is performed, the user authentication unit 2 causes the CPU to notify the driver #1 of the encryption-type folder for which the corresponding portion of the user-level management table has been set in the above S13 (S14).
When the notification in the above S14 is performed, the driver #1 causes the CPU to register the user-level management table, in which the corresponding portion for the folder is set as being the encryption-type folder, with the memory of the file system 3 (S15).
As shown in
After the notification in the above S14 is performed, the user authentication unit 2 causes the CPU to request the driver #1 to start the encryption/decryption (S16).
When the request in the above S16 is performed, the driver #1 causes the CPU to start the encryption/decryption for files in the folder of the external storage device 10 (S17).
Accordingly, the user authentication unit 2 provides authentication of a user, and, only against an authorized user, the file access system driver 4 causes the CPU in the above step S15 to register the user-level management table in which a corresponding portion for a given folder is set as being the encryption-type folder. The corresponding portion of the user-level management table for the given folder indicates whether the encryption/decryption must be performed after the reading/writing process during the file accessing procedure. Further, the file access system driver 4 causes the CPU in the above step S17 to start the encryption/decryption for files in the given folder of the external storage device 10.
As shown in
When the file opening process is started in the above S22, the driver #1 (or the file opening unit 5) causes the CPU to receive an open event from the operating system (S23). The open event includes: a file name (including a path name); a file attribute; a file handle; file opening function parameters; a return address for the file system 3; and others.
The driver #1 causes the CPU to determine whether the portion of the user-level management table for the folder (indicated by the path name of the open event) indicates that the files in the folder have encrypted data and during the file accessing procedure the encryption/decryption must be performed after the reading/writing process (S24).
When the result of the above S24 is negative, it is determined that the files in the folder indicated by the path name of the open event have plaintext and during the file accessing procedure the encryption/decryption is not performed after the reading/writing process. The driver #1 causes the CPU to return to the return address for the file system 3 (S25).
When the result of the above S24 is affirmative, it is determined that the files in the folder indicated by the path name of the open event have encrypted data and during the file accessing procedure, the encryption/decryption must be performed after the reading/writing process. The driver #1 causes the CPU to determine whether the file attribute of the open event indicates that the file is irrelevant to the file accessing procedure (S27). For example, in cases of system files, hidden files and driver files, the file attributes of such files indicate that the files are irrelevant to the file accessing procedure. These files are excluded from the file accessing procedure.
When the result of the above S27 is affirmative, it is determined that the file is irrelevant to the file accessing procedure. The driver #1 causes the CPU to store the file handle of the open event into a file attribute table (not shown) (S28). After the updating of the file attribute table in the above S28 is performed, the driver #1 causes the CPU to return to the return address for the file system 3 (S29).
When the result of the above S27 is negative, it is determined that the file is relevant to the file accessing procedure. The driver #1 causes the CPU in the above S29 to return to the return address for the file system 3.
After the above step S29 is performed, the file system 3 finishes the file opening process (S30). The application 1 receives the file opening function from the file system 3 (S31).
Accordingly, when a file opening function is issued by the application 1, the file opening unit 5 of the file access system driver 4 causes the CPU to carry out the file opening process to open a file within the external storage device 10.
As shown in
When the reading process is started in the above S42, the driver #1 (or the reading unit 6) causes the CPU to receive a read event from the operating system (S43). The read event is called a reading request. The read event includes: a file name (including a path name); a file handle; a read point; a read buffer; a read size; a return address for the file system 3; and others.
When the read event is received in the above S43, the driver #1 causes the CPU to determine whether the portion of the user-level management table for the folder (indicated by the path name of the read event) indicates that the files in the folder have encrypted data and during the file accessing procedure the encryption/decryption must be performed after the reading/writing process (S44).
When the result of the above S44 is negative, it is determined that the files in the folder indicated by the path name of the read event have plaintext and during the file accessing procedure the encryption/decryption has not to be performed after the reading/writing process. The driver #1 causes the CPU to return to the return address for the file system 3 (S45). In this case, a normal reading process for the given file within the external storage device 10 is performed.
When the result of the above S44 is affirmative, it is determined that the files in the folder indicated by the path name of the read event have encrypted data and during the file accessing procedure the encryption/decryption must be performed after the reading/writing process. The driver #1 causes the CPU to determine whether the file handle of the read event is included in the file attribute table which has been updated in the file opening process (S46).
When the result of the above S46 is affirmative, it is determined that the given file is irrelevant to the file accessing procedure. The driver #1 causes the CPU to return to the return address for the file system 3 (S47). In this case, the normal reading process for the given file within the external storage device 10 is performed.
When the result of the above S46 is negative, it is determined that the file is relevant to the file accessing procedure. The driver #1 causes the CPU to call a reading process in a HDD driver of the external storage device 10 (S48). In this case, a boundary process is performed so as to read data from the given file within the external storage device 10.
The reading process of the HDD driver causes the CPU to read the encrypted data from the given file within the external storage device 10 through the boundary process (S49).
After the above step S49 is performed, the driver #1 causes the CPU to receive a fixed length (for examples, 8 bytes) of the encrypted data from the given file and generate a block of decrypted data of the same size by performing the decryption (S50). This procedure is called a block decryption.
After the above step S50 is performed, the driver #1 causes the CPU to determine a position of the fixed length of the decrypted data by a position indicated by the read event, so that the decrypted data is set in the read buffer (S51).
After the above step S51 is performed, the driver #1 causes the CPU to return to the return address for the file system 3 (S52).
After the above step S52 is performed, the file system 3 finishes the reading process (S53). The application 1 receives the reading function with the read buffer from the file system 3 (S54).
Accordingly, when a reading function is issued by the application 1, the reading unit 6 of the file access system driver 4 causes the CPU to carry out the reading process to read data from a given file within the external storage device 10. Specifically, when a portion of the user-level management table for a folder containing the file indicates that the files in the folder have encrypted data, the reading unit 6 receives a fixed length of the encrypted data from the file and generates a block of decrypted data of the same size by performing the block decryption. When the portion of the user-level management table for the folder indicates that the files in the folder have plaintext, the reading unit 6 returns the plaintext read from the file, to the application 1 without performing the decryption.
In the file access system driver 4 of the present embodiment, a simple decryption method is utilized to carry out the reading process. Therefore, it is possible for the file access system driver 4 of the present embodiment to efficiently access the given file within the external storage device. Further, in the file access system driver 4 of the present embodiment, it is difficult to discriminate between a block of encrypted data and a block of decrypted data since both blocks have the same size. Therefore, it is possible for the file access system driver 4 of the present embodiment to provide adequate security for information of the given file within the external storage device even after the accessing procedure for the file is finished.
As shown in
When the writing process is started in the above S62, the driver #1 (or the writing unit 7) causes the CPU to receive a write event from the operating system (S63). The write event is called a writing request. The write event includes: a file name (including a path name); a file handle; a writing point; a writing buffer; a writing size; a return address for the file system 3; and others.
When the write event is received in the above S63, the driver #1 causes the CPU to determine whether the portion of the user-level management table for the folder (indicated by the path name of the writing event) indicates that the files in the folder have encrypted data and during the file accessing procedure the encryption/decryption must be performed after the reading/writing process (S64).
When the result of the above S64 is negative, it is determined that the files in the folder indicated by the path name of the write event have plaintext and during the file accessing procedure the encryption/decryption has not to be performed after the reading/writing process. The driver #1 causes the CPU to return to the return address for the file system 3 (S65). In this case, a normal writing process for the given file within the external storage device 10 is performed.
When the result of the above S64 is affirmative, it is determined that the files in the folder indicated by the path name of the write event have encrypted data and during the file accessing procedure the encryption/decryption must be performed after the reading/writing process. The driver #1 causes the CPU to determine whether the file handle of the write event is included in the file attribute table which has been updated in the file opening process (S66).
When the result of the above S66 is affirmative, it is determined that the given file is irrelevant to the file accessing procedure. The driver #1 causes the CPU to return to the return address for the file system 3 (S67). In this case, the normal writing process for the given file within the external storage device 10 is performed.
When the result of the above S66 is negative, it is determined that the file is relevant to the file accessing procedure. The driver #1 causes the CPU to call the reading process in the HDD driver of the external storage device 10 (S68). In this case, a boundary process is performed so as to read data from the given file within the external storage device 10.
The reading process in the HDD driver causes the CPU to read the encrypted data from the given file within the external storage device 10 through the boundary process (S69).
After the above step S69 is performed, the driver #1 causes the CPU to receive a fixed length (for examples, 8 bytes) of the encrypted data from the given file and generate a block of decrypted data of the same size by performing the block decryption (S70). Further, the driver #1 causes the CPU to determine a position of the fixed length of the decrypted data by a position indicated by the writing event.
After the above step S70 is performed, the driver #1 causes the CPU to overwriting new data from the writing buffer to the decrypted data which has been produced by the block decryption in the above step S70 (S71).
After the above step S71 is performed, the driver #1 causes the CPU to receive a fixed length (for example, 8 bytes) of the decrypted data from the decrypted data produced by the overwriting in the above S71 and generate a block of encrypted data of the same size by performing the encryption (S72). This encryption is called a block encryption.
After the above step S72 is performed, the driver #1 causes the CPU to call the write process of the HDD driver of the external storage device 10 (S73). In this case, a boundary process is performed so as to writing data to the given file within the external storage device 10.
The writing process of the HDD driver causes the CPU to writing the encrypted data from the driver #1 to the given file at the position indicated by the write event through the boundary process (S74).
After the above step S74 is performed, the file system 3 finishes the writing process (S75). The driver #1 causes the CPU to return to the return address for the file system 3 (S76). The application 1 receives the writing function from the file system 3 (S77).
Accordingly, when a reading function is issued by the application 1, the writing unit 7 of the file access system driver 4 causes the CPU to carry out the writing process to writing data from a given file within the external storage device 10. When a portion of the user-level management table for a folder containing the given file indicates that the files in the folder have encrypted data, the writing unit 7 receives a fixed length of the encrypted data from the file, generates a block of decrypted data of the same size by performing the block decryption, and overwrite new data from the writing buffer to the decrypted data. Further, the writing unit 7 receives a fixed length of the decrypted data from the data produced by the overwriting, and generates a block of encrypted data of the same size by performing the block encryption, so that the resulting data is written to the given file within the external storage device 10. When the portion of the user-level management table for the folder indicates that the files in the folder have plaintext, the writing unit 7 overwrite new data from the writing buffer to the plaintext read from the file and writings the resulting data to the file within the external storage device 10 without performing the decryption/encryption.
In the file access system driver 4 of the present embodiment, a simple encryption/decryption method is utilized to carry out the writing process. Therefore, it is possible for the file access system driver 4 of the present embodiment to efficiently access the given file within the external storage device. Further, in the file access system driver 4 of the present embodiment, it is difficult to discriminate between a block of encrypted data and a block of decrypted data since both blocks have the same size. Therefore, it is possible for the file access system driver 4 of the present embodiment to provide adequate security for information of the given file within the external storage device even after the accessing procedure for the file is finished.
As shown in
When the file closing process is started in the above S82, the driver #1 (or the file closing unit 8) causes the CPU to receive a close event from the operating system (S83). The close event includes: a file name; a file handle; a return address for the file system 3; and others.
The driver #1 causes the CPU to determine whether the portion of the user-level management table for the folder (indicated by the file name of the close event) indicates that the files in the folder have encrypted data (S84).
When the result of the above S84 is negative, it is determined that the files in the folder indicated by the file name of the close event have plaintext. The driver #1 causes the CPU to return to the return address for the file system 3 (S85). In this case, a normal file closing process for the given file within the external storage device 10 is performed.
When the result of the above S84 is affirmative, it is determined that the files in the folder indicated by the file name of the close event have encrypted data. The driver #1 causes the CPU to determine whether the file handle of the close event is included in the file attribute table which has been updated in the file opening process (S86).
When the result of the above S86 is negative, the driver #1 causes the CPU to return to the return address for the file system 3 (S87). In this case, the normal file closing process for the given file within the external storage device 10 is performed.
When the result of the above S86 is affirmative, the driver #1 causes the CPU to delete the file handle of the close event from the file attribute table (S89). After the updating of the file attribute table in the above S89 is performed, the driver #1 causes the CPU to return to the return address for the file system 3 (S90).
After the above step S90 is performed, the file system 3 finishes the file closing process (S91). The application 1 receives the file closing function from the file system 3 (S92).
Accordingly, when a file closing function is issued by the application 1, the file closing unit 8 of the file access system driver 4 causes the CPU to carry out the file close process to close a file within the external storage device 10.
As described above, in the file access system of the present invention, a simple encryption/decryption method is utilized to carry out the reading/writing process. It is not necessary for the present invention to generate a working file and encrypt/decrypt data of a given file to store the result of encryption/decryption in the working file. Therefore, the file access system of the present invention is effective in increasing the access speed at which a given file within the external storage device is accessed. Further, in the file access system of the present invention, it is difficult to discriminate between a block of encrypted data and a block of decrypted data since both blocks have the same size. Therefore, the file access system of the present invention is effective in providing adequate security for information of the given file within the external storage device even after the accessing procedure for the file is finished.
Further, the present invention is not limited to the above-described embodiments, and variations and modifications may be made without departing from the present invention.
Sasaki, Takaaki, Yamanaka, Yusuke
Patent | Priority | Assignee | Title |
10057726, | Oct 02 2012 | RAZER ASIA-PACIFIC PTE LTD | Managing user data on an electronic device |
10148433, | Oct 14 2009 | DigitalPersona, Inc.; DIGITALPERSONA, INC | Private key/public key resource protection scheme |
10303652, | Jan 14 2011 | Apple Inc. | File system management |
10356204, | Dec 13 2012 | Microsoft Technology Licensing, LLC | Application based hardware identifiers |
10425228, | Aug 27 2014 | International Business Machines Corporation | Receipt, data reduction, and storage of encrypted data |
10469622, | Sep 12 2011 | Microsoft Technology Licensing, LLC | Platform-enabled proximity service |
10694337, | Oct 02 2012 | Razer (Asia-Pacific) Pte. Ltd. | Managing user data on an electronic device |
6845908, | Mar 18 2002 | RENESAS ELECTRONICS AMERICA INC | Storage card with integral file system, access control and cryptographic support |
7096358, | May 07 1998 | RPX Corporation | Encrypting file system |
7139918, | Jan 31 2002 | International Business Machines Corporation | Multiple secure socket layer keyfiles for client login support |
7200747, | Oct 31 2001 | Hewlett Packard Enterprise Development LP | System for ensuring data privacy and user differentiation in a distributed file system |
7240345, | Feb 16 2001 | Sony Corporation | Data processing apparatus and associated method |
7398465, | Jun 20 2002 | The Boeing Company | System and method for identifying, classifying, extracting and resolving hidden entities |
7406596, | Mar 10 2000 | Herbert Street Technologies | Data transfer and management system |
7673153, | Mar 15 1999 | Sony Corporation | Data processing method, apparatus and system for encrypted data transfer |
7681007, | Apr 15 2004 | AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE LIMITED | Automatic expansion of hard disk drive capacity in a storage device |
7979714, | Jun 02 2006 | HARRIS GLOBAL COMMUNICATIONS, INC | Authentication and access control device |
8041947, | Mar 23 2006 | HARRIS GLOBAL COMMUNICATIONS, INC | Computer architecture for an electronic device providing SLS access to MLS file system with trusted loading and protection of program execution memory |
8060744, | Mar 23 2006 | HARRIS GLOBAL COMMUNICATIONS, INC | Computer architecture for an electronic device providing single-level secure access to multi-level secure file system |
8127145, | Mar 23 2006 | NERA INNOVATIONS LIMITED | Computer architecture for an electronic device providing a secure file system |
8141057, | Feb 16 2001 | Sony Corporation | Data processing apparatus and associated method |
8316199, | Nov 07 2006 | HITACHI SOLUTIONS, LTD | Data processing control method, information processing apparatus, and data processing control system |
8402039, | Feb 12 2009 | Brother Kogyo Kabushiki Kaisha | Information processing apparatus and computer readable medium having information processing program |
8667273, | May 30 2006 | DATA LOCKER INC | Intelligent file encryption and secure backup system |
8799651, | Jan 31 2008 | International Business Machines Corporation | Method and system for encrypted file access |
8856521, | May 07 2010 | FEITIAN TECHNOLOGIES CO , LTD | Methods and systems for performing secure operations on an encrypted file |
8918633, | Sep 30 2003 | DAI NIPPON PRINTING CO , LTD | Information processing device, information processing system, and program |
9118686, | Sep 06 2011 | Microsoft Technology Licensing, LLC | Per process networking capabilities |
9218623, | Dec 28 2005 | Xerox Corporation | System and method for providing private stable matchings |
9373003, | Jun 27 2014 | Ivanti US LLC | Systems and methods for automatically handling multiple levels of encryption and decryption |
9460296, | Jul 19 2013 | Ivanti US LLC | Systems, methods and media for selective decryption of files containing sensitive data |
9672564, | Dec 28 2005 | Xerox Corporation | Computer-implemented system and method for providing private stable matchings through a re-encryption mix network |
9679130, | Sep 09 2011 | Microsoft Technology Licensing, LLC | Pervasive package identifiers |
9773102, | Sep 09 2011 | Microsoft Technology Licensing, LLC | Selective file access for applications |
9800688, | Sep 12 2011 | Microsoft Technology Licensing, LLC | Platform-enabled proximity service |
9858247, | May 20 2013 | Microsoft Technology Licensing, LLC | Runtime resolution of content references |
Patent | Priority | Assignee | Title |
5699428, | Jan 16 1996 | Symantec Corporation | System for automatic decryption of file data on a per-use basis and automatic re-encryption within context of multi-threaded operating system under which applications run in real-time |
5835601, | Mar 15 1994 | Kabushiki Kaisha Toshiba | File editing system and shared file editing system with file content secrecy, file version management, and asynchronous editing |
5881287, | Aug 12 1994 | SOL LABS K G LIMITED LIABILITY COMPANY | Method and apparatus for copy protection of images in a computer system |
JP7140896, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Feb 26 1998 | Fujitsu Limited | (assignment on the face of the patent) | / | |||
May 01 1998 | SASAKI, TAKAAKI | Fujitsu Limited | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 009195 | /0976 | |
May 01 1998 | YAMANAKA, YUSUKE | Fujitsu Limited | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 009195 | /0976 |
Date | Maintenance Fee Events |
Sep 30 2005 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Sep 23 2009 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Sep 25 2013 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Apr 23 2005 | 4 years fee payment window open |
Oct 23 2005 | 6 months grace period start (w surcharge) |
Apr 23 2006 | patent expiry (for year 4) |
Apr 23 2008 | 2 years to revive unintentionally abandoned end. (for year 4) |
Apr 23 2009 | 8 years fee payment window open |
Oct 23 2009 | 6 months grace period start (w surcharge) |
Apr 23 2010 | patent expiry (for year 8) |
Apr 23 2012 | 2 years to revive unintentionally abandoned end. (for year 8) |
Apr 23 2013 | 12 years fee payment window open |
Oct 23 2013 | 6 months grace period start (w surcharge) |
Apr 23 2014 | patent expiry (for year 12) |
Apr 23 2016 | 2 years to revive unintentionally abandoned end. (for year 12) |