JPH09251426A - File ciphering system and its control method, and cipher file reception system and its control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a safe cipher file reception system and its method which need only one cipher file even when plural users access the same WWW(world wide web). SOLUTION: This cipher file reception system includes a server information processor 120 which includes a shared file cipher program 21b and previously ciphers the information transmitted through a WWW to store them in a magnetic disk 5b, and a client information processor 110 which includes a shared file cipher program 21a and a communication API hook program. Then the system hooks the communication API call sent from a browser program and automatically decodes the received file data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file encryption system for an information processing apparatus, a control method therefor, and a data reception control method when an encrypted file is received through a communication line, and more particularly, it can be decrypted by a plurality of users. The present invention relates to a shared file encryption system and its control method suitable for creating or decrypting various encrypted files, and an encryption file reception system and its control method transparent to an application program.

[0002]

2. Description of the Related Art As information processing apparatuses such as personal computers have become widespread, user program files stored on a magnetic storage device for each information processing apparatus,
Data files and the like are stored in one large-capacity magnetic storage device, and users of each information processing device share the file. Generally, a server information processing apparatus equipped with a file server program and a plurality of client information processing apparatuses equipped with a client program for accessing the server information processing apparatus are connected via a network. Is accessed and used from each client information processing device. Conventionally, such a file sharing system has been closed inside a company or the like, but with the spread of a global network called the Internet, a case where the Internet is connected to a company network to enable access from outside the company. Is increasing. The spread of the file sharing system and the wide area of the network as described above have made the security of the shared files on the file server, that is, the need for protection against unauthorized access higher than ever.

As a method of maintaining the security of a file on a server information processing apparatus, a user authentication mechanism provided in a file server program and an access authority setting / confirmation mechanism for each file based on the user authentication are used. General. However, in this method, data flowing on the network is not encrypted, so that unauthorized access by eavesdropping is possible. Therefore, when higher security is required, it is general to encrypt the data of the stored file or the file flowing on the network by using a secret key or a public key. These encryption methods are disclosed in detail in "Research on Data Protection and Encryption" supervised by Shin Ichimatsu and Nihon Keizai Shimbun (1983).

Further, on the Internet, a WWW (World-Wide We) having an information transmission function is provided.
b) It is general to provide information in a document file in a format called hypertext using a server. Software for interpreting the hypertext and displaying it graphically is called a browser and is widely used. The language specifications of the hypertext include HT
ML (HyperText Markup Langua
ge) is generally used, and this language specification and HTM
For a browser that displays files described in L, see "UNIX MAGAZINE" (1994.1).
0) pp. 52-60. Note that most HTML files are linked to other HTML files and image data files, and the browser receives the HTML file and then receives the image data file to which the HTML file is linked, and the contents of the HTML file. And display it on the same screen. These H
The TML file and the image data file linked to it are collectively called a page.

[0005] The WWW server is HTTP (Hype).
The HTML file and the image data are transmitted to a browser based on a communication protocol called "rtext Transfer Protocol". At this time, since the data flowing on the Internet is not encrypted,
Storing a page containing confidential information in the W server has a security problem. As means for encrypting data flowing on the Internet, for example, Secure HTTP
And SSL (Secure Socket Layer)
And the like. Also, about these technologies,
"Nikkei Communication" Nikkei BP (1995.1)
2.4 pages 75-80).

[0006]

Although the above-described encryption is sufficient from the viewpoint of protection against unauthorized access and wiretapping and tampering of data, it enables a plurality of users to securely access the same file. Therefore, it is necessary to use a different key for each user, and it is difficult to manage the key. In addition, when a stored file is encrypted, it is necessary to create an encrypted file for each key, and there is a problem that a large amount of storage capacity of a storage device is consumed. In addition, in the method of encrypting data on the network during communication,
There is also a problem that the access speed is reduced due to the encryption / decryption processing. Furthermore, in the method of encrypting data on the network during communication, the problem that the access speed is reduced due to the encryption process and that the WWW server manages confidential information in a plaintext file, the plaintext file There is a problem that confidential information is leaked by directly accessing the information processing device that manages the.

Further, in the case of the file sharing system, the client information processing device does not always have the decryption software program. When an encrypted file is read by an application program on an information processing device that is not equipped with decryption software, meaningless characters or symbols are displayed on the monitor screen of the information processing device, or the application program There is a problem that it may operate abnormally.

Further, the method of encrypting the file to be stored has a problem that the user forgets the encryption operation and stores the file to be protected from unauthorized access in plain text.

Further, the client information processing apparatus having the above-mentioned browser on the Internet does not always have the decryption software program. When an encrypted file is read by a browser on an information processing device that does not have decryption software, meaningless characters or symbols are displayed on the monitor screen of the information processing device, or the browser program is abnormal. There is a problem that it may operate.

Therefore, it is an object of the present invention to provide a file encryption system that requires only one encrypted file even when a plurality of users use the same file, and a secure file encryption method.

Another object of the present invention is to provide a file encryption system in which a user who permits decryption can be set for each user when a plurality of users encrypt files in the same directory. To provide a method.

Another object of the present invention is to provide a file encryption system and its control that do not operate abnormally even when an encrypted file is read in a client information processing apparatus that does not have decryption software. To provide a method.

Another object of the present invention is to provide a file encryption system and a control method therefor in which a user never forgets to encrypt.

Further, an object of the present invention is to provide a secure encrypted file receiving system and its control, in which only one encrypted file is required even when a plurality of users receive the same page from the WWW server on the Internet. To provide a method.

Another object of the present invention is to provide an encrypted file receiving system which does not operate abnormally even when an encrypted file is read out by a client information processing apparatus which does not have decryption software, and the same. It is to provide a control method.

Still another object of the present invention is to provide a cryptographic file receiving system and its control method in which the user does not need to explicitly instruct the decryption processing of the received encrypted file for each file. .

[0017]

The above object is to perform encryption in an information processing apparatus having at least an operating system (OS) having an input / output control function for files and a storage device for storing the files. An encrypted directory storage means capable of setting a plurality of target directories in advance for each user, a means for encrypting the storage data of the storage means, and write data to a file in the directory from an application program operating on the OS are provided. It is achieved by providing an encryption means for encrypting.

Another object is to provide an operating system (OS) having at least an input / output control function for a file, a storage device for storing the file, a file encryption means for encrypting the file, and In the information processing device, comprising: a decryption unit for decrypting a file, the file encryption unit uses the application program in the grammar for data encryption of a plaintext file described according to a grammar interpreted and processed by the application program. A descriptor for making an annotation text to be ignored as a non-processing object at the time of processing is added to the encrypted data and stored as an encrypted file, and the file decryption means, in the data decryption of the encrypted file, the annotation The data part annotated by the statement descriptor Decoded, it is achieved by storing the data in unencrypted plaintext file.

Another object is to provide a hook means for hooking a file operation request issued from the application program to the OS, and to automatically encrypt or decrypt the file operation request when the file operation request is issued. It is achieved by providing.

The above object is to provide a first information processing apparatus having an operating system (OS) having at least a communication control function and a file input / output control function, and a storage device for storing the file, and the first information processing apparatus. Operating system (OS) having a communication control function for receiving a file from at least the storage device on the first information processing device, which is connected to the information processing device via a network.
In a system including a second information processing apparatus including: a file encryption unit that encrypts the file and attaches a list of users who are information disclosure destinations to the encrypted file; and the second information processing apparatus When a user who uses the received file receives the encrypted file registered in the storage device, a received file decryption unit that decrypts the encrypted file, and if the user is included in the user list, This is achieved by providing the above-mentioned received file decryption means, and decryption right discrimination means for controlling so as not to perform decryption if not included.

Another object is to have an operating system (OS) having at least an input / output control function for a file, a storage device for storing the file, and a file encryption means for encrypting the file. In the first information processing apparatus, the file encryption means ignores the data encryption of the plaintext file described according to the grammar interpreted and processed by the application program as a non-processing target when processing the application program in the grammar. A descriptor to be an annotation text is added to the encrypted data and stored as an encrypted file, and the received file decryption means uses the descriptor for the annotation text to decrypt the encrypted file data. Decode the data part that is the annotation text,
It is achieved by passing it to the application program as the plaintext file data before encryption.

Another object is to provide a hook means for hooking a data transmission / reception request issued from the application program to the OS in the second information processing apparatus, and the hook means precedes the application program. This is accomplished by checking the received data, decrypting the received data if the received data is the data of the encrypted file, and passing the decrypted data to the application program.

[0023]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings.

First, the overall system configuration will be described. FIG. 1 is a configuration example of a shared file encryption system according to the present invention. 110 is a client information processing device, and 120 is a server information processing device. A central processing unit (CPU) 1b, a memory 2b, a LAN
A controller 3b, a disk controller 4b, and a magnetic disk 5b are provided. When the server information processing apparatus 120 is started, an operating system (O
S) 20b and the file server program 25 are loaded from the magnetic disk 5b to the memory 2b via the disk controller 4b. The client information processing device 110 includes a CPU 1a, a memory 2a, a LAN controller 3a, a disk controller 4a, a magnetic disk 5a, and an IC card controller 6, respectively. When the client information processing apparatus 110 is started, the OS 20a, the client program 24, the shared file encryption program 21, and the file I / O hook program 22 are loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a. You. The application program 23 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a according to an instruction from a user of the client information processing apparatus 110 (hereinafter, simply referred to as a user). The file I / O hook program 22 hooks (preempts) the file I / O API issued by the application program 23 to the OS 20a, and automatically performs encryption / decryption of file data in the background. .

The server information processing device 120 and the client information processing device 110 are connected to each other via a local area network (LAN) 101, and communicate with each other via each LAN controller 3.
Although FIG. 1 shows one client information processing apparatus 110, actually, a plurality of client information processing apparatuses 110 having the same configuration are connected to the LAN 101, and the client information processing apparatus 110 The file stored in the magnetic disk 5b of the information processing device 120 is shared. The user accesses a shared file on the magnetic disk 5b via the client program 24 to perform the sharing.

Further, the IC card controller 6 of the client information processing apparatus 110 has an IC card 130 detachable. In the IC card 130, a CP
A U1c, a nonvolatile memory 7, and an input / output interface 8 are provided. The nonvolatile memory 7 has an access control program 30, a group encryption program 28,
The D information 29 and the master key 31 are written. The contents of the nonvolatile memory 7 are stored in the input / output interface 8.
Can be accessed from outside via However,
In order to protect the storage contents of the nonvolatile memory 7 from unauthorized access, the user authentication control by the CPU 1c always intervenes.

FIG. 27 is a diagram showing a program routine that constitutes the shared file encryption program 21 and the file I / O hook program 22. The shared file encryption program 21 includes a login control routine 1 for logging in and out of the IC card 130.
000, a logout control routine 1100, a manual file encryption routine 2000 for the user to explicitly instruct and encrypt a file each time, and an HTML (Hyper Text Mark) manual file encryption.
HTML file encryption routine 210 arranged for a shared file described in up Language)
It consists of 0. The file I / O hook program 22 includes a file open hook routine 1200,
File create hook routine 1300, file read hook routine 1400, file write hook routine 1500, file close hook routine 1
600 and a file rename hook routine 1700.

FIG. 2 is a diagram showing an example of the contents of the ID information 29. Here, up to 10 sets of data indicating the contents of each category and their codes can be registered. What is actually stored in the nonvolatile memory 7 is only the data and code values.

Next, the operation of the group encryption program 28 will be described. In the group encryption, a destination list of a partner to whom decryption is permitted is created, and a hash value obtained by inputting the destination list to a hash function is used as an encryption / decryption key. The key is called a group key 51. The destination list in the present embodiment is the ID information 2
9 is expressed in a form linked by a conditional expression. Specifically, a “category number”, a “data code identifier”, an “operator”, and a “data” are set as a set and are separated by commas (,). This comma has a logical OR meaning. As an operator, in addition to equality (=), magnitude (>, <) and logical product (＾) can be used. For example, when the definition of the ID information 29 shown in FIG. 2 is used, the destination list for the destination of “Chief or higher of the fourth part of System Research Laboratory and Taro Cryptography” is “5C = 676 ^ 6C = 04 ^ 8C > = 5, 2D = Cryptaro. ”

FIG. 3 is a diagram showing an example of a procedure for calculating the hash value of the destination list and creating the group key 51. 31 is a master key, 41 is a destination list, 51 is a group key, and 32 is a hash function. First, the ID
If the data length of the destination list created based on the information is not a multiple of 8 bytes, the shortage is supplemented with blank characters and a random number of 8 bytes is added. Address list is exactly 8
If it is a multiple of, an 8-byte random number is simply added. The destination list that is a multiple of 8 is simply referred to as a destination list 41 below. By adding a random number in this way, a different group key is generated each time even at the same destination, so that security can be improved.

Next, the operation of the hash function 32 will be briefly described. First, the destination list 41 is encrypted by 8 bytes at a time from the beginning by a block encryption method, and an exclusive OR of a result of the encryption and an initial value is obtained and used as an initial value of a block encryption of the next stage. This process is performed in the destination list 41.
And the exclusive OR of the encryption result output from the last stage and the initial value is used as the group key 51.
In the block cipher, an 8-byte master key 31 is used.
Then, the input data is encrypted using the initial value of 8 bytes. A user who encrypts data and a user who decrypts data use the master key 31 having the same value.

FIG. 4 is a flow chart showing the processing contents of the group encryption program 28 in the IC card 130. In the group encryption program 28, a group key 51 is created from the destination list 41 by using the above-described group key generation method. In step 401, it is checked whether or not the login to the access control program 30 of the IC card 130 is completed, and if it is not completed, an error code is set in step 411 and the program is terminated. If the login has been completed,
The input destination list 41 is analyzed in step 402,
It is checked whether there is a destination corresponding to the ID information 29. If the result of the inspection indicates that the destination is applicable, step 40
Step 3 is executed, and if not, an error code is set in step 412 and the program ends. Step 4
In 03, a group key is generated by the method described with reference to FIG. With the above processing, the user has already logged in to the IC card 130 and
It is possible to control to generate a group key only when there is ID information 29 in 0.

By encrypting the data using the group key 51 described above, only the person having the ID information 29 included in the destination list 41 can decrypt the data.

Next, an example in which the above-mentioned group cipher is applied to the cipher of a file will be described. FIG. 5 is a diagram showing a file encryption procedure and a configuration of a file after encryption. Reference numeral 501 denotes a plaintext file before encryption, and 502 denotes an encrypted text file after encryption. 61 is an execution key generated as a random number; 504 is ciphertext data obtained by encrypting the contents of the file 501 using the execution key 61 as a key;
5 is a header to be added to the ciphertext data 504; 506 to 511 are contents of the header 505; 506 is a character string indicating the encryption method used; 507 is the file name of the plaintext file 501;
509 is an encrypted execution key obtained by encrypting the execution key 61 with the group key 51, 510 is the size of the destination list 41, and 511 is an encrypted destination obtained by encrypting the destination list 41 with the master key 31. It is a list. As shown in FIG. 6, the ciphertext file 502 can be decrypted in a procedure completely opposite to the above procedure. In the above-described file encryption, the group key 51 is used to encrypt the execution key 61, and the execution key 61 is used to encrypt file data. Therefore, when the destination list 41 is changed, first, the execution key 61 is changed to the group key 5 generated in the destination list 41 before the change.
1 and then re-encrypted with the group key 51 generated from the changed destination list 41. Thus, even when the destination list 41 is changed, the execution key 6
Re-encryption of file data having a larger amount of data than that of No. 1 can be unnecessary, and the change processing can be performed at high speed.

Next, the function of automatically encrypting / decrypting a file operated by the user by using the above-mentioned file encryption will be described. The file system used here is a general one included in a recent OS, and has a tree-like hierarchical structure. The sections of the tree are called directories, and the files in each directory are managed by files called directory files. The physical storage location of the file may be either the magnetic disk 5a of the client information processing device 110 or the magnetic disk 5b of the server information processing device 120.

FIG. 7 is a diagram showing a logical directory structure viewed from the user. When the automatic file encryption and decryption of the present embodiment are not introduced, the logical directory structure and the physical directory structure are the same. FIG. 8 is a diagram showing a physical directory structure after the automatic encryption and decryption of a file has been introduced. In a directory in which the user automatically encrypts and decrypts a file, a destination list file 901 is created with a user name as a file name and a file name with ".dei" added to the end thereof. When encryption is performed by setting a common destination for all users, “default.
destination list file 901 with the file name “dei”
Create In this way, the destination list file 90
When 1 is created, the files are automatically encrypted with the destination list described in the destination list file 901 as the destination, and are stored with a serial number and a file name with ".ssf" added to the end. It For example, the file "o
saka. “doc” is stored as “0001.ssf”. In addition, an encrypted file information file 902 named “fileinfo.dei” is created in the directory where the automatic encryption has been performed.

FIG. 9 shows the destination list file 901,
It is a figure which shows an example of the content of the said encryption file information file 902. Destination list file 901 for each user
Is encrypted by group encryption with the user as the destination. Further, “default.dei” is encrypted using the master key 31. As a result, unauthorized reading and falsification of the destination list file can be prevented.
On the other hand, in the encrypted file information file 902, the file name after encryption, the plaintext file name before encryption, and the size of the plaintext file before encryption are written. The above file names are merely examples, and other names may be used.

Details of the processing program for handling the file having the physical structure shown in FIG. 8 as the logical file structure shown in FIG. 7 will be described below.

First, the login processing routine 1000 and the logout processing routine 1100 in the shared file encryption program 21 will be described. FIG. 10 is a diagram showing a processing flow of a login processing routine 1000 for the IC card 130. First, in step 1001, the user inputs an ID and a password.
Then, using the user ID and the password,
An attempt is made to log in to the C card 130, and it is determined in step 1003 whether or not the log in has been successful. If the result of the determination is a failure, step 1009 is executed, and control is performed so that steps 1001 and subsequent steps are repeated until three consecutive failures occur. If login is successful, step 100
At 4 the event wait state is set. When the event arrives,
It is checked whether the request is a logout request. If the request is a logout request, logout processing is performed in step 1008, and the processing is terminated. If the event is not a logout request, step 100
In step 6, it is checked whether the event is a timer event. If the event is not a timer event, the process returns to step 1004. If it is a timer event, it is checked whether or not the IC card 130 is connected to the client information processing apparatus 110. If it is connected, the process returns to step 1004; And exit. As described above, the logout process when the IC card 130 is removed can be automated by checking the connection of the IC card 130 periodically using the timer event.

FIG. 11 is a diagram showing a processing flow of a logout processing routine 1100 from the IC card 130. First, it is checked in step 1101 whether there is an open encrypted file, and if so, in step 1102, the user is asked whether to stop logout. If the logout process is to be stopped, this routine ends. If not stopped, in step 1103, the open file is closed and the process is continued. In step 1104, it is checked whether or not the IC card 130 is connected to the client information processing apparatus 110. If connected, a logout command is sent to the IC card 130 in step 1105, and the process ends. If not, the process ends.

Next, the processing of each routine in the file I / O hook program 22 will be described. First,
A description will be given from the data input / output of the file and the management method thereof.

FIG. 18 is a diagram showing a data input / output method in file encryption / decryption of this embodiment. The ciphertext data 504 of the ciphertext file 502 is read / written from / to the ciphertext block buffer 82 in units of the size of the ciphertext block buffer 82. The data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. The data in the plaintext block buffer 81 is encrypted and transferred to the ciphertext block buffer 82.

FIG. 19 shows a file handle table 90 for managing open encrypted files. Handle number 1902, open mode 1903, plaintext file pointer 1904, encrypted file pointer 190
5, buffer pointer 1906, update flag 1907,
The information of the destination list 41 is stored in a list structure using the pointer 1901 for each open file. Here, the handle number 1902 is a management number given from the OS 20 when the file is opened, and the open mode 1903 is a value indicating a mode such as read-only, write-only, or read / write.
The plaintext file pointer 1904 indicates a starting point when reading / writing the plaintext file 501 after decryption, and is indicated by the number of bytes from the head of the plaintext file 501. Note that the plaintext file 501 exists as a logical file that is read and written through the plaintext block buffer 81. Encrypted file pointer 1905
Indicates the starting point when reading / writing to the ciphertext file, and is indicated by the number of bytes from the beginning including the header 505 of 502. The cipher file pointer 1905 increases or decreases in buffer size units except for the last block of the file. Buffer pointer 19
06 is a value indicating which part of the plaintext file 501 corresponds to the head of the data transferred to the plaintext block buffer 81 and the ciphertext block buffer 82. The number of bytes is stored. The buffer pointer 190
6 increases or decreases only in units of buffer size. The update flag 1907 indicates that the data in the plaintext block buffer 81 has been updated by a write I / O operation, but is transferred to the ciphertext block buffer 82 and the ciphertext file 502.
This is a flag indicating a state in which writing to the memory has not been completed.

FIG. 12 is a diagram showing a processing flow of the file open hook routine 1200. First, in step 1281, it is checked whether or not the encrypted file information file 902 exists in the directory of the hooked file.
02, it is checked whether the file name of the hooked file is registered. If you are registered,
In step 1282, the file name is changed to the file name of the corresponding ciphertext file 502. Next, in step 1201, a file open request is issued to the OS 20a. It is checked in step 1202 whether or not the opening has succeeded. If the opening has failed, this routine ends. Next, in step 1203, it is determined whether or not login to the IC card 130 has been completed. If the login has been completed, the process proceeds to step 1207. If the user has not logged in, the process checks in step 1204 whether the file is an encrypted file. If not, the process of this routine ends. In the case of an encrypted file, the log-in processing routine 1000 is called in step 1205, so that the IC card 1
The server 30 performs a login process. In step 1206,
It is determined whether or not the login processing has been successful. If the login processing has not been successful, the message 2 125 is determined in step 1215.
2 is displayed and this routine ends. If the login is successful, it is determined in step 1207 whether the file has the decryption right, that is, whether the destination includes the logged-in user. The determination is made by obtaining the destination list 41 by decrypting the encrypted destination list 511 of the header 505 of the encrypted file, inputting the destination list 41 to the group encryption program 28 of the IC card 130, This is performed depending on whether the key 51 is output or an error code is output. If the user does not have the decryption authority, the message 2 1252 is output in step 1215.
Is displayed and the routine ends. If the user has the decryption right, in step 1209, it is checked whether or not the user or the common destination list file 901 exists in the directory. If it is not the encryption target directory, step 1216 is executed to check whether or not the hooked file is an encrypted file. If the file is not an encrypted file, this routine ends. In the case of an encrypted file, a message 31253 is displayed in step 1217 to inquire of the user whether or not to interrupt the process. If it is determined in step 1209 that the directory is an encryption target directory, it is checked in step 1210 whether the hooked file is an encrypted file.
1251 is displayed and an inquiry is made to the user as to whether or not to suspend the processing. If it is determined in step 1210 that the file is an encrypted file, it is checked in step 1218 whether the destination list 41 of the file and the destination of the destination list 41 written in the destination list file 901 of the directory are the same or different. If so, step 121
In step 9, message 41254 is displayed, and the user is inquired whether or not to interrupt the processing. Step 121
If it is determined in step 8 that the destinations are the same, step 1220
To register in the file handle table 90, and terminates this routine. Steps 1217 and 1217
In response to the message displayed in steps 11 and 1219, it is determined in step 1212 whether or not the user has selected to stop the processing. This routine ends. Step 1
If the determination at 212 is not aborted, the step 1
Step 220 is executed, and this routine ends.

FIG. 13 is a diagram showing a processing flow of the file create hook routine 1300. First, in step 1301, it is determined whether or not login to the IC card 130 has been completed. If the login has been completed, the process proceeds to step 1306. If the user has not logged in, it is checked in step 1302 whether the user or the common destination list file 901 exists in the directory, and if it exists, the directory is determined to be an encryption target directory. If it is not the directory to be encrypted, file creation is executed in step 1331 and this routine ends. In the case of the directory to be encrypted, a message 51355 is displayed in step 1303, and the login processing routine 10 is executed in step 1304.
By calling 00, the login process to the IC card 130 is performed. In step 1305, it is checked whether or not the login processing is successful, and if not successful, a message 61356 is displayed in step 1341 and the user is inquired whether or not to cancel the file creation. In step 1342, the user's selection is judged, and in the case of cancellation, a create error is set in step 1343 and this routine is ended. If not, the file creation is executed in step 1320, and this routine ends. On the other hand, if the login is successful in step 1305, in step 1306, the destination list file 9 of the user or the common destination is stored in the directory.
It is checked whether or not 01 exists, and if it exists, it is determined that the directory is an encryption target directory. If the directory is not the encryption target directory, file creation is executed in step 1320, and this routine ends. If the directory is an encryption target directory, the file name is
The file is replaced with a serial number and a file name with ".ssf" added to the end, and file creation is executed in step 1308. In step 1309, it is checked whether or not the file creation has succeeded. If the file creation has failed, this routine ends. If the file creation has succeeded, steps 1310 and subsequent steps are executed.
In step 1310, the header 50 of the encrypted file
5 is generated and written at the beginning of the file created in step 1308. In the following step 1311, registration in the encrypted file information file 902 is performed, and in step 1312, registration in the file handle table 90 is performed, and this routine ends.

FIG. 14 shows a lead hook routine 1400.
It is a figure which shows the processing flow of. First, step 1401
It is checked whether or not the file handle number included in the read I / O parameter has already been registered in the file handle table 90. If the file handle number has not been registered, it is not a file to be encrypted / decrypted. I / O is executed, and this routine ends. If the file is already registered in the file handle table 90, it is checked in step 1402 whether the open mode 1903 of the file handle table 90 is readable. If the open mode 1903 is not read, the process cannot be continued. An error code is set and this routine ends. Next, step 1403
To obtain the plaintext file pointer 1904. In step 1404, the plaintext file pointer 1904
Of the buffer starting from the buffer pointer 1906 is checked. If it is pointing, the processing is moved to step 1413, and if it is not pointing, step 1405 and subsequent steps are executed. Step 140
In 5, the update flag 1907 is referred to to check whether or not there is update data in the plaintext block buffer 81.
The file pointer No. 02 is moved to the buffer pointer 1906 by a seek command to the OS. In step 1407, the data in the plaintext block buffer 81 is encrypted, transferred to the ciphertext block buffer 82, and written back to the ciphertext file 502. Step 140
In step 8, the update flag 1907 is cleared, and a setting is made to indicate that there is no update data in the plaintext block buffer 81. In step 1409, the file pointer of the actual ciphertext file 502 is moved to the cipher file pointer 1905 by a seek command to the OS. In step 1410, data of the block size is read from the ciphertext file 502 to the ciphertext block buffer 82. In step 1411, the ciphertext file pointer 1905 and the buffer pointer 1906 are updated. In step 1412, the data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. In step 1413, the data is transferred from the plaintext block buffer 81 to the request buffer designated by the application program 23 requesting the hooked file read I / O. In step 1414, the number of transferred bytes is added to the plain file pointer 1904. At step 1415, it is checked whether or not data of the requested size has been transferred to the request buffer by the request source of the hooked file read I / O.
If completed, this routine ends.

FIG. 15 shows a light hook routine 1500.
It is a figure which shows the processing flow of. First, step 1501
The file handle number included in the parameter of the write I / O hooked by the above is stored in the file handle table 90.
It is checked whether or not the file has already been registered. If the file has not been registered, it is not a file to be encrypted / decrypted. Therefore, normal file read I / O is executed in step 1521, and this routine ends. If it is registered in the file handle table 90, it is checked in step 1502 whether the open mode 1903 of the file handle table 90 is set to "read / write enabled". An error code is set and this routine ends. It is necessary to have not only “write enabled” but also “read / write enabled”. For writing smaller than the encryption block unit, read the insufficient data, encrypt it and write it back. This is because a read-modify-write process is required.
The file open hook routine may forcibly replace “write permitted” with “read / write permitted” and open the file. Next, in step 1503, the plaintext file pointer 1904 is obtained. In step 1504, the plaintext file pointer 1904 is
It is checked whether or not the pointer is pointing in the buffer starting from the buffer pointer 1906. If so, the process proceeds to step 1513; otherwise, steps 1505 and subsequent steps are executed. In step 1505, the update flag 1907 is referred to, and it is checked whether or not there is update data in the plaintext block buffer 81. If there is no update data, the process proceeds to step 1510. The file pointer of the statement file 502 is moved to the buffer pointer 1906 by a seek command to the OS. In step 1507, the plaintext block buffer 81
Is transferred to the ciphertext block buffer 82 and written back to the ciphertext file 502. In step 1508, the update flag 1907 is cleared,
A setting is made to indicate that there is no update data in the plaintext block buffer 81. In step 1509, the file pointer of the ciphertext file 502 is moved to the position indicated by the cipher file pointer 1905 by a seek command to the OS. In step 1510,
It is checked whether or not the write data area of the hooked file write I / O request includes the entire current plaintext block buffer 81. If the result of the check does not include the entirety, the shortage is read and merged, so the ciphertext file 502 is read by the size of the ciphertext block buffer 82 in step 1511. The read data is stored in the ciphertext block buffer 82 and decrypted and stored in the plaintext block buffer 81. On the other hand, as a result of the check in the step 1510, if the whole is included, it is not necessary to read the shortage. Therefore, in the step 1518, the seek process is performed for the same size as the read size in the step 1511. In step 1512, the ciphertext file pointer 1905 and the buffer pointer 1906 are updated. In step 1513, the data from the position indicated by the plaintext file pointer 1904 to the position before the position indicated by the ciphertext file pointer 1905 is transferred from the hooked file I / O request write data buffer to the plaintext block buffer 81. In step 1514, an update flag 1907 indicating that the contents of the plaintext block buffer 81 has been updated is set, and it is determined whether or not transfer of all data of the file I / O write request hooked in step 1515 has been completed. If not, the process is repeatedly executed until steps 1506 and subsequent steps are completed. With the above processing, the plaintext block buffer 81 operates as a pre-read and pre-decryption cache and operates as a write-back cache.
A decrease in file I / O processing speed due to encryption / decryption can be reduced.

FIG. 16 shows the close hook routine 160.
FIG. 7 is a diagram showing a processing flow of 0. First, step 160
In step 1, it is checked whether or not the file handle for which the close request has been made is registered in the file handle table 90. If not, the process proceeds to step 1607, the file is closed, and the process ends. If the file has been registered in the file handle table 90, the update flag 1907 of the file handle table 90 is referred to, and the update flag 1907 is referred to.
Is set, that is, whether or not update data not written back to the file exists in the plaintext block buffer 81. If the update flag 1907 has been set, a process of encrypting the contents of the plaintext block buffer 81 and writing it back to the file is performed in step 1603. In the following step 1604, the plaintext block buffer 81
Is cleared by writing data such as all 0s, and the plaintext block buffer 81
Then, the ciphertext block buffer 82 is released. In step 1606, the node of the file is deleted from the file handle table 90, a file close request is issued to the OS in step 1607, and this routine ends.

FIG. 17 is a diagram showing a processing flow of the file rename hook routine 1700. First, in step 1701, it is determined whether or not the target of the rename is a directory file. If the target is a directory file, the rename is executed in step 1721, and this routine ends.
If it is not a directory file, it is determined in step 1702 whether or not the target file is an encrypted file. If it is not an encrypted file, renaming is executed in step 1721 and the routine ends. In the following step 1703, it is determined whether the user has the authority to decrypt the file, that is, the ID of the user who has logged in the destination list 41 of the header 505.
It is determined whether or not an item that matches the information 29 is included. If there is no decryption right, a message indicating that there is no right is displayed in step 1711, an error code is set in step 1712, and this routine ends. If the user has the decryption right, in step 1704, the plain text file name 507 in the header 505 of the file is changed to the new name designated by the application program 23.
In step 705, the plaintext file name of the file described in the encrypted file information file 902 is entered in step 17
Similar to 04, the name is changed to a new name, and this routine ends.

By the processing of each routine of the file I / O hook program 22 described above, the encryption / decryption of a file in a desired directory can be realized transparently from the application program 23.

Next, the shared file encryption program 2
The manual file encryption routine 2000 included in No. 1 will be described with reference to FIG. This routine operates with the file name of the plaintext file to be encrypted, the encrypted file name after encryption, and the destination list 41 as inputs. First, in step 2001, the designated plaintext file is opened, and in step 2002, a temporary file with a temporary name is created. In step 2004, a group key is generated by giving the designated destination list 41 to the group encryption program 28 of the IC card 130. The generation requires the login to the IC card 130, but since it is the same as the above embodiment, the description thereof is omitted here. In step 2005, the execution key 41, which is a random number, is generated.
In step 6, the header 505 is written to the head of the temporary file. In step 2009, data is read from the plaintext file, the data is encrypted in step 2010, and the encrypted data is written in the temporary file in step 2011. In step 2012, it is determined whether or not encryption of all the data of the plaintext file has been completed, and control is performed so that steps 2009, 2010, and 2011 are repeatedly executed until the encryption is completed. In step 2013, both the plaintext file and the temporary file are closed. In step 2014, it is determined whether or not the designated plaintext file name and the ciphertext file name are the same. In step 2016, the file name of the temporary file is changed to the specified ciphertext file name, and the program ends.

Next, an embodiment for encrypting an HTML file will be described. Reference numeral 2201 in FIG.
It is an example of a TML file. When the HTML file is displayed by an HTML browser, the screen shown in FIG. 23 is displayed. Reference numeral 2401 in FIG. 24 is an example of an encrypted HTML file, which includes a reader portion 2402 and the plaintext HT.
A main body portion 2403 that is an encrypted ML file 2201,
This is a combination of the footer portion 2404. At the end of the reader part 2402, "<!-", Which indicates the start of a comment sentence in HTML, is displayed at the beginning of the footer part 2404.
"->" Indicating the end of the comment sentence is set, and the main body portion 2403 becomes the content of the comment sentence by the synthesis. Since the content of the comment text is not displayed in the display by the HTML browser, the result of displaying the encrypted HTML file 2401 by the HTML browser is a screen as shown in FIG. By embedding the encrypted result as a comment text, a meaningless character string is displayed on the screen even if the encrypted file is erroneously displayed by the client information processing apparatus 110 having no decryption program. Can be prevented.

FIG. 21 is a diagram showing a processing flow of the HTML file encryption program for performing the above HTML file encryption. In step 2101, the designated plaintext HTML file 2201 is opened, and in step 2102, a temporary file with a temporary name is created.
At step 2104, the specified destination list 41 is given to the group encryption program 28 of the IC card 130 to generate a group key. Step 2
At 105, the retry counter is initialized, and step 21
At 06, the execution key 41 which is a random number is generated. In step 2107, the header 505 is written at the head of the temporary file. In step 2109, the reader portion 2402 is transferred to the header 505 of the temporary file.
Write in the continuation of. In step 2110, data is read from the plaintext HTML file 2201, and in step 2111 the data is encrypted. Step 211
In step 2, it is checked whether or not the comment end character string "->" is present in the encrypted data, and if there is, the steps from step 2131 and thereafter are executed. Write later data. In step 2114, the plain text HTML file 22
It is judged whether the encryption of all data of 01 is completed,
Until the end, the steps 2110, 2111, 211
Control is performed so that steps 2 and 2113 are repeatedly executed. In step 2115, the footer portion 2404 is written in the temporary file, and in step 2116, the plain text H
Both the TML file 2201 and the temporary file are closed. In step 2117, it is judged whether or not the designated plain text HTML file name and the encrypted HTML file name are the same, and if they are the same, the plain text HTML file 2201 is deleted in step 2118. In step 2119, the file name of the temporary file is changed to the specified encrypted HTML file name,
Exit this program. On the other hand, the step 2112
If it is determined that the end character string "->" of the comment is included in the encrypted data in step 2, step 2
At 131, the contents written in the temporary file are cleared. Next, in step 2132, the retry counter is counted up, and in step 2133, it is checked whether the retry counter exceeds the preset upper limit value (10 times in this embodiment). The portion from 2106 is executed again. In this re-execution, since the random number different from the previous time is used as the execution key 61 in the step 2106, the probability that the end character string “—>” of the comment appears again in the encryption in the step 2111 is considerably low. Nevertheless, if the upper limit is exceeded, both the plaintext HTML file 2201 and the temporary file are closed in step 2134. Further, the temporary file is deleted in step 2115, an error message is displayed in step 2136, and the program ends. Since the encrypted data has a random value, the probability that the end character string "->" of the comment will appear is that one character is 1 byte (=
Since it is represented by 8 bits, it is 1 / (the cube of (2 8)), that is, 1 / 677,216. In other words, it occurs only once for about 16 Mbytes of data. Therefore, if the control for changing the execution key 61 and retrying is incorporated as described above, there is no problem in practical use. Further, as another means for preventing the end character string “—>” of the comment from appearing in the main body portion 2403, the encrypted data can be stored as a text character string in hexadecimal display.

FIG. 26 shows an encrypted HTML file created by this method. However, in this method, two characters, that is, two bytes are required to represent one-byte data, and there is a problem that the data amount is doubled.

In the present embodiment, the document file described in HTML has been described, but the present invention can be similarly applied to any grammar having a format for describing a comment sentence that is ignored during interpretation. Is clear.

[0056]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment in which the present invention is applied to the Internet will be described below with reference to the drawings. First, the overall system configuration will be described. FIG. 1 is a configuration example of an encrypted file receiving system and a control method thereof according to the present invention. 110 is a client information processing device, and 120 is a server information processing device.

The server information processing device 120 includes a central processing unit (CPU) 1b, a memory 2b, a LAN controller 3b, a disk controller 4b, and a magnetic disk 5b. When the server information processing device 120 is started, the operating system (OS) 20b and the WW
The W (World-Wide Web) server program 26 and the shared file encryption program 21b are loaded from the magnetic disk 5b onto the memory 2b via the disk controller 4b. The client information processing device 110 includes a CPU 1a, a memory 2a, a LAN controller 3a, a disk controller 4a, a magnetic disk 5a, and an IC card controller 6, respectively. When the client information processing device 110 is started,
OS 20a, shared file encryption program 21a, communication API (Application Program In)
interface) hook program 27 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a. The browser program 19 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a according to an instruction from a user of the client information processing apparatus 110 (hereinafter simply referred to as a user). Communication A
The PI hook program 27 is the browser program 19
Hooks the communication API issued to the OS 20a, and automatically decrypts the received file data in the background.

The server information processing device 120 and the client information processing device 110 are connected to each other via a local area network (LAN) 101, and communicate with each other via each LAN controller 3.
The server information processing device 120 and the client information processing device 110 may be located at remote locations from each other, and may be connected via a telephone line or a dedicated line.

In FIG. 28, one client information processing device 110 is shown, but in reality, a plurality of client information processing devices 110 having the same configuration are connected to the LAN 101, and these client information processing devices 110 are connected to each other. , HTML files and image data files stored in the magnetic disk 5b of the server information processing device 120 are shared. The user accesses the file on the magnetic disk 5b using the browser program 19 to perform the sharing. In addition, the HTML
The file or image data file may be created on the server information processing device 120 and stored on the magnetic disk 5b, or may be created on the client information processing device 110 and then stored on the magnetic disk 5b. . Further, the IC card 130 of the client information processing apparatus 110 can be attached / detached. The IC card 130 includes a CPU 1c, a non-volatile memory 7, and an input / output interface 8. The non-volatile memory 7 includes an access control program 30, a group encryption program 28, ID information 29,
The master key 31 is written. The contents of the non-volatile memory 7 can be externally accessed via the input / output interface 8. However, in order to protect the contents stored in the nonvolatile memory 7 from unauthorized access,
The user authentication control by the CPU 1c is necessarily interposed.

FIG. 29 is a diagram showing a program routine constituting the shared file encryption program 21 and the communication API hook program 27. The shared file encryption program 21 includes a login control routine 100 for logging in and out of the IC card 130.
0, a logout control routine 1100, a manual file encryption routine 2000 in which a user explicitly instructs and encrypts a file each time, and the manual file encryption is performed by HTML (Hyper Text Markup).
It is composed of an HTML file encryption routine 2100 arranged for a shared file described in the Language). The communication API hook program 27
Is composed of a send hook routine 1800, a recv hook routine 1810, and a close socket hook routine 1820.

The contents of the ID information 29 are the same as the ID information 29 shown in FIG. 2 in the first embodiment. Here, up to 10 sets of data indicating the contents of each category and their codes can be registered. What is actually stored in the nonvolatile memory 7 is only the data and code values.

Next, the operation of the group encryption program 28 will be described below.
And the procedure for calculating the hash value of the destination list and creating the group key 51 are the same as the procedure shown in FIG. 3 in the embodiment. The IC card 130
The processing content of the group encryption program 28 in the above is the same as the flow chart shown in FIG. 4 in the embodiment. By encrypting the data using the group key 51 described above, only the person having the ID information 29 included in the destination list 41 can decrypt the data.

Next, an example in which the above-mentioned group cipher is applied to the cipher of a file will be described. FIG. 30 is a diagram showing a file encryption procedure and a file structure after encryption. The content of the header 505 of the encrypted file 502 is different from the example shown in FIG. That is, 501
Is a plaintext file before encryption, and 502 is an encrypted file after encryption. 61 is an effective key generated as a random number, and 504 is the file 5 using the effective key 61 as a key.
The ciphertext data obtained by encrypting the contents of 01, 505 is a header added to the ciphertext data 504, 506 to 511 are the contents of the header 505, 506 is a character string indicating the encryption method used, and 509 is the effective An encrypted effective key 511 obtained by encrypting the key 61 with the group key 51, an encrypted destination list 511 obtained by encrypting the destination list 41 with the master key 31, and a size 510 of the encrypted destination list 511. The cipher file 502 can be decrypted by a procedure completely opposite to the above procedure as shown in FIG.

In the above file encryption, the group key 51 is used to encrypt the effective key 61,
The effective key 61 was used to encrypt the file data.
Therefore, when changing the destination list 41,
First, the effective key 61 may be decrypted by the group key 51 generated by the destination list 41 before the change, and then re-encrypted by the group key 51 generated by the destination list 41 after the change. As a result, even when the destination list 41 is changed, re-encryption of the file data having a larger data amount than the effective key 61 can be eliminated, and the change process can be performed at high speed.

Next, the login processing routine 1000 and the logout processing routine 1100 in the shared file encryption program 21 will be described. The IC card 130
The processing flow of the login processing routine 1000 for login is the same as that of the login processing routine 1000 in the first embodiment shown in FIG. 10, and detailed description thereof will be omitted. By periodically checking the connection of the IC card 130 using a timer event, the logout process when the IC card 130 is removed can be automated.

The processing flow of the logout processing routine 1100 from the IC card 130 is the same as that of the logout processing routine 1100 in the first embodiment shown in FIG. 11, and detailed description thereof will be omitted.

FIG. 32 is a diagram showing a data input / output method in file encryption / decryption of this embodiment. The ciphertext data 504 of the ciphertext file 502 is read / written with the ciphertext block buffer 82 in units of the size of the ciphertext block buffer 82. The data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. The data in the plaintext block buffer 81 is encrypted and transferred to the ciphertext block buffer 82. This input / output method is different from the input / output method shown in FIG. 18 in that the buffer length is shown from 1024 bytes to 256 bytes.

Next, the shared file encryption program 2
The manual file encryption routine 2000 included in 1 will be described. This routine operates by inputting the file name of the plaintext file to be encrypted, the encrypted file name after encryption, and the destination list 41. This process is substantially the same as the file encryption routine 2000 shown in FIG. 20, and detailed description thereof will be omitted.

Next, an embodiment for encrypting an HTML file will be described. Also in this embodiment, the plain text HTML file, the display on the browser, the encrypted HTML file, and the like are the same as those in the first embodiment shown in FIGS.

HT for performing the above HTML file encryption
The processing flow of the ML file encryption program is the first embodiment.
21 is the same as the processing flow shown in FIG. 21, and detailed description thereof will be omitted. The encrypted HTML file created by this method is the same as that shown in FIG. The file that has been subjected to the above-described encryption processing is stored in the magnetic disk 5b of the server information processing apparatus by the information provider.

Next, the browser program 19
The processing of the communication API hook program 27 when receiving the encrypted file from the WW server program 26 will be described. First, input / output of received file data and a management method thereof will be described. FIG. 33 is a diagram showing data input / output at the time of decrypting a received file in the present embodiment.
Reference numeral 83 is a ciphertext reception buffer prepared by the browser program 19 and contains a ciphertext. The communication API hook module processes the received ciphertext in the ciphertext block buffer 82 in the recv hook process described later.
Copy to At this time, the ciphertext block buffer 82
If is satisfied, the decryption processing of the ciphertext is executed and the plaintext is copied to the plaintext block buffer 81. Further, in order to pass the plaintext to the browser 23, the content of the plaintext block buffer 81 is overwritten and copied to the ciphertext reception buffer. When the ciphertext copied from the ciphertext reception buffer 83 to the ciphertext block buffer 82 does not fill the ciphertext block buffer 82, the decryption processing is not performed and the next reception file data is waited for. After that, the ciphertext block buffer 82 of the received ciphertext file data
Copy to, decryption process and plaintext block buffer 8
The copy to 1 and the plaintext copy to the ciphertext reception buffer 83 are repeated until there is no received cipher file data.

FIG. 34 shows a socket information table 91 for managing open sockets. The socket information table 91 includes a socket descriptor 1912, a reception flag 1913, a reception data pointer 1914, an encrypted effective key 509, an encrypted destination list size 510, an encrypted destination list 511, a group key 51, an effective key 61, and a ciphertext. Each information of the block buffer pointer 1915 and the plaintext block buffer pointer 1916 is stored in a list structure by using the pointer 1901 for each open socket. Here, the socket descriptor 1912 is a management number given by the OS 20 when the socket is opened. The reception flag 1913 is "0" when the data of the encrypted file has never been received using the socket descriptor 1912, and the data of the encrypted file is 1
This flag is set to "1" when received more than once. The received data pointer 1914 indicates the starting point when reading a ciphertext from the received file data,
A recv hook routine 1810, which will be described later, registers the start address of the reception buffer when receiving data. The ciphertext block buffer pointer 1915 and the plaintext block buffer pointer 1916 are pointers to the ciphertext block buffer 82 and the plaintext block buffer 81 in FIG. 33, respectively, and are used when a ciphertext or a plaintext is copied between the buffers during decryption processing. It is the starting point. Also,
The encrypted effective key 509, the encrypted destination list size 510, and the encrypted destination list 511 are read from the header 505 and registered when the encrypted file is received. The encrypted destination list 511 is decrypted by the master key as shown in FIG. Further, the group key 51 is generated from the destination list 41, and the encrypted effective key 509 is decrypted by the group key 51 to obtain the effective key 6
1 is obtained and registered in the socket information table 91, respectively.

Next, the communication API hook program 2
The processing of each routine in 7 will be described. FIG. 35 shows
FIG. 14 is a diagram showing a processing flow of the send hook routine 1800. First, in step 1801, it is checked whether or not the file acquisition command “GET” is present in the data transmitted by the browser program 19 to the WWW server program 26. If there is, in step 1804, the socket information table 91 is referred to to check whether the descriptor of the hooked socket is registered. If registered, in step 1806, the reception flag 1913 of the corresponding socket information is set to "0", and the send process of step 1807 is performed. If not registered, the socket information is registered in the table 90 in step 1805. If the file acquisition command does not exist in the transmission data in step 1801, it is checked in step 1802 whether or not the descriptor of the hooked socket is registered in the socket information table. If registered, the corresponding socket information is deleted in step 1803. If not registered, step 1807
Executes send processing. Next, in step 1808, an error in the send process occurs, and
If the corresponding socket information is already registered in the table in step 1810, the corresponding socket information is deleted from the socket information table 91 in step 1810, and
Returns to the browser program 19. If no error occurs in step 1808, the process returns to the browser program 19 in step 1811 without doing anything.

FIG. 36 shows the recv hook routine 182.
FIG. 7 is a diagram showing a processing flow of 0. First, step 182
In step 1, the recv process called by the browser program 19 is processed, and in step 1822, an error check of the recv process is performed. If an error occurs at this time, the error is returned to the browser program 19 in step 1835. Since a message about the error is displayed by the browser program 19, rec
The vhook routine 1810 need not display an error message. If there is no error, step 1823
To check whether the socket descriptor has already been registered in the socket information table 91. Here, the socket descriptor registered in the socket information table 91 in the send hook routine is the H descriptor managed by the WWW server 26.
Refers to the socket used to receive TML files and image data files. Therefore, the socket information table 9
If it is already registered in step 1, it is checked in step 1824 whether or not there is received data. If not registered, the received data is returned to the browser program 19 in step 1835. If the received data does not exist in step 1824, it means that the reception of the data is completed.
The corresponding socket information is stored in the socket information table 91.
, And returns to the browser program 19 in step 1835. If there is received data,
In step 1825, the recv flag is checked. If the recv flag is “0”, it is determined that the received data is the first received data for the send process, and the received data is checked in step 1826. Step 1
If the received data is a file encrypted by the encryption method of the present invention at 827, it is checked at step 1828 whether there is a logged-in user. If it does not exist, the message 1837 is displayed in step 1838. If it exists, it is checked in step 1829 whether the destination user list includes the login user. If the login user is included, the recv flag is set to “1” in step 1830,
In step 1832, the received file data is decrypted. On the other hand, if the login user is not included in the destination list, the message 1 is sent in step 1831.
836 is displayed, the socket information is deleted from the socket information table 91 in step 1834, and the process returns. On the other hand, if the received file data is not encrypted in step 1827, the socket information is deleted from the socket information table in step 1834 and the process returns.

FIG. 37 is a diagram showing the processing flow of the closesocket hook routine 1840. First, in step 1841, it is checked whether or not the socket descriptor specified in the argument of the closesocket function called by the browser program 19 is registered in the socket information table 91. If registered, the socket information corresponding to the socket descriptor is deleted from the table 90 in step 1842, and cl in step 1843
It executes an ossocket process and returns to the browser program 19 (step 1844). on the other hand,
If it is not registered in the socket information table,
The process executes the closesocket process of step 1843 and returns.

By the processing of each routine of the communication API hook program 27 described above, the decryption of a desired page can be realized transparently from the browser program 19.

Next, an example of an actual WWW operation system in this embodiment will be described with reference to FIG. 1
Reference numeral 40 is a proxy server information processing device, and by the proxy server program 18, the client information processing device 1
10 relays data transmitted and received between the server 10 and the server information processing apparatus 120. The proxy server program 18
Is an HTM transmitted by the server information processing apparatus 120 in response to a request from the client information processing apparatus 110.
It has a function of caching L files and image data files in the magnetic disk 5c via the disk controller 4c. Thereafter, when a file transfer request is issued from the client information processing apparatus 110, if the file is cached in the magnetic disk 5c,
The proxy server program 18 transfers the cache file to the client information processing device 110. In this embodiment, all files related to confidential information are encrypted and stored in the magnetic disk 5b of the server information processing apparatus 120. Therefore, all confidential information cached in the magnetic disk 5c at the time of file transfer becomes an encrypted file.

[0078]

As described above, according to the present invention, when a file is encrypted, a group encryption that adds a list of users who are permitted to decrypt to the file is used. Therefore, even when a plurality of users use the same file, There is an effect that only one encrypted file is required and it is safe.

Further, since the directory to be encrypted and the destination list of users who are allowed to decrypt can be set for each user, a plurality of users share the directory and files in the directory are filed using different destination lists. There is an effect that encryption can be performed.

Further, according to the present invention, in data encryption of a plaintext file described in accordance with a grammar that an application program interprets and processes, a description for making an annotation sentence to be ignored as a processing target when the application program is processed in the grammar is described. Since the child is added to the encrypted data and stored as an encrypted file, abnormal operation may occur even when the encrypted file is read by an information processing device that does not have a decryption program compatible with the encryption system. There is an effect that there is no.

Further, according to the present invention, the hook means for hooking the file operation request issued from the application program to the OS is provided, and the encryption or decryption is automatically performed when the file operation request is issued. It has the effect of never forgetting.

Further, according to the present invention, since the WWW server manages the files encrypted in advance, there is an effect that confidential information is not leaked even if the server information processing apparatus having the WWW server program is directly accessed. Further, according to the present invention, since the WWW server manages a file encrypted in advance, the confidential information cached by the proxy server at the time of transferring the file is also an encrypted file, so that the proxy server information processing device is confidential even if directly accessed. The effect is that information is not leaked.

Further, according to the present invention, the hook means for hooking the communication API call issued from the browser program to the communication module is provided, and the decoding is automatically performed when the data reception API is called. The operation is unnecessary.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration example of a shared file encryption system according to an embodiment of the present invention.

FIG. 2 is a diagram showing an example of contents of ID information 29 in the embodiment of the present invention.

FIG. 3 is a diagram showing an example of a procedure for calculating a hash value of a destination list and creating the group key 51 in the embodiment of the present invention.

FIG. 4 is a flowchart showing the processing contents of the group encryption program 28 in the IC card 130 according to the embodiment of the present invention.

FIG. 5 is a diagram showing a file encryption procedure and a file structure after encryption according to an embodiment of the present invention.

FIG. 6 is a diagram showing a file decoding procedure according to an embodiment of the present invention.

FIG. 7 is a diagram showing a logical directory structure viewed from a user according to an embodiment of the present invention.

FIG. 8 is a diagram showing a physical directory structure after automatic file encryption and decryption is introduced in an embodiment of the present invention.

FIG. 9 is a diagram showing an example of the contents of a destination list file 901 and the encrypted file information file 902 according to an embodiment of the present invention.

FIG. 10 is an IC card 130 according to an embodiment of the present invention.
FIG. 10 is a diagram showing the processing flow of a login processing routine 1000 for login to the.

FIG. 11 is an IC card 130 according to an embodiment of the present invention.
FIG. 13 is a diagram showing a processing flow of a logout processing routine 1100 from FIG.

FIG. 12 is a diagram showing a processing flow of a file open hook routine 1200 according to an embodiment of the present invention.

FIG. 13 is a diagram showing a processing flow of a file create hook routine 1300 according to an embodiment of the present invention.

FIG. 14 is a diagram showing a processing flow of a lead hook routine 1400 according to an embodiment of the present invention.

FIG. 15 is a diagram showing a processing flow of a light hook routine 1500 according to an embodiment of the present invention.

FIG. 16 is a diagram showing a processing flow of a close hook routine 1600 according to an embodiment of the present invention.

FIG. 17 is a diagram showing a processing flow of a file rename hook routine 1700 according to an embodiment of the present invention.

FIG. 18 illustrates an example of file encryption and encryption according to an embodiment of the present invention.
The figure which shows the input-output method of the data at the time of decoding.

FIG. 19 is a file handle table 9 for managing open encrypted files according to an embodiment of the present invention.
FIG.

FIG. 20 is a diagram showing an example of a processing flow of a manual file encryption routine 2000 according to an embodiment of the present invention.

FIG. 21 is a diagram showing a directory structure of the first server information processing device 120 according to the first embodiment of the present invention.

FIG. 22 is a diagram showing an example of a plaintext HTML file according to an embodiment of the present invention.

FIG. 23 is a diagram showing an example of a screen in which a plaintext HTML file is displayed on a browser in an embodiment of the present invention.

FIG. 24 shows an encrypted HTM in one embodiment of the present invention.
The figure which shows an example of an L file.

FIG. 25 is a diagram showing an example of a screen in which a plaintext HTML file encrypted in a working example of the present invention is displayed by a browser.

FIG. 26 shows an encrypted HTM in one embodiment of the present invention.
The figure which shows the other example of L file.

FIG. 27 is a diagram showing a program routine that constitutes the shared file encryption program 21 and the file I / O hook program 22 in the first embodiment of the present invention.

FIG. 28 is a diagram showing a configuration example of an encrypted file receiving system according to an embodiment of the present invention.

FIG. 29 is the shared file encryption program 21 and the communication API hook program 2 according to the embodiment of the present invention.
The figure which shows the program routine which comprises 7.

FIG. 30 is a diagram showing a file encryption procedure and a file structure after encryption according to an embodiment of the present invention.

FIG. 31 is a diagram showing a file decoding procedure according to an embodiment of the present invention.

FIG. 32 is a diagram illustrating a file encryption according to an embodiment of the present invention.
The figure which shows the input-output method of the data at the time of decoding.

FIG. 33 is a diagram showing an input / output method of data at the time of decrypting a received file in one embodiment of the present invention.

FIG. 34 is a diagram showing a configuration of a socket information table 91 for managing socket information during opening according to an embodiment of the present invention.

FIG. 35 is a diagram showing a processing flow of a send hook routine 1800 according to an embodiment of the present invention.

FIG. 36 is a diagram showing a processing flow of a recv hook routine 1820 in the embodiment of the present invention.

FIG. 37: closesoc in one embodiment of the present invention
The figure which shows the processing flow of the ket hook routine 1840.

FIG. 38 is a diagram showing an example of the configuration of a system that operates an actual WWW in the embodiment of the present invention.

[Explanation of symbols]

 1 CPU 2 Memory 3 LAN Controller 4 Disk Controller 5 Magnetic Disk 6 IC Card Controller 7 Nonvolatile Memory 8 Input / Output Interface 19 Browser Program 18 Proxy Server Program 20 OS 21 Shared File Encryption Program 22 File I / O Hook Program 23 Application Program 24 Client Program 25 File server program 26 WWW server program 27 Communication API hook program 28 Group encryption program 29 ID information 30 Access control program 31 Master key 32 Hash function 101 LAN 110 Client information processing device 120 Server information processing device 130 IC card 140 Proxy server information Processor

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Hisashi Umeki 1099, Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Ltd. System Development Laboratory, Hitachi, Ltd. (72) Inventor, Yutaka Otsu 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa In-house company Hitachi Ltd., Software Development Headquarters (72) Inventor Hajime Morito 1099 Ozenji, Aso-ku, Kawasaki City, Kanagawa Prefecture In-house Hitachi Systems Development Laboratory (72) Inventor Mayuko Shimizu 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Hitachi, Ltd. Software Development Division

Claims (39)

[Claims] 1. An operating system (OS) having at least an input / output control function for a file, and a storage device for storing the file or a file storage means in a storage device on a second information processing device connected by a network. In a file encryption system including an information processing device including: an encrypted directory storage unit that presets a directory to be encrypted and stores the file in a file; and a file in the directory from an application program operating on the OS. A file encryption system comprising: an encryption means for encrypting write data to the file. 2. The file encryption according to claim 1, wherein the encryption directory storage means can set a plurality of independent encryption target directories for each user who uses the information processing apparatus. system. 3. The file encryption system according to claim 1, wherein the encrypted directory storage means stores a list of users who can be decrypted for each target directory. 4. The file encryption system according to claim 3, wherein a file storing a list of the users is created in the target directory for each target directory. 5. The file encryption according to claim 1, wherein said encryption means encrypts write data to the file when the directory has a file indicating that the directory is an encryption target directory. system. 6. The file encryption system according to claim 3, wherein the list of users is encrypted and stored. 7. The file according to claim 1, wherein a logical file name viewed from the application program and a physical file name stored by the encryption means are different. Encryption system. 8. An operating system (OS) having at least a file input / output control function, and a file storage means for storing the file in a storage device or a storage device on a second information processing device connected by a network. In a file encryption system including an information processing apparatus including: an encryption directory storage unit that presets a directory to be encrypted and stores the file in a file; and encryption of write data from an application program to a file in the directory. A file encryption system comprising: an encryption / decryption means for performing encryption and decryption of read data. 9. The encryption / decryption means comprises a plaintext block buffer and a ciphertext block buffer having a size independent of the size of writing or reading a file from an application program, and the encryption and decryption processing is performed by the above 9. The file encryption system according to claim 8, which is performed by processing all the data on the block buffer at a time. 10. The method according to claim 1, wherein the encryption means or the decryption means is called by hook means for hooking a file operation request issued to the OS from the application program. Or described file encryption system. 11. The encryption means uses a numerical value created by compressing a character string of a list of users who are permitted to decrypt with a hash function as an encryption key. 10. The file encryption system according to any one of 10. 12. The encryption means encrypts an encryption key with a numerical value created by compressing a character string of a list of users permitted to decrypt with a hash function,
11. The file encryption system according to claim 1, wherein the encryption key is added to an encrypted file. 13. An operating system (OS) having at least an input / output control function for a file, and a storage device for storing the file or a file storage means in a storage device on a second information processing device connected by a network. And a file encryption system comprising an information processing device comprising a file encryption means for encrypting the file, wherein the file encryption means is a plaintext written in accordance with a grammar interpreted and processed by an application program. When encrypting the data of the file, a descriptor for adding an annotation text to the annotation data to be ignored as a processing target when processing the application program in the grammar is added to the encrypted data and stored. Control method. 14. The control of the file encryption system according to claim 13, wherein an encryption key is selected and used such that a descriptor indicating the end of the annotation text does not exist in the encrypted data. Method. 15. A descriptive text for displaying by the application program that a file is a ciphertext file is added and stored before or after the annotation text including the encrypted data. The method for controlling the file encryption system according to claim 13 or 14. 16. An operating system (OS) having at least a file input / output control function, and a file storage means in a storage device for storing the file or a storage device on a second information processing device connected by a network. And a file decryption means for decrypting a file stored in the storage device, the method of controlling a file encryption system comprising an information processing device, wherein the file decryption means is interpreted and processed by an application program. At the time of decrypting the data of the encrypted file described according to the grammar, the data portion which is the annotation sentence is decrypted by the descriptor for the annotation sentence to be ignored as the processing target when the application program is processed in the grammar, and the decryption is performed. The data after is the plaintext file data before encryption. A method for controlling a file encryption system, which is characterized by storing as a file. 17. The encryption unit or the decryption unit is called by a hook unit that hooks a file operation request issued to the OS from the application program. Or the control method of the file encryption system described above. 18. The encryption means uses a numerical value created by compressing a character string of a list of users who are permitted to decrypt by a hash function as an encryption key. 18. The method for controlling the file encryption system according to any one of 17. 19. The encryption means encrypts an encryption key with a numerical value created by compressing a character string of a list of users who are allowed to decrypt with a hash function,
18. The method for controlling a file encryption system according to claim 13, wherein the encryption key is added to an encrypted file. 20. An operating system (O) having at least a communication control function and a file input / output control function.
S), a first information processing device including a storage device that stores the file, an operating system (OS) that is connected to the first information processing device via a network, and has at least a communication control function, A cryptographic file receiving system configured by a second information processing device, which includes an application program that operates on the OS and has a function of receiving a file from a storage device on the first information processing device, One information processing device has a file encryption means for encrypting the file, and the second information processing device has the application program encrypted from the first information processing device by the file encryption means. When the encrypted file is received, the received file is decrypted before the application program Cryptographic file receiving system characterized by having a reception file decoding means to pass. 21. The received file decryption means receives and decrypts a file in which the list of users who can be decrypted is added to the encrypted file by the file encryption means. Encrypted file receiving system. 22. The encrypted file receiving system according to claim 20, wherein the received file decryption means is called by hook means for hooking a data transmission / reception request issued by the application program to the OS. . 23. The hook means calls the received file decryption means only when there is a user authenticated by the user authentication means for confirming the identity of the user of the second information processing apparatus. 23. The encrypted file receiving system according to claim 20. 24. The reception file decryption unit has a decryption right by a decryption right determination unit that determines whether the user authenticated by the user authentication unit is included in the list of decryptable users. 24. The encrypted file receiving system according to claim 20, wherein the encrypted file receiving system is called only when it is determined to be. 25. The encrypted file receiving system according to claim 20, wherein the encrypted file is received by decrypting a file obtained by encrypting and adding a list of decryptable users. 26. The storage device on the first information processing device stores a file encrypted in advance by the file encryption means.
The encrypted file receiving system according to any one of claims 0 to 25. 27. The hook means processes only a received file for a file transfer request command transmitted to the first information processing apparatus by the application program, as a decoding target.
The encrypted file receiving system according to any one of claims 0 to 25. 28. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. A second operating system (OS) having at least a communication control function, and an application program operating on the OS and having a function of receiving the encrypted file from the storage device on the first information processing apparatus In the encrypted file receiving system configured by the information processing device, the file encryption means, during data encryption of a plaintext file described according to a grammar interpreted and processed by the application program, at the time of processing the application program in the grammar. Descriptor to be an annotation sentence to be ignored as non-processing target The encrypted data is added to the encrypted file, and when the application program receives the encrypted file, only the data part in which the descriptor is added to form the comment text is extracted. An encrypted file receiving system comprising a received file decoding means for decoding. 29. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. Data to be transmitted to the first information processing device by the second information processing device, which is connected to the second information processing device having at least an operating system (OS) having a communication control function via the network, On the contrary, the second information processing apparatus is composed of a third information processing apparatus having a function of relaying data received from the first information processing apparatus and a cache function of caching the received data. In the encrypted file receiving system, when the second information processing device issues a transfer request for the encrypted file, the encrypted file receives the first information processing. From the storage device to the second information processing device via the third information processing device, the encrypted file is cached by the cache function, and the second information processing device again stores the same encrypted file. Is transmitted, the encrypted file cached by the cache function is transferred from the third information processing device to the second information processing device. 30. An operating system (O) having at least a communication control function and a file input / output control function.
S), a first information processing device including a storage device that stores the file, an operating system (OS) that is connected to the first information processing device via a network, and has at least a communication control function, A control method for a cryptographic file receiving system configured by a second information processing apparatus, comprising: an application program that operates on the OS and has a function of receiving a file from a storage device on the first information processing apparatus. When the application program receives the encrypted file from the first information processing device, the received file is decrypted and then passed to the application program. . 31. The encrypted file according to claim 30, wherein the file encryption means receives and decrypts a file in which a list of decryptable users is added to the encrypted file. Receiving system control method. 32. The control method of an encrypted file receiving system according to claim 30, wherein the received file decryption means is called by hook means for hooking a data transmission / reception request issued by the application program to the OS. 33. The hook means calls the received file decryption means only when there is a user authenticated by the user authentication means for confirming the identity of the user of the second information processing apparatus. 33. The control method of the encrypted file receiving system according to claim 30. 34. The decryption right discriminating means for discriminating whether or not the user authenticated by the user authenticating means is included in the decryptable user list has the decryption right for the received file decrypting means. 31. Calling only when it is determined that
34. The control method of the encrypted file receiving system according to claim 33. 35. The control method of the encrypted file receiving system according to claim 30, wherein a file obtained by encrypting and adding a list of decryptable users to the encrypted file is received and decrypted. 36. The storage device on the first information processing device stores a file encrypted in advance by the file encryption means. Control method of encrypted file receiving system. 37. The hook means processes only a received file for a file transfer request command transmitted to the first information processing apparatus by the application program, as a decryption target.
A control method for the encrypted file receiving system according to any one of claims 0 to 35. 38. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. A second operating system (OS) having at least a communication control function, and an application program operating on the OS and having a function of receiving the encrypted file from the storage device on the first information processing apparatus In the control method of the encrypted file receiving system configured by the information processing apparatus, the file encryption means, in the data encryption of the plaintext file described according to the grammar interpreted and processed by the application program, the application in the grammar. Because it is a comment statement that is ignored as a processing target during program processing A descriptor is added to the encrypted data as an encrypted file, and when the application program receives the encrypted file, only the data part to which the descriptor is added and which is a comment text is extracted. A method for controlling an encrypted file receiving system characterized by decrypting. 39. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. Data to be transmitted to the first information processing device by the second information processing device, which is connected to the second information processing device having at least an operating system (OS) having a communication control function via the network, On the contrary, the second information processing apparatus is composed of a third information processing apparatus having a function of relaying data received from the first information processing apparatus and a cache function of caching the received data. In the control device of the encrypted file receiving system, when the second information processing device issues a transfer request for the encrypted file, the encrypted file is transferred to the first information device. While being transferred from the processing device to the second information processing device via the third information processing device, the cipher file is cached by the cache function, and the second information processing device again uses the same encryption. A method of controlling a cryptographic file receiving system, comprising: transmitting a cryptographic file cached by the cache function from the third information processing device to the second information processing device when a file transfer request is issued.