JP2011198325A - Method and system for performing safe bringing-out of file data to outside - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method for safely bringing out to outside, file data which is held in a computer.SOLUTION: The method includes: a step of dividing the file data into a plurality of fragmented files by using a threshold secret sharing method in a computer; a step of transmitting a plurality of divided fragmented files to a plurality of net storage services to hold the files; and a step of obtaining at least two of the fragmented files held in the net storage services in a computer using the file data, to restore the original file data.

Description

  The present invention uses a threshold secret sharing method on a plurality of net storages to increase confidentiality and availability, and can safely take out files and automatically synchronize distributed data. The present invention relates to a safe external export method and system for file data.

Currently, there are various methods for safely taking out files that prevent information leakage. For example, (1) export on a personal computer (PC) using encryption software (Non-patent Document 1), (2) export on a USB memory having an encryption function (Non-patent Document 2), (3) secret This is divided and taken out by a PC and a USB memory using distributed (Patent Literature 1), and (4) taken out by a PC with an information deletion function introduced via a network or the like (Non-Patent Literature 3). There are also products that combine these.
However, in (1) and (2), there is a risk that the content will leak if the encryption is broken. The risk of breaking the cryptography is increasing year by year, as cloud computing and other large computing power are available at a low cost.

In (2) and (3), a physical medium other than a PC such as a USB memory is used, which is complicated to manage and may be lost due to misplacement or the like. In particular, an external medium such as a USB memory is miniaturized and has a high risk of loss. Furthermore, (3) tends to be managed and transported as a set with a PC because of fear of being able to access data, and the secret sharing technology may become meaningless at the operation site.
In addition, (4) includes deletion via a network and time deletion, but it is possible to avoid the deletion by changing the internal clock without connecting to the network. In general, encryption is often combined, but this is not necessarily secure as described above. Furthermore, (4) has a high introduction cost when a dedicated PC is required.

  On the other hand, there are many inexpensive net storage services in recent years. These net storages are services that allow you to import and export files and data anytime you can use the Web. In many cases, it has a general user authentication function, and communication is encrypted by HTTPS. It is also said that servers are managed safely. For this reason, there is a direction that it is considered safer than taking out a file on an external medium or a PC as in (1) to (4) above.

  However, there are two risks in using the net storage service. One is the risk of information leakage from inside the service provider. Many net storage services have explained that they are taking necessary measures such as encryption, but the user cannot basically confirm it, and it is not known what it actually is. The other is the risk of service outage. Many services may be temporarily unavailable due to network or hardware failure. There are services that guarantee the operation rate with SLA, but there is a possibility that it will stop to some extent instead of 100%. Compensation when the occupancy rate is not met is often in the form of a reduction in service fees, and not all losses such as lost opportunities are compensated.

Regarding the former risk, there is a countermeasure method that encrypts on the client PC side before placing the file on the net storage, but since it uses encryption technology in the end, it is not necessarily safe as described above. The latter problem cannot be solved.
Therefore, in order to use the net storage service at present, the service provider can only be trusted in the end.

Patent No. 4039810

HIBUN AE Information Cyber http://hitachisoft.jp/products/hibun/products/ae_ic.html Security USB memory ED-EA series with automatic hardware encryption function http://www.iodata.jp/product/USBmemory/easydisk/ed-ea/ CLEARSUREhttp: //www.fmworld.net/biz/fmv/lifebook/clearsure/

  An object of the present invention is to realize file take-out while preventing information leakage, and to preserve existing net storage without holding files and part of files including encrypted files on a physical medium such as a PC or a USB memory. Provides a method to take out information leakage prevention files that can use the service but avoid the risk of information leakage from the company that provides the net storage service, and consider the temporary suspension of the net storage service, etc. to increase the availability as much as possible. There is to do.

In order to achieve the above object, a file take-out method according to the present invention includes a step of dividing the file data into a plurality of fragment files using a threshold secret sharing method in the computer, and a plurality of the plurality of divided fragment files. Transmitting to the network storage service and storing the file data, and obtaining at least two of the plurality of fragment files stored in the plurality of net storage services in the computer using the file data to restore the original file data And a step.
A step of checking that all of the net storage services are available, and performing fragment file synchronization processing between the net storages if they are available, and resolving fragment file inconsistencies that occur when a file is changed, etc. And further comprising.
The file take-out system according to the present invention is a system for safely taking out file data held by a computer to the outside,
Means for dividing the file data into a plurality of fragment files by using a threshold secret sharing method; means for transmitting the divided plurality of fragment files to a plurality of net storage services; A computer using data includes means for acquiring at least two of a plurality of fragment files held in the plurality of net storage services and restoring the original file data.
In addition, the computer checks that all the net storage services are available, and if available, performs fragment file synchronization processing between the net storages, and fragment file inconsistencies that occur when a file is changed, etc. It is further characterized by further comprising means for eliminating

  According to the present invention, since file data is not stored on a physical medium such as a PC or a USB memory, information leakage does not occur when these are lost. In addition, since the file data is sent as fragment files to a plurality of net storage services to be held, information leakage from the company that provides the net storage service does not occur. Furthermore, if a storage service within the threshold is available, it can be saved, and the files that have been synchronized can be referenced and updated at any time. Since it is performed as much as possible, high availability can be ensured.

It is a system configuration figure showing an embodiment of the invention. It is a figure which shows the example of Place Data List. It is a figure which shows the example of Place List. It is a figure which shows the example of Local Cache List. It is a figure which shows the example of Place Data List Cache. It is a flowchart which shows the outline | summary of a process of a client application. It is a flowchart which shows the process of a process at the time of starting. It is a figure which shows the example of the password input screen of a net storage service. It is a flowchart which shows the process of a file presence display process. It is a figure which shows the example of a file display screen. It is a figure which shows the example of the file display screen at the time of a non-connection. It is a flowchart which shows a maintenance management loop process. It is a flowchart which shows the example of Local Cache List. It is a figure which shows the example of the file display screen at the time of becoming disconnected. It is a flowchart which shows a file re-display process. It is a flowchart which shows a file reference process. It is a flowchart which shows a file new registration and change process. It is a flowchart which shows a file deletion process. It is a flowchart which shows the outline | summary of a synchronous process. It is a flowchart which shows the outline | summary of a local synchronous process. It is a flowchart which shows the outline | summary of the synchronous process between PP. It is a flowchart which shows the outline | summary of a process at the time of completion | finish.

Hereinafter, an embodiment for carrying out the present invention will be specifically described with reference to the drawings.
Here, in this embodiment, the original file is divided into three fragment files A, B, and C, and a threshold value that can be restored if two fragment files A, B, B, C, or A, C are obtained. We will use the secret sharing method.
FIG. 1 shows a configuration diagram of a system according to an embodiment of the present invention.
This system includes a client PC 100 and an external net storage service group 110 connected via the Internet.
The net storage service group 110 includes three net storage services: a net storage service 111 provided by company A, a net storage service 112 provided by company B, and a net storage service 113 provided by company C. On each net storage service, a storage area 114 is arranged at a position described in a Place List 122 described later. In the storage area 114, a fragment file 115 generated after secretly sharing the file and a place data list 116 holding metadata of all the fragment files in the storage area are arranged.

A detailed example of the Place Data List 116 in one net storage service is shown in FIG. The Place Data List 116 is a table file including a B FNAME 201 indicating a file name before division, a Ver 202 indicating a fragment file version, and a P FNAME 203 indicating a fragment file name stored in a storage area.
For example, the first line indicates that a version 1 fragment file X.doc.p1-1 obtained by dividing the X.doc file is stored in this storage area.
The client PC 100 includes an explorer 101 that is an existing technology for a user to access files and folders, and a client application 120 that is the center of the system.

  The client application 120 includes an interface processing unit 121 for exchanging with the explorer 101, a place list 122 in which information of a net storage service to be used is described, a local cache list 123 that is a file list used when the application is started and during operation, and each net storage Place Data List Cache 124 which is cache data corresponding to the Place Data List 116 in the service, a temporary file 125 used at the time of file access or secret sharing processing, a temporary storage area 127 for temporarily storing it, a temporary file configuration, etc. A fragment file 128 to be used for storage, a fragment file storage area 129 for storing the fragment file, a secret sharing processing unit 129 for secretly distributing the file and creating a fragment file, and an original file from two or more fragment files A secret integration processing unit 130 for reconfiguring the network, a communication processing unit 131 for performing communication processing with the secret sharing network storage service, and a synchronization processing unit 132 for performing synchronization at the time of file update and fragment file synchronization between net storage services Is done.

  A detailed example of the Place List 122 is shown in FIG. The Place List 122 includes a PID 301 indicating an identifier of the net storage service, a URL 302 indicating an access URL of the net storage service, a UNAME 303 indicating a user name used for authentication of the net storage service, and a Dir 304 indicating the location of the storage area 114 on the net storage service. And PW 305 for temporarily storing a password used at the time of net storage authentication, and State 306 for registering a connection state between the net storage service and the client application 120.

A detailed example of the Local Cache List 123 is shown in FIG.
The Local Cache List 123 includes FNAME 401 indicating the original file name, Ver 402 indicating the version of a valid fragment file, P1 Ver 403 indicating the version of the fragment file stored in the net storage service P1, and the fragment file name stored in P1. P1FNAME 404 shown, similarly P2Ver 405, P2FNAME 406, P3 Ver 407, P3F NAME 408 showing fragment file versions and file names stored in P2 and P3, Synced 409 showing whether synchronization is completely established between the net storage services, on the client PC Only the local 410 indicating whether or not the latest valid version file exists.

For example, the first line indicates that the file is X.doc, the valid version is 1, and the fragment file of the same version exists on the net storage for all net storage services.
The second line indicates that the version of the fragment file stored in P3 is one before the net storage, but Synced 409 is no and the synchronization is not established. Incidentally, as will be described in detail later, if the P1 and P2 can be connected, the Y.ppt file on the second line can be used.
The third line indicates that because the file is newly registered in the client PC 100, Local 410 is yes and the latest and valid version fragment file does not exist on the net storage service.

A detailed example of the Place Data List Cache 124 corresponding to one Place Data List 116 is shown in FIG.
The Place Data List Cache 124 includes B FNAME 501, Ver 502, and P FNAME 503, which are caches of data 201 to 203 in the Place Data List 116, a check 504 that checks whether there is a failure in sending a fragment file, and a fragment file in the client application 120. It consists of Down 505 indicating whether or not a fragment file exists in the area 128.
For example, the first line indicates that X.doc.p1-1, which is a fragment file of version 1 of X.doc, has been displayed and downloaded. The third line indicates that the display processing has been completed but the fragment file has not been downloaded. The fourth line indicates that neither the display process nor the fragment file has been downloaded.

FIG. 6 is a flowchart showing an outline of the processing of the client application 120.
The client application 120 performs a startup process 601 described later at startup, and a file reference process 602, a new file registration / change process 603, and a file deletion process, which will be described later, according to a user operation on the created net drive or folder. 604, processing 605 at the end is performed. In the case of the end-time process 605, the process ends as it is, and in other processes, a process according to the next user operation is performed.

FIG. 7 is a flowchart showing an outline of the startup process.
First, the client application 120 displays a password input screen and prompts the user to input a password (step 701).

FIG. 8 shows an example of a password input screen. The password input screen includes a URL display unit 801, a user name display unit 802, and a password input unit 803. Here, the URL display unit 801 and the user name display unit 802 use information in the place list 116 of FIG. 3 set in advance.
After the user inputs the password of each net storage service and clicks OK, the client application 120 holds the password input in the PW 305 of the Place List 122 in FIG. 3 and uses the communication processing unit 131 to store each net storage service. (Step 702). The user name and password used for authentication at this time use UNAME 303 and PW 305 held in the Place List 122.

  Next, the client application 120 moves to the folder in the Dir 304 of the Place List 122 in FIG. 3 and tries to acquire the Place Data List 116 in connection to each net storage service. For the Place Data List 116 that has been successfully acquired, a corresponding Place Data List Cache 124 is created (Step 703). In the creation of the Place Data List Cache 124, for the B NAME 501, Ver 502, and P NAME 503, the values in the acquired Place Data List 116 are copied, and the rest are blank.

Next, with respect to the State 306 of the Place List 122, the Place Data List 116 is successfully acquired in Step 703, and Online is stored for the net storage service for which the Place Data List Cache 124 has been created, and Offline is stored for the net storage service that has failed. (Step 704).
Next, it is checked whether two or more net storage services are online (step 705). If two or more net storage services are online, file existence display processing is performed (step 706).

FIG. 9 is a flowchart showing detailed processing of the file presence display processing.
First, a local cache list 123 is created from a plurality of place data list caches 124 using the original file name B NAME 501 as a key (step 901).
Thereafter, the Local Cache List 123 is processed from the top.
First, it is checked whether or not there are two or more fragment files for the original file name FNAME 401 by checking whether the values of P1FNAME 404, P2FNAME 406, and P3FNAME 408 are included (step 902).
If it exists, whether or not two or more of the existing fragment files are the same version is checked by comparing the values of P1Ver403, P2Ver405, and P3Ver407 (step 903).

If two or more of the existing fragment files are the same version, keep the version in Rver 402, and if all three fragment files exist and all versions are the same, keep yes in Synced 409 Let Further, if any net storage service is not connected and therefore there is a blank, unknown is held, and if there is no other version, no is held (step 904). Then, the file name is displayed as an accessible file using FNAME 401 (step 905).
In step 902 and step 903, if two or more fragment files of the same version do not exist, it is first checked whether or not all the net storages are connected (step 906).

If all the connections have been made, the corresponding data is deleted from the Local Cache List 123 and the Place Data List Cache 124, and the corresponding data is also deleted from the Place Data List 116 on the net storage service ( Step 907). Further, the corresponding fragment file on the net storage service is also deleted (step 908). By these steps 907 and 908, deletion of a fragment file that is not already used and information related to the fragment file are realized.
If all network storage services are not connected in step 906, the file name is displayed as an inaccessible file using FNAME 401 (step 909).

FIG. 10 shows an example of a display screen as a result of the file existence display process.
In this example, an accessible file is displayed with a solid line such as 1001, and an inaccessible file is displayed with a broken line such as 1002. In addition, the color may be changed or another icon may be displayed.
In step 706, after the file existence display process shown in FIG. 9 is completed, a maintenance management loop process described later is started (step 708). In step 708, the process ends without waiting for the end of the maintenance management loop process.
If at least two of the Place List 122 are not in the online state in step 705, the file display screen is displayed in a form indicating the disconnected state (step 709). An example of the screen at this time is shown in FIG.

  As shown at 1101 in FIG. 11, the date connection state is shown to the user by changing a part of the color or pattern as compared with the file display screen in the connection state shown in FIG. In this case, the file is not displayed.

FIG. 12 is a flowchart showing the maintenance management loop process in step 708.
First, a timer is started and wait processing is performed until an appropriate time has passed (step 1201).
Next, a connection state is confirmed by accessing the Place Data List 116 or the like for the net storage service in which the State 306 is Online in the Place List 122.
Further, the network storage service in the offline state is re-established in the same manner as in step 702 of the start-up process, and it is checked whether or not the place data list 116 on the net storage service can be acquired (step 1202).

  Next, it is checked whether or not the result of the check is different from the State 306 of the Place List 122 (Step 1203). If there is no change, the synchronization processing unit 132 performs a synchronization process to be described later (step 1204), and checks whether or not the process is completed (step 1205). If the process at the end has been performed, the process ends as it is, and if not, the process returns to step 1201.

If there is a change in the connection state with the net storage service in step 1203, the acquisition of the Local Cache List 123 is handled for the net storage service that is newly in the online state, as in step 703 of the startup process in FIG. The Place Data List Cache 124 is created.
For the net storage service in the offline state, items other than those whose Down 505 is yes are deleted from the corresponding Place Data List Cache 124 (step 1206). Then, the State 306 of the Place List 122 is changed according to the current connection status (Step 1207).

Next, the deletion or creation of the Place Data List Cache 124 is reflected in the Local Cache List 123, and the fragment file 127 not described in the new Local Cache List 123 is deleted from the fragment file area 128 (Step 1208).
The reflection in the Local Cache List 123 is, for example, when the Place Data List Cache 124 of the net storage service with the PID 301 of 1 is deleted, the data in the P1Ver 403 and P1FNAME 404 columns of the Local Cache List 123 are left blank. When a new Place Data List Cache 124 of the net storage service with PID 301 of 3 is newly created, JOIN is performed to the Local Cache List 123 using B NAME as a key.

Next, referring to the State 306 of the Place List 122, it is checked whether or not two or more net storage services are online (step 1209). If two or more net storage services are not in the Online state, the file display is divided according to the value of Local 140 in the Local Cache List 123.
A file whose value of Local140 is yes is displayed as an accessible file. As will be described in detail later, a file whose Local 140 value is Only is a file that exists only on the client PC, and is displayed as a Local Only file. Other files are displayed as inaccessible files (step 1210).

For example, in the case of a Local Cache List as shown in FIG. 13, a display indicating a non-connection state is displayed as indicated by 1401 in FIG. Incidentally, the file display 1402 associated with a bold line is a display indicating a Local Only file existing only on the client PC. After step 1210, the process proceeds to step 1205 described above.
If two or more net storage services are online in step 1209, the file existence redisplay process is performed (step 1211).
In the file re-display process (step 1210), the process of FIG. 15 is performed for each row of the Local Cache List 123 changed in step 1208.

First, it is checked whether or not the value of Local 140 is Only (step 1501), and if it is a Only file, it is displayed as a Local Only file (Step 1502), and the process ends.
In step 1501, if the value of Local140 is not Only, it is checked whether the value of Local140 is yes (Step 1503). If yes, the value of Synced is appropriately changed with reference to the values of P1Ver403, P2Ver405, and P3Ver407 in the Local Cache List 123 as in step 904 of the file existence display process of FIG. 9 (step 1504).
Then, similar to step 904 of the file existence display process in FIG. 9, the file is displayed as an accessible file (step 1505), and the process ends.

If it is determined in step 1501 and step 1503 that the value of Local 140 is neither Only nor yes, the same processing as step 902 and subsequent steps in the file existence display processing of FIG. 9 is performed. Steps 1506 to 1513 are the same as steps 902 to 909 of the file existence display process in FIG.
After the file existence redisplay process in step 1210 is completed, the process proceeds to a synchronization process in step 1204 described later. Thereafter, it is confirmed whether or not the end process has been performed (step 1205). If the end process has been performed, the process ends. If not, the process returns to the timer waiting process in step 1201.
As described above, this connection management loop process is started and the startup process in FIG. 7 is ended.
Next, a file reference process 602, a new file registration / change process 603, and a file deletion process 604 will be described.

FIG. 16 shows a process flow of the file reference process 602 of FIG.
When a file reference is requested by the user, the client application 120 first refers to the Local 410 in the corresponding row of the Local Cache List 123, then checks the temporary area 126, and there is a temporary file 125 corresponding to the requested file. Whether or not (step 1601).
If there is a temporary file, the file is referred to (step 1602), and the process is terminated.

In step 1601, if there is no corresponding temporary file, a retry value to be used later is initialized, the value of Down 505 of the Place Data List Cache 124 and the fragment file area 128 are referenced, and there are necessary and sufficient fragment files. Whether or not (step 1603).
Here, the necessary and sufficient fragment files are fragment files that can reconstruct the original file, and specifically, are two or more fragment files having the same version as the Rver 402 of the Local Cache List 123.

If the necessary and sufficient fragment file exists in the fragment file area 128 in step 1603, a temporary file equivalent to the original file is generated in the temporary area 126 using the secret combination processing unit 130, and the corresponding local cache list 123 corresponds. The value of Local 410 in the row is set to yes (step 1604), and the process proceeds to step 1602.
If the necessary and sufficient fragment file does not exist in the fragment file area 128 in step 1603, it is confirmed that the retry value initialized in step 1601 has not reached the number of retries appropriately set in advance (step 1604). If not reached, the retry value is increased, the fragment file corresponding to the requested file in the Place Data List Cache 124 and the value of Down 505 being no is passed through the communication processing unit 131 to the net storage service. Download from (1606). If the download is successful within a preset appropriate time, the value of Down 505 of the Place Data List Cache 124 is set to yes, the downloaded fragment file is placed in the fragment file area 128 (step 1607), Return to 1603. If the download is not successful in step 1607, nothing is done and the process returns to step 1603.
In step 1605, if the retry value has reached the number of retries set appropriately in advance, a reference error is returned through the interface processing unit 121 (step 1607), and the reference processing is terminated.

FIG. 17 is a flowchart showing the file new registration / change process 603.
The new file registration / change process 603 places a new file in the temporary area 126 through the interface processing unit 121 or changes the temporary file 125 in the temporary area 126 corresponding to the file referenced in the file reference process 602. This process is performed when Therefore, it is assumed that the temporary file 125 corresponding to the newly registered and changed file exists in the temporary area 126. Based on this premise, the file new registration / change processing 603 will be described.

First, duplication of file names is confirmed in the Local Cash List 123 (step 1701). If there is no duplication, a new line is added to the Local Cache List 123 as a file name in FNAME 401, 1 in Rver 402, no in Synced 409, and Only in Local 410 (step 1702). And it displays as a Local file (step 1703).
Next, the secret sharing process of the temporary file 125 corresponding to the newly registered / changed file is performed, and the corresponding fragment file 127 is generated in the fragment file area 128 (step 1704). At this time, the file name of the fragment file should not be duplicated with other fragment files. For example, a combination of the original file name, the PID 301 of each net storage service, and the version Rver 402 is used as the fragment file name.

Next, the fragment file name created in step 1704 is registered in P1FNAME 404, P2FNAME 406, and P3FNAME 408 in the corresponding row of the Local Cash List 123. At this time, the value of Rver 402 is entered in P1Ver403, P2Ver405, and P3Ver407. Further, it is also registered in each Place Data List Cache 124. At this time, check 504 sets No and Down 505 sets yes. Also, a retry value to be used later is initialized (step 1705).
Next, the fragment file 127 generated in step 1704 is transmitted to each net storage service. If there is an old version fragment file in the Place Data List 116, the fragment file is deleted, and the Place Data List Cache 124 performed in step 1705 is deleted. Is reflected in the Place Data List 116 in each net storage service. In the Place Data List Cache 124 corresponding to the net storage service for which these have succeeded, the check 504 of the line corresponding to the transmitted fragment file is changed to yes (step 1706).

  Next, it is checked whether or not the processing in step 1706 has succeeded for two or more net storage services (step 1707). If two or more net storage services are not successful, it is confirmed that the retry value initialized in step 1705 has not reached the number of retries set appropriately in advance (step 1708). . If not reached, the retry value is increased, and the process returns to step 1706 to try again to transmit the fragment file 127 and change the Place Data List Cache 124.

  If it is determined in step 1708 that the retry value has reached the number of retries appropriately set in advance, the processing is terminated as it is. In this case, the newly registered / changed file remains displayed as a Local file, and synchronization is attempted in a synchronization processing step 1211 described later.

  In step 1707, if the processing of step 1706 is successful for two or more net storage services, the value of Local 410 in the row of Local Cache List 123 corresponding to the newly registered / changed file is changed to yes. If the processing in step 1706 is successful for all three net storage services, the value of Synced 409 is changed to yes, and the file display is changed from the local file to an accessible file and displayed again (step 1709). .

If the file name is duplicated in step 1701, the user is inquired through the interface processing unit 121 whether to change the existing file, and the answer is checked (step 1710). If the user requests a change, the Rver in the row of the Local Cache List 123 corresponding to the file to be changed is incremented by 1, no is set in Synced, and Local 410 is changed to Only (step 1711). Thereafter, the process proceeds to step 1703 described above.
If the user does not request to change the existing file in step 1710, an appropriate error process such as prompting to change the file name of the file to be saved is performed through the interface processing unit 121 (step 1711), and then the process ends.

FIG. 18 is a flowchart showing the file deletion process 604.
First, the Local Cache List 123 and the Place Data List Cache 124 are checked, and if the temporary file 125 and the fragment file 127 corresponding to the file to be deleted exist in the temporary area 126 and the fragment file area 128, they are deleted. Accordingly, necessary changes are made such as setting Local 410 of the Local Cache List 123 to no and setting Down 505 of the Place Data List Cache 124 to no. Further, a retry value to be used later is initialized (step 1801).

  Next, the fragment file on the net storage service is identified from each Place Data List Cache 124, and the identified fragment file is deleted through the communication processing unit 131, and the line of the Place Data List 116 corresponding to the deleted fragment file is deleted. Try. For the net storage service that can be deleted, the line corresponding to the deleted fragment file in the corresponding Place Data List Cache 124 is also deleted (step 1802).

  Next, it is checked whether or not the processing of Step 1802 is successful for two or more net storage services (Step 1803). If two or more net storage services are not successful, it is confirmed that the retry value initialized in step 1801 has not reached the number of retries set appropriately in advance (step 1804). . If not reached, the retry value is increased, and the process returns to step 1802 to delete the fragment file on the net storage service again.

In step 1804, if the retry value has reached the number of retries set appropriately in advance, the user is notified through the interface processing unit 121 that the deletion has not been possible (step 1805), and the process ends.
In step 1803, if the processing in step 1702 is successful for two or more net storage services, the deleted file is hidden and the corresponding line is deleted from the local cache list 123 (step 1806). Then, the process ends.
By the processing described above with reference to FIGS. 16, 17, and 18, file reference, new registration / change, and deletion processing can be performed.

Next, details of the synchronization processing in step 1204 of the connection management loop processing of FIG. 12 will be described.
The synchronization process performs two synchronizations. One is local file synchronization. This is to synchronize a file whose version is valid only in the temporary area 126 on the client PC and whose Local 410 is Only in the Local Cache List 123 with the net storage service. This is called local synchronization processing.
The other is to synchronize a file in which a fragment file different from RVer 402 exists on a certain net storage service and Synced 409 is no in Local Cache List 123. This is called PP synchronization processing.

FIG. 19 is a flowchart showing an outline of the synchronization process.
First, referring to the State 306 of the Place List 122, it is checked whether or not two or more net storage services are online (step 1901). If two or more net storage services are not in the Online state, the processing is terminated without doing anything. If two or more net storage services are online, local synchronization processing is performed for each row of the local cache list 123 (step 1902).

FIG. 20 is a flowchart showing an outline of the local synchronization process.
First, it is checked whether or not Local 410 is Only in the Local Cache List 123. Further, a retry value to be used later is initialized (step 2001). If it is not Only, do nothing and end the process.
In Step 2001, if Local 410 is Only, the fragment file created by the file new registration / change process shown in FIG. 17 exists, and the fragment file that could not be transmitted is specified by the value of check 504 of each Place Data Cache List 124. it can. Therefore, processing such as fragment file transmission is performed in the same manner as in step 1706 of the new file registration / change processing shown in FIG. 17 (step 2002).

  Next, similarly to step 1706 of file new registration / change processing, processing of step 2002 or file new registration / change processing is performed with two or more net storage services, including processing such as fragment file transmission already performed. It is checked whether or not step 1706 has succeeded (step 2003). However, the difference from step 1706 of file new registration / change processing is that if the processing of step 2002 is not successful with two or more net storage services, the processing is terminated without doing anything.

If two or more net storage services have succeeded in step 2002 or step 1706, the same processing as step 1709 of file new registration / change processing is performed (step 2004).
As a result, a file in which a valid version file exists only in the temporary area 126 on the client PC also exists on the net storage service.
After the local synchronization processing in step 1902, it is checked whether all the net storage services are online (step 1903). If even one of the net storage services is not online, the process is terminated without doing anything.
If all the net storage services are online in step 1903, the inter-PP synchronization processing is performed for each row of the Local Cache List 123 (step 1904).

FIG. 21 shows a flowchart of the synchronization process between PPs.
First, it is checked whether Synced 405 is no in the Local Cache List 123 (step 2101). If it is not no, do nothing and end the process.
If Synced 405 is no in Step 2101, the Place Data Cache List 124 and the like are referred to, and it is checked whether or not there is a fragment file that needs to be transmitted for synchronization in the fragment file area 128 (Step 2102). Here, there is a possibility that a fragment file to be transmitted exists if the file has been newly registered / changed before.

If there is no fragment file necessary for step 2102, the reference processing shown in FIG. 16 is performed (step 2103). However, the reference processing of the target file in step 1602 and the reference error processing in step 1607 are not returned to the interface processing unit 121, but are only returned as success or failure.
Next, as a result of step 2103, it is confirmed whether the reference has succeeded or failed (step 2104). If the reference fails, the process is terminated.

If the reference is successful in step 2104, the temporary file 125 corresponding to the file referenced in the temporary area 126 should have been created, so that the new registration / change processing step 1704 shown in FIG. A fragment file is created by performing the same processing as in (Step 2105).
Next, the Local Cache List 123 is checked, and a fragment file that already has a valid version of the fragment file on the net storage service and does not need to be transmitted is deleted (step 2106). Here, when Synced is no, only one fragment file remains, so the subsequent processing is performed on one remaining fragment file.

  Next, for the fragment file that has not been deleted, the name and version of the corresponding fragment file are registered or changed in the corresponding row of the Local Cash List 123, as in step 1705 of the new registration / change process of FIG. . Similarly to step 1705, the data is also registered in the corresponding place data list cache 124, and check 504 sets No and Down 505 to yes (step 2107). However, unlike step 1705, the retry value is not initialized.

After step 2107 and when there is a fragment file required in step 2102, or after step 2107, as in step 1706 of the new registration / change process in FIG. And the place data list 116 and the place data list cache 124 are changed (step 2108).
Next, it is checked whether or not step 2108 is successful (step 2109). If it has failed, the process ends without doing anything. If successful, check 504 of the corresponding row of the Place Data List Cache 124 is set to yes, and Synced of the corresponding row of the Local Cash List 123 is set to yes (step 2110).
As a result, the versions of the fragment files on all the net storage services are synchronized with valid versions.

In step 1904, after the PP synchronization process described above is completed, the synchronization process of FIG. 19 is terminated.
As described above, the local synchronization process and the inter-PP synchronization process described above are realized by the synchronization process performed in the connection monitoring management loop process of FIG. 12 started in the startup process of FIG.

FIG. 22 is a flowchart showing an outline of the end-time process that is step 606 in FIG.
First, for each row of the Local Cash List 123, it is checked whether or not a file whose Local 410 is Only exists (step 2201). If it exists, a screen for prompting the user to confirm whether the file synchronization processing is desired or forcibly terminated is output through the interface processing unit, and the user input is waited (step 2202).

Next, it is confirmed on the screen output in step 2202 whether or not the user desires synchronization processing (step 2203). If the user desires synchronization processing, the local synchronization processing shown in FIG. 20 is performed (step 2204). Then, the process returns to step 2201.
If there is no file whose Local 410 is “Only” in step 2201, or if it is desired to end without desiring synchronization processing in step 2203, the maintenance management loop processing started in the startup processing of FIG. 7 is stopped (step 2205). ).
Next, the network storage service whose State 306 is Online in the Place List 122 is disconnected, the State 306 is changed to Offline, all PWs 305 are left blank, and the password information is deleted (Step 2206).

Finally, the temporary file 125 in the temporary area 126, the fragment file 127 in the fragment file area 128, and the stored Place Data List Cache 124 and Local Cache List 123 are deleted. Further, the screen display is stopped and the client application 120 is terminated (step 2207).
As described above, after completion, there is no data that may leak information, such as a file, a fragment file, and a password for the net storage service.

100 client PC
101 Explorer 110 Net Storage Service Group 111 Net Storage Service 112 Provided by Company A Net Storage Service 113 Provided by Company B 113 Net Storage Service Provided by Company C 114 Storage Area on Net Storage Service 115 Fragment File on Net Storage Service 116 Place Data List
120 Client application 121 Interface processing unit 122 Place List
123 Local Cache List
124 Place Data List Cache
125 Temporary File 126 Temporary Storage Area 127 Fragment File on Client PC 128 Fragment File Storage Area 129 on Client PC Secret Sharing Processing Unit 130 Secret Integration Processing Unit 131 Communication Processing Unit 132 Synchronization Processing Unit

Claims (4)

A method for safely taking out file data held by a computer.
Dividing the file data into a plurality of fragment files using a threshold secret sharing method in the computer, sending the plurality of divided fragment files to a plurality of net storage services and holding them;
And a step of acquiring at least two of the plurality of fragment files held in the plurality of net storage services in the computer using the file data and restoring the original file data. How to take it out.   Checking that all of the net storage services are available, and performing fragment processing synchronization between the net storages if they are available, and resolving fragment file inconsistencies that occur when changing files, etc. The file data safe take-out method according to claim 1, further comprising: A system for safely taking out file data held by a computer.
Means for dividing the file data into a plurality of fragment files using a threshold secret sharing method; and means for transmitting the divided plurality of fragment files to a plurality of net storage services for holding the computer,
A file data safety characterized in that the computer using the file data comprises means for acquiring at least two of the plurality of fragment files held in the plurality of net storage services and restoring the original file data. Take-out system.   The computer checks that all of the net storage services are available, and if it is available, it performs fragment file synchronization processing between the net storages to eliminate fragment file inconsistencies that occur when files are changed. 4. The file data safe take-out system according to claim 3, further comprising means for performing the operation.

Images