JP5494171B2 - File management system, storage server, client, file management method and program - Google Patents

Description

  The present invention relates to a file management system, a storage server, a client, a file management method, and a program, and more particularly, to a file management system, a storage server, a client, a file management method, and a program that manage files by encryption.

  There is a need for a file management system that allows access from a certain user to files on the storage and can be used for information sharing and task sharing. For example, a service that provides a storage service directly or indirectly to a user belonging to a different organization via a network may be used. Also, using this type of file management system, recommendations can be created and provided based on correlation analysis and trend analysis of data among multiple users, HSM (Hierarchical Storage Management), ILM (Information Lifecycle Management), and data It is also known to perform compression and deduplication. In this type of file management system, it is desirable to control each user to access a file according to the authority without risking the key or data itself used for file encryption.

  Patent Document 1 uses a common key encryption method and a public key encryption method to search and transmit a file storage unit for storing a file encrypted with a user private key and a file access request from a user. File management system comprising: a shared file server comprising a file transmission unit for performing encryption; and a cipher management server comprising a client private key storage unit for encrypting the user private key with a user public key and storing the encrypted user private key in association with the user ID and file ID Is disclosed.

  Also, in Patent Document 2, by embedding a plurality of key information in the header portion of the encrypted file, even when certain key information is incorrect, it can be decrypted using different key information, A security system is disclosed in which only the user having the group key can decrypt the file by creating and distributing the key information.

  Further, in Non-Patent Document 1, the key used for file encryption (the content key in FIG. 8 of the same document) is encrypted so that only a user having access rights can safely extract it, and then added to the file. Describes an example of a method for realizing file sharing.

JP 2005-209181 A JP 2000-99385 A

Microsoft, “Information Protection with RMS and IRM”, Technical White Paper, March 18, 2004, [online], [Search March 29, 2010], Internet <URL: http://technet.microsoft.com /ja-jp/library/CC984234.aspx>

  However, each of the technologies described in the above-mentioned patent documents and non-patent documents discloses that when a user's confidential information (file encryption key or decryption key of an encrypted file encryption key) leaks, unauthorized access using the user's confidential information There is a problem that it is difficult to block. For example, in the case of Patent Document 1, a client secret key (RSA secret key) for decrypting a user secret key (user DES key) used for file encryption is assumed not to leak. When the access request to the file from the client is accepted, the user secret key (user DES key) encrypted with the user public key (RSA public key) and the encrypted file are transmitted to the client. If the user secret key (RSA secret key) is leaked, there is a possibility that another file accessible by the user is accessed.

  Similarly, since the techniques of Patent Document 2 and Non-Patent Document 1 are designed on the assumption that the confidential information of the user will not leak, the confidential information (user information, password, etc. of Patent Document 2) There is a possibility that the key (session key, content key) attached to the encrypted file is obtained using the user secret key (Non-Patent Document 1), and the plaintext or content in the encrypted file is accessed. .

  In addition to the case where the user's secret information (secret key used as a decryption key for the user's password or file encryption key) is leaked, the above-mentioned problem is caused by personnel changes, retirement, Alternatively, it may occur in the case of withdrawal of a user from various services described at the beginning or a service change. On the other hand, it is not practical to re-encrypt the encrypted file itself with another encryption key each time.

  The present invention has been made in view of the above circumstances, and the purpose of the present invention is when the above-described user secret information (secret key used as a user key or a decryption key of a file encryption key) leaks. Even so, it is to provide a file management system, a storage server, a client, a file management method and a program capable of taking countermeasures as soon as possible and suppressing unauthorized access using the confidential information of the user. .

  According to the first aspect of the present invention, an encrypted file storage unit for storing a file encrypted using a predetermined file encryption key (FEK) and an access right to the file are provided. A storage comprising: an encrypted file encryption key storage unit for storing an encrypted file encryption key (E-FEK) obtained by encrypting the file encryption key (FEK) using a public key determined for each user or service A server, a decryption processing unit for decrypting the encrypted file encryption key (E-FEK) received from the storage server with a secret key corresponding to the public key, and a file using the decrypted file encryption key (FEK) An encryption / decryption processing unit that encrypts / decrypts the storage server, and a storage instance After confirming the validity of the public key defined for each user or service having access rights to the file, the server pays an encrypted file encryption key (E-FEK) to the client or service instance. A file management system is provided.

  According to a second aspect of the present invention, a decryption processing unit that decrypts an encrypted file encryption key (E-FEK) received from a storage server with a secret key, and the decrypted file encryption key ( A client or a service instance including an encryption / decryption processing unit that encrypts / decrypts a file using FEK (File Encryption Key), and an encryption that stores a file encrypted using a file encryption key (FEK). An encrypted file encryption key (E-FEK) obtained by encrypting the file encryption key (FEK) is stored using a file storage unit and a public key defined for each user or service having access rights to the file. And an encrypted file encryption key storage unit. Provided is a storage server that confirms the validity of a public key defined for each user or service having access rights and then issues an encrypted file encryption key (E-FEK) to the client or service instance. .

  According to a third aspect of the present invention, a decryption processing unit that decrypts an encrypted file encryption key (E-FEK) received from the storage server with a secret key, and the decrypted file encryption A client or a service instance is provided that includes an encryption / decryption processing unit that encrypts / decrypts a file using a key (FEK; File Encryption Key).

  According to the fourth aspect of the present invention, an encrypted file storage unit for storing a file encrypted using a predetermined file encryption key (FEK) and an access right to the file are provided. A storage comprising: an encrypted file encryption key storage unit for storing an encrypted file encryption key (E-FEK) obtained by encrypting the file encryption key (FEK) using a public key determined for each user or service In response to a request from the client or service instance, the server confirms the validity of the public key defined for each user or service that has access to the file, and then encrypts the client or service instance. An encrypted file encryption key (E-FEK) is issued, and the client or The service instance decrypts the encrypted file encryption key (E-FEK) received from the storage server with a secret key corresponding to the public key, and uses the decrypted file encryption key (FEK) to decrypt the file. An encryption / decryption step for encryption / decryption is provided. The method is associated with a specific machine, a storage server that issues an encrypted file encryption key (E-FEK) to the client or service instance.

  According to the fifth aspect of the present invention, there is provided a program for causing a computer constituting each of the above-described storage server, client, or service instance to execute. This program can be recorded on a computer-readable storage medium. That is, the present invention can be embodied as a computer program product.

  According to the present invention, even if a user's secret information (a secret key used as a decryption key for a user password or a file encryption key) is leaked, unauthorized access using the user's secret information is subsequently suppressed. It becomes possible to do.

It is a figure for explaining the outline of the present invention. It is a block diagram showing the structure of the 1st Embodiment of this invention. It is a figure which shows the structural example of the encryption file memorize | stored in the encryption file memory | storage part of FIG. It is a figure which shows the structural example of the list | wrist for managing the encryption file encryption key (E-FEK) in the E-FEK memory | storage part of FIG. It is a flowchart which shows the operation | movement (at the time of file creation) of the 1st Embodiment of this invention. It is a flowchart which shows the operation | movement (at the time of file utilization) of the 1st Embodiment of this invention. It is a flowchart which shows the operation | movement (at the time of service start) of the 1st Embodiment of this invention. It is a block diagram showing the structure of the deformation | transformation embodiment of this invention.

  First, the outline of the present invention will be described. As shown in FIG. 1, the present invention provides an encrypted file storage unit 26 for storing a file encrypted using a predetermined file encryption key (FEK; File Encryption Key), and an access right to the file. A file encryption key encryption unit 22 that encrypts the file encryption key (FEK) using a public key determined for each user or service, and the encrypted file encryption key (E-FEK) The storage server 20 includes the encrypted file encryption key storage unit 25 and the clients 10A and 10B that can access the storage server 20 via the network.

  The storage server 20 further includes an access request accepting unit 21, and when receiving a request for paying out an encrypted file encryption key (E-FEK) from the clients 10A and 10B, the revocation public key information storage unit 23 stores It is confirmed whether or not the public key of the user or service is registered, and when the validity of the public key is confirmed, the encrypted file encryption key (E-FEK) is paid out.

  Receiving the encrypted file encryption key (E-FEK) from the storage server 20, the clients 10A and 10B decrypt the encrypted file encryption key (E-FEK) using the private key corresponding to its public key, The file is encrypted using the obtained file encryption key (FEK).

  For example, as shown in FIG. 1, each of the clients 10A and 10B is a regular user, and an encrypted file is encrypted in the encrypted file storage unit 26 with its own file encryption key (FEK_A, FEK_B). Has been registered. Thereafter, the public key of the client 10A is invalidated for some reason (for example, leakage of the user private key_A of the client 10A), and the fact that the public key is invalidated is recorded in the invalidated public key information storage unit 23. Thereafter, the storage server 20 rejects the request for paying out the encrypted file encryption key (E-FEK) encrypted with the public key of the client 10A.

  This makes it possible to prevent the encrypted file from being decrypted without re-encrypting the encrypted file stored in the encrypted file storage unit 26.

[First Embodiment]
Next, a first embodiment of the present invention will be described in detail with reference to the drawings. FIG. 2 is a block diagram showing the configuration of the first exemplary embodiment of the present invention. Referring to FIG. 2, a storage server that can access the client 100, the service instance 200, the encrypted file storage unit 401, the E-FEK storage unit 402, the revoked public key list storage unit 403, and the service user list storage unit 404. 300 is shown.

  The client 100 includes a file input / output unit 101 that performs file input / output processing with various applications that handle files, its own private key (file owner private key), and another node's public key (storage server public key). Etc.), the FEK encryption / decryption processing unit 102 that performs encryption / decryption of the file encryption key (hereinafter referred to as “FEK”), and the FEK decrypted by the FEK encryption / decryption processing unit 102, 200 includes a file encryption / decryption processing unit 103 that performs encryption / decryption processing of the encrypted file received from 200, and a communication unit 105 that mainly communicates with the storage server 300. In the example of FIG. 2, a configuration in which one client 100 is connected is shown, but a plurality of clients 100 may exist. Further, a configuration in which there is no client 100 and only the service instance 200 can be employed.

  The service instance 200 includes a service execution unit 201 that executes a service, an FEK encryption / decryption processing unit 202 that performs FEK encryption / decryption processing using its own private key (service secret key), and an FEK encryption / decryption processing unit 202. A file encryption / decryption processing unit 203 that performs encryption / decryption processing of the encrypted file received from the storage server 200 using the FEK decrypted in step S3, and a communication unit 205 that mainly communicates with the storage server 300. Composed. A service instance 200 is prepared for each set of users who provide a service, and a plurality of service instances 200 can exist. There may be a plurality of services themselves. Also, a configuration in which there is no service instance 200 and only the client 100 can be employed.

  The storage server 300 includes a digital signature verification unit 301 that verifies a digital signature attached to a message received from the client 100, an authentication unit 302 that authenticates the client 100 and the service instance 200 using a predetermined authentication method, A communication unit 303 that communicates with the client 100 and the service instance 200, an FEK generator 304 that generates FEK using a predetermined key generation method, an FEK encryption / decryption processing unit 305 that performs encryption / decryption processing of FEK, and encryption Storage access unit 306 for accessing the activation file storage unit 401, E-FEK storage unit 402, revocation public key list storage unit 403, service user list storage unit 404, and the client 100 or service instance that requested the access request 200 requests Configured to include a request validation unit 307 verifies the validity of the. In the example of FIG. 2, a configuration in which one storage server 300 is connected is shown, but a plurality of storage servers 300 may exist.

  The encrypted file storage unit 401 is configured by a database or the like that stores files in a state encrypted with FEK. A specific configuration of the encrypted file will be described later with reference to FIG.

  The E-FEK storage unit 402 stores a public key determined for each user or service in association with an encrypted file encryption key (E-FEK) obtained by encrypting the FEK with this public key. A specific configuration of the FEK storage unit 402 will be described later with reference to FIG.

  The revoked public key list storage unit 403 stores a revoked public key list of users or services that have been revoked. The addition / deletion of the invalidation public key to the invalidation public key list storage unit 403 is performed by the administrator of the storage server by, for example, a report from the user. Instead of the revoked public key list, a list of valid public keys may be stored, and public keys not listed in the list may be determined to be invalid.

  The service user list storage unit 404 stores a service user list that stores a set of service instances and users who use the service instances.

  The encrypted file storage unit 401, the E-FEK storage unit 402, the revoked public key list storage unit 403, and the service user list storage unit 404 described above can be realized by one or a plurality of storage devices. In the example of FIG. 2, an encrypted file storage unit 401, an E-FEK storage unit 402, an invalidated public key list storage unit 403, and a service user list storage unit 404 are connected to the outside of the storage server 300. Although shown, a configuration in which a part or all of the encrypted file, the E-FEK, the revoked public key list, and the service user list is stored in a storage device built in the storage server 300 may be employed.

  Here, a specific configuration example of the encrypted file stored in the encrypted file storage unit 401 and the E-FEK storage unit 402 will be described.

  FIG. 3 is a diagram schematically showing the configuration of the encrypted file. In the example of FIG. 3, the encrypted file 500 is configured by adding the FEK ID 502 used for the encryption to the encrypted file body 501 obtained by encrypting the data body with FEK. As described above, it is possible to make it difficult to analyze the key information by not attaching the key information or related information to the encrypted file itself.

  FIG. 4 is a diagram showing the structure of a list 600 for managing public keys and E-FEKs held in the E-FEK storage unit 402. In the example of FIG. 4, for each FEK ID used when a certain file is encrypted, the public key of the access subject (file owner, storage server, other user, other service) who has access authority to the file And E-FEK encrypted with the public key of the corresponding access subject, and a necessary number (1 to n; n is the number of subjects permitted to access the file) are stored together. Is done. By preparing such a list for each FEK (FEK ID), management of the public key and E-FEK encrypted using the public key is facilitated.

  As apparent from FIGS. 3 and 4, the FEK itself that is not encrypted with the public key is not stored anywhere in the entire system shown in FIG. When a certain access subject tries to access a certain file, the E-FEK storage unit 402 refers to the E-FEK list corresponding to the FEK ID in FIG. -Remove FEK. Since the access subject holds a secret key corresponding to his / her public key, the E-FEK can be decrypted. As a result of the decryption, the target file can be encrypted and decrypted using the obtained FEK.

  Note that each unit (processing unit) of the client 100, the service instance 200, and the storage server 300 illustrated in FIG. 2 is realized by a computer program that causes the computer that configures the units to execute the above-described processes using the hardware. can do.

  Next, the operation of this embodiment will be described in detail by dividing it into creation of a file, use of the file, and start of a service using the file.

[Create File]
FIG. 5 is a flowchart showing the operation (when creating a file) of the first embodiment of the present invention. Referring to FIG. 5, first, the file creator (file owner) requests the storage server 300 for authentication using the client 100 prior to file creation (step S100).

  The storage server 300 authenticates the file owner using the authentication unit 302 and determines the public key of the file owner (step S101). Note that the authentication method in steps S100 and S101 is not particularly limited, and a method using a password or biometric information can be appropriately employed. In addition, the public key received from the file owner may be used as the public key to be confirmed here, or the public key of the authorized user (authenticated user) held on the storage server 300 side is read and the public key is confirmed. It is good to do.

  Next, the storage server 300 reads the revoked public key list from the revoked public key list storage unit 403 (step S102), and verifies the validity of the public key of the file owner (step S103). Although omitted in FIG. 5, if the public key of the file owner is invalidated as a result of the verification of the validity of the public key, error processing such as notification to the file owner is performed. Then, the process ends.

  When the validity of the public key of the file owner is verified, the client 100 creates a file using the installed application (step S104). When the creation of the file is completed, the client 100 requests the storage server 300 to generate an FEK used for encrypting the file (step S105).

  The storage server 300 that has received the generation request generates an FEK using the FEK generator 304 (step S106). The generated FEK is given an FEK ID for uniquely identifying the FEK.

  Subsequently, the storage server 300 uses the FEK encryption / decryption processing unit 305 to encrypt the generated FEK using the public key of each access subject authorized to access the file. The storage server 300 encrypts the FEK with the file owner's public key (step S107). Similarly, the storage server 300 encrypts the FEK with the public key of the storage server itself (step S108). Furthermore, the storage server 300 reads the service user list from the service user list storage unit 404 (step S109), and encrypts the FEK with the public key of another user or service that the file owner permits access to the file. (Step S110).

  The storage server 300 creates a list with the FEK ID added by combining the E-FEK created in steps S107, S108, and S110 and each public key used for encryption of the E-FEK (see FIG. 4 (see list 600 in FIG. 4), and stores it in the E-FEK storage unit 402 (step S111).

  In response to the FEK generation request in step S105, the storage server 300 transmits the E-FEK encrypted using the file owner's public key to the client 100 together with the FEK-ID.

  The client 100 that has received the E-FEK decrypts the received E-FEK using the file owner's private key (step S112).

  In the FEK encryption / decryption processing unit 102, the client 100 encrypts the file created in step S104 using the FEK obtained in step S112 (step S113). Thereafter, the client 100 transmits the encrypted file with the FEK ID added (see the encrypted file 500 in FIG. 4) to the storage server 300 as shown in FIG. 4 (step S114).

  The storage server 300 stores the encrypted file received from the client 100 in the encrypted file storage unit 401 (step S115).

  As described above, the encrypted file is stored in the encrypted file storage unit 401, and the main E-FEK that can access the file including the file owner is stored in the E-FEK storage unit 402 and can be used anytime. It becomes a state.

[Use of file]
FIG. 6 is a flowchart showing the operation (when using a file) of the first embodiment of the present invention. Referring to FIG. 6, first, a file user (user or service) requests authentication from the storage server 300 using the client 100 or service instance 200 prior to use of the file (step S200).

  The storage server 300 authenticates the file user using the authentication unit 302 and determines its public key (step S201). Note that the authentication method in steps S200 and S201 is not particularly limited, as in steps S100 and S101, and a method using a password or biometric information can be appropriately employed. In addition, the public key received from the file user may be used as the public key determined here, or the public key of the authorized user (authenticated user) held on the storage server 300 side is read out and the public key is obtained. It may be confirmed.

  Next, the storage server 300 reads the revoked public key list from the revoked public key list storage unit 403 (step S202), and verifies the validity of the public key of the file user (step S203).

  If the public key of the file user is invalidated as a result of verification of the validity of the public key, the storage server 300 reads the list 600 stored in the E-FEK storage unit 402 (step S207), The revoked public key and E-FEK are deleted from the list 600 in which the revoked public key and the corresponding E-FEK are registered (step S204). As a result, the E-FEK encrypted with the revoked public key is deleted from the entire system, and there is no FEK that can be decrypted with the private key corresponding to the revoked public key. Instead of deleting the revoked public key and E-FEK, a method of rewriting to other information so that these cannot be used can be appropriately employed.

  When the validity of the file user's public key is verified, the file user can make a file request to the storage server 300. When the file user makes a request for the file (step S205), the storage server 300 reads the requested encrypted file from the encrypted file storage unit 401 (step S206), and based on the FEK ID and the public key, E The E-FEK encrypted with the public key of the corresponding file user is read from the FEK storage unit 402 (step S207) and returned to the file user (step S208).

  First, the file user decrypts the E-FEK received from the storage server 300 with his / her private key (step S209), and decrypts the encrypted file using the decrypted FEK (step S210).

  Thereafter, the file user uses the file (step S211), and encrypts the file again with FEK (step S212).

  Thereafter, the file user transmits the encrypted file with the FEK ID added thereto as shown in FIG. 4 (see the encrypted file 500 in FIG. 4) to the storage server 300 (step S213).

  The storage server 300 stores the encrypted file received from the file user in the encrypted file storage unit 401 (step S214).

  As described above, the encrypted file after use is stored in the encrypted file storage unit 401.

[Start service using file]
FIG. 7 is a flowchart showing the operation (at the start of service) of the first exemplary embodiment of the present invention. Referring to FIG. 7, first, when the service instance 200 receives a service provision start instruction for a new user from somewhere (step S300), the service instance 200 requests authentication from the storage server 300 (step S301).

  The storage server 300 authenticates the service instance 200 using the authentication unit 302 and determines its public key (step S302). Note that the authentication method in steps S301 and S302 is not particularly limited as in steps S100 and S101, and a method using a password or biometric information can be appropriately employed. Also, the public key that is received from the service instance 200 side may be used as the public key to be determined here, or the public key of the authorized user (authenticated user) held on the storage server 300 side is read out and the public key It is good also as confirming.

  Next, the storage server 300 reads the revoked public key list from the revoked public key list storage unit 403 (step S303), and verifies the validity of the public key of the service instance 200 (step S304).

  If the public key of the service instance 200 is invalidated as a result of the verification of the validity of the public key, the storage server 300 reads the list 600 stored in the E-FEK storage unit 402 and is invalidated. The revoked public key and E-FEK are deleted from the list 600 in which the E-FEK corresponding to the public key is registered (step S305). As a result, the E-FEK encrypted with the revoked public key is deleted from the entire system, and there is no FEK that can be decrypted with the private key corresponding to the revoked public key. Instead of deleting the revoked public key and E-FEK, a method of rewriting to other information so that these cannot be used can be appropriately employed.

  When the validity of the public key of the service instance 200 is verified, the service instance 200 can request the storage server 300 to start a service for a new user. When the service instance 200 makes a service start request to a new user (step S306), the storage server 300 reads the service user list from the service user list storage unit 404 (step S307), and sends the new user and the existing user respectively. On the other hand, a service provision inquiry is transmitted (step S308).

  The new user and the existing user who have received the service provision inquiry each determine the use of the service (steps S309 and S311), and reply with a digital signature as a response (steps S310 and S312).

  The storage server 300 verifies the validity of these responses using the digital signature verification unit 301 (step S313), and when starting a service for a new user, the new user is added to the service user list in the service user list storage unit 404. Is added (step S314).

  Further, the storage server 300 allows the new user's encrypted file already registered in the encrypted file storage unit 401 to be accessed via the service instance 200, and the service public key and the new user's encryption file. The E-FEK obtained by encrypting the FEK for decrypting the encrypted file is added to the E-FEK storage unit 402 (step S315). More specifically, a list corresponding to the encrypted file of the new user is extracted from the list stored in the E-FEK storage unit 402, and is encrypted with the public key of the storage server in the list. The E-FEK is decrypted with the private key of the storage server 300, encrypted again with the service public key, and stored in the list.

  As described above, according to the present embodiment, secret information (mainly FEK) necessary for data decryption and key information (mainly E-FEK) calculated from the secret information is more than necessary outside the storage system. Data sharing between users or between users and services can be realized without going out. The reason is that the FEK required for decrypting the file is encrypted (E-FEK) with the public key of the authorized user or service, stored in a storage medium separate from the encrypted file, and encrypted. This is because only the access subject E-FEK is selectively used when accessing the file.

  In the present embodiment, random information generated for each file can be used as the FEK. Since public key cryptography is used for the encryption of the FEK, even if the FEK of some data is leaked, the safety of other data is not threatened, and even if the E-FEK of a certain user is leaked From there, confidential information represented by the user's password is never leaked.

  Further, in the present embodiment, a list of revoked public keys is further provided, and the storage server 300 verifies the validity of the access request from the access subject at the time of storage access, and then an appropriate E-FEK. Is supposed to be returned. For this reason, in the case where detection of secret information leakage and registration of the corresponding public key in the revocation public key list have been made, it is represented by a password of some users or services or a secret key of public key cryptography. Even if confidential information leaks, the security of other parts of the system is protected.

  In the present embodiment, the FEK ID used for encrypting the file is further added to the encrypted file, and the public key of the access subject is stored in the E-FEK storage unit 402 for each FEK ID. A list in which E-FEK is paired is stored. Therefore, if the public key of the access subject is specified at the time of data access authentication, the E-FEK corresponding to the public key can be read from the E-FEK storage unit 402. That is, it is not necessary to search for E-FEK in a brute force manner, and the overhead can be suppressed.

  Further, in the present embodiment, the result of the validity verification of the file user or service instance that is performed at the time of file access or service start (see step S203 in FIG. 6 and step S304 in FIG. 7), file When the public key of the user or service instance has been revoked, the storage server 300 deletes the E-FEK corresponding to the revoked public key from the E-FEK storage unit 402 ( (See step S204 in FIG. 6 and step S305 in FIG. 7). For this reason, even if leakage of the E-FEK storage unit 402 and leakage of the user's private key with an invalid public key occur, the FEK is not calculated from the user's private key. be able to.

  Further, in the present embodiment, when the user starts using the service, even if no action is taken, when the user newly starts using the service, the existing file is also updated. It can be included in the access range. The reason is that when the user starts using the service, the storage server 300 allows the user's existing file to be accessed via the service instance 200, and the service public key and the new user's encryption This is because the E-FEK encrypted with the FEK for decrypting the file is added to the E-FEK storage unit 402 (step S315 in FIG. 7).

  In this embodiment, since the public key of the storage server 300 and the E-FEK encrypted with the public key are stored in the E-FEK storage unit 402, the storage service provider side in the event of an emergency It is also possible to restore or access the contents.

[Second Embodiment]
Next, a second embodiment in which a change is made to the first embodiment of the present invention will be described. Since the second embodiment of the present invention can be realized with the same configuration as the first embodiment and has the same basic operation, the differences will be described below.

  In the second embodiment of the present invention, step S204 in FIG. 6 and step S305 in FIG. 7 in the first embodiment are omitted.

  In this way, the processing speed can be increased by omitting step S204 in FIG. 6 and step S305 in FIG. In addition, when the leakage of the E-FEK storage unit 402 and the leakage of the secret key of the user or service occur at the same time, there is a possibility that the FEK used to encrypt each file may be calculated. Separately, existing information leakage measures may be taken.

[Third Embodiment]
Next, a description will be given of a third embodiment in which a change is made to the first embodiment of the present invention. Since the third embodiment of the present invention can be realized with the same configuration as the first embodiment and has the same basic operation, the difference will be described below.

  In the third embodiment of the present invention, step S315 in FIG. 7 in the first embodiment is omitted, and step S108 in FIG. 5 is omitted.

Thus, by omitting step S315 in FIG. 7 and step S108 in FIG.
It becomes unnecessary to store the E-FEK corresponding to the public key of the storage server in the E-FEK storage unit 402. This means that strict file management is possible in which even the storage service provider cannot access the contents of the file.

[Fourth Embodiment]
Subsequently, a description will be given of a fourth embodiment in which a change is made to the first embodiment of the present invention. The fourth embodiment of the present invention can be realized with substantially the same configuration as the first embodiment, and the basic operation is also common. Therefore, the difference will be described below.

  In the fourth embodiment of the present invention, the storage server 300 encrypts the list 600 (see FIG. 4) stored in the E-FEK storage unit 402 by using a separately defined common key encryption or the like. .

  By encrypting the list 600 (see FIG. 4) stored in the E-FEK storage unit 402 in this way, the secret key of the user or service instance is leaked, and the information is stored in the invalidated public key list. Even before registration in the unit 403, the security of the FEK used for encrypting each file can be improved.

[Fifth Embodiment]
Subsequently, a fifth embodiment in which a change is made to the first embodiment of the present invention will be described. The fifth embodiment of the present invention can be realized with substantially the same configuration as the first embodiment, and the basic operation is also common, so the difference will be described below.

  In the fifth embodiment of the present invention, the file encryption / decryption processing units 103 and 203 of the client 100 or the service instance 200 do not encrypt the entire file at once with FEK, but divide the file into smaller structural units. The encryption / decryption is performed in units of things.

  By performing encryption / decryption in finer units in this way, the performance at the time of partial update of the file is improved.

  As mentioned above, although embodiment of this invention was described, this invention is not limited to each above-mentioned embodiment, In the range which does not deviate from the fundamental technical idea of this invention, further modification, substitution, and adjustment Can be added.

  For example, in each of the above-described embodiments, the description has been made on the assumption that the storage server 300 is provided with the FEK generator. However, as shown in FIG. A configuration in which 104 is arranged can also be adopted. In this case, in principle, FEK encryption / decryption is performed by the client 100. In this case, it is necessary to assign a unique FEK ID to the entire system. For example, a method for assigning an FEK ID to each client 100 in advance and a rule for creating an FEK ID are determined. Can be used. As the latter FEK ID creation rule, for example, a method in which a module for assigning and paying out an FEK ID based on the FEK hash value or the like is provided on the storage server 300 and each client 100 side can be considered.

  For example, in each of the embodiments described above, the service user list storage unit 404 has been described as being accessed from the storage server 300. However, as shown in FIG. 8, the service user list storage unit 206 is managed on the service instance 200 side. It is also possible to adopt a configuration that does this.

  The present invention can be applied to applications such as a storage service that provides disk space to a plurality of users via a network, and a back-end storage system for a web-based service.

Finally, a preferred form of the invention is summarized.
[First embodiment]
(Refer to the file management system from the first point of view)
[Second form]
In the first form,
The encrypted file encryption key storage unit lists, for each file encryption key, a set of a public key of each user or service and an encrypted file encryption key (E-FEK) encrypted using the public key. A file management system that manages a set of a public key and an encrypted file encryption key (E-FEK).
[Third embodiment]
In the first and second forms,
A file management system in which the storage server confirms the validity of the public key based on whether or not a public key determined for each user or service is stored in a list that stores the revoked public key.
[Fourth form]
In the 1-3 form,
A file management system in which the storage server rewrites or deletes the encrypted file encryption key (E-FEK) encrypted with the public key determined to be invalid as a result of confirmation of the validity of the public key. .
[Fifth embodiment]
In the 1-4 type,
The encrypted file encryption key storage unit stores an encrypted file encryption key (E-FEK) encrypted with the public key of the storage server,
The storage server newly uses the file encryption key (FEK) obtained by decrypting the encrypted file encryption key (E-FEK) encrypted with the public key with the private key corresponding to the public key. The encrypted file encryption key (E-FEK) of the user or service having access rights to the file is added to the encrypted file encryption key storage unit by encrypting with the public key of the user or service to be added to File management system.
[Sixth embodiment]
In the form 1-5,
Furthermore, a file management system that manages users using a service user list that stores a service instance and a set of users who use the service instance.
[Seventh form]
(Refer to the storage server from the second viewpoint above)
[Eighth form]
(Refer to the client from the third viewpoint above)
[Ninth Embodiment]
(See service instance from the third perspective above)
[Tenth embodiment]
(Refer to the file management method from the fourth viewpoint.)
[Eleventh form]
(Refer to the program from the fifth viewpoint above)
[Twelfth embodiment]
(Refer to the program from the fifth viewpoint above)
The seventh to twelfth embodiments can be developed in the same manner as the second to sixth embodiments derived from the first embodiment.

10A, 10B, 100 Client 20, 300 Storage server 21 Access request receiving unit 22 File encryption key encryption unit 23 Invalidated public key information storage unit 25, 402 Encrypted file encryption key storage unit (E-FEK storage unit)
26, 401 Encrypted file storage unit 101 File input / output unit 102 FEK encryption / decryption processing unit 103 File encryption / decryption processing unit 104, 304 FEK generator 105, 205, 303 Communication unit 200 Service instance 201 Service execution unit 202 FEK encryption / decryption processing Unit 203 file encryption / decryption processing unit 206, 404 service user list storage unit 301 digital signature verification unit 302 authentication unit 305 FEK encryption / decryption processing unit 306 storage access unit 307 request validity verification unit 401 encrypted file storage unit 402 E-FEK storage 403 Invalidation public key list storage unit 500 Encrypted file 501 Encrypted file body 502 FEK ID
600 lists

Claims (10)

An encrypted file storage unit for storing a file encrypted using a predetermined file encryption key (FEK), and a public key determined for each user or service having access to the file A storage server comprising: an encrypted file encryption key storage unit that stores an encrypted file encryption key (E-FEK) obtained by encrypting the file encryption key (FEK);
A decryption processing unit for decrypting the encrypted file encryption key (E-FEK) received from the storage server with a secret key corresponding to the public key, and encrypting / decrypting the file using the decrypted file encryption key (FEK) An encryption / decryption processing unit, and a client or service instance comprising:
The storage server confirms the validity of a public key determined for each user or service having access rights to the file, and then sends an encrypted file encryption key (E-FEK) to the client or service instance. Pay out file management system.   The encrypted file encryption key storage unit lists, for each file encryption key, a set of a public key of each user or service and an encrypted file encryption key (E-FEK) encrypted using the public key. The file management system according to claim 1, wherein a set of a public key and an encrypted file encryption key (E-FEK) is managed.   The storage server confirms the validity of the public key depending on whether or not a public key determined for each user or service is stored in a list storing the revoked public key. 2. File management system.   The storage server rewrites or deletes the encrypted file encryption key (E-FEK) encrypted with a public key determined to be invalid as a result of confirmation of the validity of the public key. To 3 file management system. The encrypted file encryption key storage unit stores an encrypted file encryption key (E-FEK) encrypted with the public key of the storage server,
The storage server newly uses the file encryption key (FEK) obtained by decrypting the encrypted file encryption key (E-FEK) encrypted with the public key with the private key corresponding to the public key. The encrypted file encryption key (E-FEK) of the user or service having access rights to the file is added to the encrypted file encryption key storage unit by encrypting with the public key of the user or service to be added to The file management system according to claim 1.   6. The file management system according to claim 1, further comprising: managing a user using a service user list storing a service instance and a set of users who use the service instance. A decryption processing unit that decrypts the encrypted file encryption key (E-FEK; Encrypted-File Encryption Key) received from the storage server with the secret key, and the file using the decrypted file encryption key (FEK; File Encryption Key) An encryption / decryption processing unit for encryption / decryption, connected to a client or a service instance,
Using the file encryption key (FEK), an encrypted file storage unit for storing a file encrypted, and a public key defined for each user or service having access to the file, the file encryption key ( An encrypted file encryption key storage unit for storing an encrypted file encryption key (E-FEK) obtained by encrypting FEK),
A storage server that issues an encrypted file encryption key (E-FEK) to the client or service instance after confirming the validity of a public key determined for each user or service having access to the file .   A decryption processing unit for decrypting an encrypted file encryption key (E-FEK; Encrypted-File Encryption Key) received from the storage server of claim 7 and a decrypted file encryption key (FEK; File Encryption Key) A client comprising: an encryption / decryption processing unit for encrypting / decrypting the file.   A decryption processing unit for decrypting an encrypted file encryption key (E-FEK; Encrypted-File Encryption Key) received from the storage server of claim 7 and a decrypted file encryption key (FEK; File Encryption Key) A service instance comprising: an encryption / decryption processing unit for encrypting / decrypting the file. An encrypted file storage unit for storing a file encrypted using a predetermined file encryption key (FEK), and a public key determined for each user or service having access to the file And a storage server comprising an encrypted file encryption key storage unit for storing an encrypted file encryption key (E-FEK) obtained by encrypting the file encryption key (FEK), in response to a request from a client or a service instance. Accordingly, after confirming the validity of the public key defined for each user or service having access rights to the file, an encrypted file encryption key (E-FEK) is paid to the client or service instance. Step to issue,
The client or service instance decrypting the encrypted file encryption key (E-FEK) received from the storage server with a private key corresponding to the public key;
An encryption / decryption step of encrypting / decrypting the file using the decrypted file encryption key (FEK);
File management method including.

Images