Secret sharing systems, servers, and computer programs

Abstract

We provide secret sharing systems, servers, and computer programs that can enhance security between the storage where shares are stored and the client. [Solution] In a secret sharing system having a client 10, a first storage 30, a second storage 40, and a file management server 20, the client 10 transmits two or more shares generated by secretly sharing a plaintext file through secret sharing processing to the first and second storage 30 and 40. The file management server 20 stores information about files that users can view, edit, and delete, as well as the storage location of the shares. Based on the file information and share storage location information received from the file management server 20, the client 10 receives two or more shares from the first storage 30 and second storage 40, which are the share storage locations, and decrypts the received two or more shares within the client.

Description

Technical Field

[0001] The present invention relates to a secret sharing system for managing files by secret sharing, a server constituting the secret sharing system, and a computer program executed on the server.

Background Art

[0002] In recent years, due to the increasing awareness of information security, "secret sharing" has attracted attention, which divides data into a plurality of parts called encrypted "shares" and distributes and stores these shares on a plurality of servers (for example, Patent Document 1). Secret sharing is a technology that divides data into a plurality of parts (shares) and stores each part in a different location so that the original data cannot be restored from a single share. This mechanism occupies an important position in the field of information security, and in recent years, research and implementation have been progressing in various application fields. With the spread of cloud computing, the practicality of secret sharing has attracted attention. In cloud services, many companies and individuals store sensitive data, and their security is a concern. Secret sharing is an effective means to reduce the risk caused by attacks and failures of a single provider by dispersing data among a plurality of cloud providers. By this method, it becomes possible to securely manage data that requires a high level of confidentiality, such as personal information, medical data, and financial data.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in conventional secret sharing systems, the client sends files as plaintext data to storage such as a server, where the storage distributes the files to multiple shares. The server then decrypts the files from the multiple shares and sends the decrypted files back to the client as plaintext data. As a result, files are transmitted and received between the server and client in plaintext format, which poses security risks such as eavesdropping.

[0005] The present invention aims to provide a secret sharing system, server, and computer program that can enhance security between the storage where shares are stored and the client. [Means for solving the problem]

[0006] The present invention is essentially a secret sharing system described in any of the following (1) to (6). (1) A secret sharing system comprising a client, a first storage, a second storage, and a file management server, wherein the client comprises secret sharing processing means for secretly sharing a plaintext file and generating two or more shares by secret sharing processing, and client transmission means for transmitting the two or more shares generated by the secret sharing processing means to the first storage and the second storage, respectively; the first storage comprises first storage storage means for storing the shares transmitted by the client transmission means, and first storage transmission means for transmitting the shares stored in the first storage storage means to the client; the second storage comprises second storage storage means for storing the shares transmitted by the client transmission means, and the shares stored in the second storage storage means to the client A secret sharing system comprising: a second storage transmission means for transmitting to an agent; a file management server comprising: a server storage means for storing information about files that users can view, edit, or delete, and the storage location of shares of said files; a server transmission means for transmitting the information about the files and the storage location of the shares to the client; the client comprising: a receiving means for receiving the information about the files and the storage location of the shares from the file management server; and a secret sharing processing means for decrypting the two or more shares received by the receiving means within the client by secret sharing processing. (2) The secret sharing system described in (1) above, wherein the file management server stores user information and a list of files that the user can view, edit, or delete, and when the user information is transmitted from the client to the file management server, the server identifies the user and transmits a list of files that the user can view, edit, or delete to the client. (3) The secret sharing system according to (1) above, wherein the client launches a browser and performs secret sharing processing on the browser to secretly share a plaintext file and generate the two or more shares, and / or decrypts the two or more shares that have been received within the client. (4) The secret sharing system according to (1) above, wherein the file management server stores information about the storage location of the share, the client obtains information about the storage location of the share from the file management server, and obtains the share from the first storage and / or second storage which are the storage locations of the share based on the obtained information about the storage location of the share. (5) The secret sharing system described in (1) above, wherein the file management server also serves as the first storage or the second storage. (6) The secret sharing system described in (1) above, wherein the client also serves as the first storage or the second storage. Furthermore, the present invention is summarized in (7) below. (7) A server that communicates with a client capable of distributing a file to multiple shares by secret sharing processing and manages the file that the client has secretly shared, the server comprising: a storage means for storing information of the storage locations of the shares; a receiving means for receiving a request from the client for information of the storage locations of the shares; and a transmitting means for transmitting to the client the information of the storage locations of the shares stored in the storage means when the request is received. Furthermore, the present invention is essentially based on the computer program described in (8) below. (8) A computer program that communicates with a client capable of distributing a file to multiple shares by secret sharing processing, and is executed on a server that manages the secretly shared file by the client, the computer program causing the server to execute a storage function that stores information of the storage locations of the shares in the server's storage unit, a receiving function that receives a request from the client for information of the storage locations of the shares, and a transmitting function that, upon receiving the request, transmits the information of the storage locations of the shares stored in the storage means to the client. [Effects of the Invention]

[0007] According to the present invention, security between the storage where shares are stored and the client can be enhanced. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagram illustrating the configuration of the secret sharing system according to this embodiment. [Figure 2] This diagram illustrates the process of secretly sharing a file into two or more shares using secret sharing (AONT transformation). [Figure 3] This diagram illustrates the process of decrypting a file using secret sharing (inverse AONT transformation) from two or more shares. [Figure 4] This diagram illustrates the information managed by the file management server. [Figure 5] This diagram illustrates the file management initiation process according to this embodiment. [Figure 6] This is a diagram illustrating the file registration process according to this embodiment. [Figure 7] This is a diagram illustrating the file acquisition process according to this embodiment. [Figure 8] This diagram illustrates the file deletion process according to this embodiment. [Figure 9] This figure shows an example of a file list screen. [Figure 10]This figure shows an example of a file sharing settings screen. [Modes for carrying out the invention]

[0009] An embodiment of the secret sharing system according to the present invention will be described with reference to the figures. Figure 1 is a configuration diagram showing the secret sharing system 1 according to this embodiment. As shown in Figure 1, the secret sharing system 1 according to this embodiment consists of a client 10, a file management server 20, a first storage 30, and a second storage 40. As shown in Figure 1, the client 10 can communicate with the file management server 20, the first storage 30, and the second storage 40 via the internet 2.

[0010] Note that while Figure 1 illustrates a configuration with only one client 10, the system is not limited to this configuration and can have multiple clients 10. Also, while Figure 1 illustrates a configuration with a first storage 30 and a second storage 40, it can also have a configuration with three or more storages. Furthermore, while the example shown in Figure 1 illustrates a configuration in which secret sharing is performed using two shares, share A stored in the first storage 30 and share B stored in the second storage 40, it is also possible to have a configuration in which secret sharing is performed using three or more shares, for example, share A stored in the first storage 30, share B stored in the second storage 40, and share C stored in a third storage (not shown).

[0011] In this embodiment, the user can execute the file management process according to this embodiment on the browser 11 launched on the client 10. Specifically, the user creates and saves a plaintext file on the browser 11, or uploads a plaintext file onto the browser 11. Thereby, the browser 11 secretly distributes the plaintext file into a plurality of shares by secret sharing processing, and transmits and stores them in the first storage 30 and the second storage 40 respectively. While the file created by the user is unencrypted plaintext data, the secretly distributed shares are fragments that do not make sense alone, and the original information (file) cannot be restored unless a predetermined number or more of the fragments are gathered.

[0012] Also, when the user views or edits a file, the user specifies the file to be viewed or edited on the browser 11, and the browser 11 can respectively obtain shares from the first storage 30 and the second storage 40, and decrypt the file by secret sharing processing based on the obtained plurality of shares. The user can view and edit the decrypted file on the client 10. When the file is edited, the edited file can be safely stored in the first storage 30 and the second storage 40 by secretly distributing it into shares again by the browser 11 through secret sharing processing.

[0013] As described above, in this embodiment, since information is transmitted and received between the client 10 (browser 11) and the first storage 30 and the second storage 40 in the form of encrypted shares, in this embodiment, security risks such as eavesdropping can be reduced between the client 10 (browser 11) and the first storage 30 and the second storage 40. Note that in this embodiment, the file management server 20 has information such as information on files available to the user and information on storage locations of shares, and the client 10 can execute the file management process by referring to this information managed by the file management server 20. The configuration of the secret sharing system according to this embodiment will be described below.

[0014] The client 10 is an information terminal device such as a personal computer, a smartphone, or a tablet operated by a user, and has an arithmetic unit, a storage device, a display, and a communication device. The client 10 stores a program for the browser 11 in the storage device, and by executing the program for the browser 11 with the arithmetic unit, the browser 11 is launched, and the file management process according to the present embodiment can be executed using the browser 11.

[0015] In the present embodiment, the browser 11 reads a program described in HTML / CSS or the like, and displays a website for executing the file management process according to the present embodiment on the display of the client 10. Also, the browser 11 can execute the file management process according to the present embodiment by executing a program described in JavaScript (registered trademark) or the like. In particular, in the present embodiment, a program for executing a process of secret sharing a plaintext file by secret sharing to generate two or more shares and a process of decrypting two or more shares in the client is described in JavaScript, and by executing the program, secret sharing by secret sharing can be executed on the browser 11.

[0016] The programs described in HTML / CSS / JavaScript or the like used in the secret sharing service according to the present embodiment are stored in the file management server 20 or a web server not shown, and the browser 11 can execute the file management process by reading the programs from the file management server 20 or the web server via the Internet 2. Note that the programs can also be incorporated in advance as a part of the program for the browser 11 (add-in), or can be configured to be downloaded and stored in advance in the storage device (also referred to as local) of the client 10 (add-on).

[0017] Furthermore, the browser 11 is not particularly limited as long as it can execute programs written in HTML / CSS / JavaScript, etc., and any publicly available and usable browser can be used. As described above, in this embodiment, the browser 11 can execute a secret sharing program written in JavaScript, thereby distributing a file containing plaintext data into multiple shares and storing them in the first storage 30 and the second storage 40, and receiving the shares stored in the first storage 30 and the second storage 40, respectively, and generating a file of plaintext data from these multiple shares.

[0018] In this embodiment, the secret sharing process can be performed, for example, by the method described in International Publication No. 2019 / 225735. Here, Figure 2 is a diagram illustrating the secret sharing process according to this embodiment, and is a diagram illustrating the process of secretly sharing a file of plaintext data into multiple shares (AONT transformation). As shown in Figure 2, the browser 11 segments the file of plaintext data into multiple input blocks x[1], x[2], ... x[n], each having a first block length l. The first block length l is equal to the block length specific to the block cipher type symmetric key encryption scheme (for example, 128 bits for AES). Next, a random bit sequence K is generated with a bit length (for example, 256 bits) equal to an integer multiple of the first block length l (2 times in the example shown in Figure 2). Then, browser 11 uses a key based on a random bit sequence K to encrypt each input block x[1], x[2], ... x[n] using a block cipher type symmetric key encryption scheme (for example, AES), and derives encrypted intermediate blocks x'[1], x'[2], ... x'[n].

[0019] Next, the browser 11 concatenates the intermediate blocks x'[1], x'[2], ...x'[n] to form output blocks y[1], y[2], ...y[m-1], each having a second block length (for example, 256 bits). Here, p consecutive intermediate blocks (two each in the example shown in Figure 2) are selected and concatenated together. Then, the browser 11 calculates the exclusive OR between all the formed output blocks y[1], y[2], ...y[m-1] and the random bit sequence K to derive a further output block y[m]. Next, the browser 11 concatenates the output block y[m] derived by calculating the exclusive OR between the iteratively formed output blocks y[1], y[2], .... y[m-1] and the random bit sequence K to form the encrypted bit sequence y[1] / y[2] / .... y[m-1] / y[m] (where " / " indicates concatenation). The browser 11 then distributes the encrypted bit sequence y[1] / y[2] / .... y[m-1] / y[m] into two or more distributed bit sequences FG1, FG2, .... each containing at least one of the output blocks. Each distributed bit sequence FG1, FG2, .... becomes a share and is sent to the first storage 30 and the second storage 40 for storage. After the AONT transformation is complete, the browser 11 erases the random bit sequence K.

[0020] Figure 3 is a diagram illustrating the secret sharing process according to this embodiment, and is a diagram illustrating the process of recovering a file of plaintext data from multiple distributed shares (inverse AONT transformation). Browser 11 concatenates two or more distributed bit sequences (corresponding to shares) FG1, FG2, ... associated with the file to be recovered to form an encrypted bit sequence FG1 / FG2 / ... Browser 11 also segments the encrypted bit sequence FG1 / FG2 / ... into multiple input blocks y[1], y[2], ... y[m-1], y[m] having a second block length (for example, 256 bytes).

[0021] Next, the browser 11 calculates the exclusive OR of the segmented input blocks y[1], y[2], ... y[m-1], y[m] to reconstruct the random bit sequence K. The reconstructed random bit sequence K may be the same as the key used to decrypt each block using a symmetric key cryptography scheme. Alternatively, the random bit sequence K may be a larger bit sequence that partially contains the key used to decrypt each block. Next, the browser 11 separates the above-mentioned input blocks y[1], y[2], ... y[m-1] into a predetermined number of intermediate blocks x'[1], x'[2], ... x'[n] (two of each in the example shown in Figure 3). As a result, the block length of the intermediate blocks becomes equal to the first block length l. Furthermore, browser 11 decrypts the intermediate blocks x'[1], x'[2], ... x'[n] using a symmetric key cryptography scheme with a key based on the recovered random bit sequence K, deriving a predetermined number of output blocks x[1], x[2], ... x[n]. Then, browser 11 concatenates the multiple output blocks x[1], x[2], ... x[n] to recover the original bit sequence, which is the plaintext data file. Finally, once the AONT inverse transform is complete, browser 11 erases the random bit sequence K.

[0022] Note that the secret sharing process shown in Figures 2 and 3 is just an example and does not necessarily have to be executed in the order shown. For example, some processing steps may be executed in parallel. Additional processing steps may also be used, and some processing steps may be omitted.

[0023] Thus, the secret sharing process (modified CTRT method) according to this embodiment eliminates the constraint of k ≤ l between block length l and key length k that existed in the existing CTRT method, making it possible to implement AON transform / inverse transform using a combination of block cipher encryption scheme and key length that provides stronger security. Furthermore, the secret sharing process according to this embodiment, like the existing CTRT method, does not involve computationally expensive processes such as hash value expansion required by the OAEP method, and the increase in data size of the encrypted bit sequence relative to the original bit sequence is only the amount of padding bits plus the amount of one output block (y[m] in the example shown in Figure 2). Therefore, the secret sharing process according to this embodiment allows for the selection of a longer key length and achieves stronger security while maintaining the advantage of the AON method, which is that it is easy to use in various systems or devices that have resource limitations in various aspects such as processing power, communication performance, or storage capacity.

[0024] Furthermore, in the secret sharing process according to this embodiment, if the encryption method is AES (Advanced Encryption Standard) which has a unique block length of 128 bits, an encryption key with a key length of 256 bits is selected. In this case, the key length k is exactly twice the block length l. Therefore, during the AONT transformation, by concatenating two intermediate blocks after AES encryption at a time to form output blocks, the encryption key can be easily spread and concealed throughout the entire message through the exclusive OR operation between these output blocks and the encryption key. In addition, the repeated concatenation / separation of bit sequences in block units and the exclusive OR operation are suitable for high-speed sequential processing on general-purpose processors or for further speedup through parallelization.

[0025] Furthermore, in the secret sharing system 1 according to this embodiment, plaintext data cannot be decrypted unless a specific number of secretly shared shares are available. Even if shares are leaked in only one of the first storage 30 or the second storage 40, if the other share is not leaked, the plaintext data cannot be decrypted, thus ensuring the confidential state.

[0026] Furthermore, the client 10 can exchange information with the file management server 20 via the Internet 2, obtain file management information associated with the user from the file management server 20, and execute the file management process according to this embodiment based on this file management information. Details of the file management process according to this embodiment will be described later.

[0027] The file management server 20 has a processing unit, a storage device, a communication device, and a database 21, and stores multiple tables for file management in the database 21. Here, Figure 4 is a diagram illustrating an example of the tables stored by the file management server 20. In this embodiment, as shown in Figure 4, the file management server 20 stores a user management table, a file attribute management table, and an access management table. The following describes each table stored by the file management server 20.

[0028] The user management table is a table that holds user management information. As shown in Figure 4, the user management information held in the user management table includes the user identification number, login ID, password, and user type. The user identification number is unique to each user and is a number arbitrarily set by the secret sharing system 1. In addition, as shown in Figure 4, the user identification number is also included in the file attribute management table, making it possible to manage the file attributes of the user via the user identification number. The login ID and password are information that the user registers in advance and are associated with the user identification number. In this embodiment, when a user enters their login ID and password on the login screen displayed in the browser 11, the entered login ID and password are sent to the file management server 20 and the user is authenticated. Furthermore, the user type is information that indicates whether the user is a regular user or an administrator.

[0029] The file attribute management table is a table that holds file attribute information and is created for each file. As shown in Figure 4, the file attribute information held in the file attribute management table includes the user identification number, file identification number, file identification number sub-number, file name, latest upload date and time, last download date and time, file creation date and time, file modification date and time, and storage location information for each share. Similar to the user management table, the file attribute management table has a user identification number, so it is possible to identify the file attribute information of files owned by the user accessed from the browser 11 of client 10. In particular, in this embodiment, in order to create a file list screen for the user to select files to view, edit, or delete and display it on client 10, file management information for all files associated with the user, specifically the file identification number, file identification number sub-number, file name, latest upload date and time, last download date and time, file creation date and time, file modification date and time, etc., is sent to client 10, and the browser 11 creates the file list screen based on this file management information.

[0030] Furthermore, in this embodiment, even for the same file, each time it is updated, the file management server 20 assigns a different file identification number sub-number, and creates a new file attribute information table with the latest upload date and / or last download date and time. This enables the file management server 20 to manage user files in a log. In addition, the file attribute management table contains information on the storage location of each share in which the files associated with the user are secretly shared. Based on this information, the client 10 can obtain the share corresponding to the user's file from the first storage 30, the second storage 40, etc.

[0031] The access management table is a table that holds access management information and is created for each file. The access management information held by the access management server includes the file identification number, the file identification number sub-number, the user identification number of the user who is allowed access, and access level information. As shown in Figure 4, the access management table, like the file attribute management table, holds information on the file identification number and the file identification number sub-number, making it possible to manage file access on a per-user and per-file (sub-number) basis. Furthermore, the user identification number that is allowed access is not limited to the user who created the file, but can also be the user identification number of any user who can view, edit, or delete the file, making it possible to share a file among multiple users. In addition, the access level information sets which operations, such as viewing, editing, and deleting, the user corresponding to the user identification number can perform according to the level. For example, level 1 can be set to allow viewing only, level 2 to allow viewing and editing, and level 3 to allow viewing, editing, and deletion.

[0032] The file management server 20 can support the file management process performed by the client 10 by sending this file management information to the client 10 in response to the client's request.

[0033] The first storage 30 and the second storage 40 are devices for storing shares created by the client 10, and are not particularly limited as long as they have storage capabilities. They can be servers such as file servers, storage devices such as NAS, information terminals such as PCs, tablets, smartphones, or storage media such as USB memory. Furthermore, if the first storage 30 and the second storage 40 are servers, they may be cloud servers or on-premises servers.

[0034] Furthermore, the configuration can be configured so that the file management server 20 provides either the first storage 30 or the second storage 40, resulting in a configuration with only a single storage, or so can be configured so that the client 10 also provides either the first storage 30 or the second storage 40. For example, the client 10 can store share A as the first storage 30, and the file management server 20 can store share B as the second storage 40.

[0035] The first storage 30 and the second storage 40 can receive shares from the client 10 and store those shares in their respective storage devices. Furthermore, the first storage 30 and the second storage 40 can be configured to transmit the shares stored in their storage devices to the client 10 upon request from the client 10.

[0036] Next, the file management process according to this embodiment will be described. Figures 5-8 are diagrams illustrating the file management process according to this embodiment. Specifically, Figure 5 shows the flow of the file management start process, Figure 6 shows the flow of the file registration process, Figure 7 shows the flow of the file retrieval process, and Figure 8 shows the flow of the file deletion process. The file management start process shown in Figure 5 is the first process performed regardless of whether the user registers a new file, views it, edits it, or deletes it. When the user registers a new file, the file registration process shown in Figure 6 is performed. Furthermore, when the user views a file, the file retrieval process shown in Figure 7 is performed. In addition, when the user edits a file, the file retrieval process shown in Figure 7 is performed, and after the user edits the retrieved file on the client 10, the file registration process shown in Figure 6 is performed. Furthermore, when the user deletes a file, the file deletion process shown in Figure 8 is performed. Each process will be described below.

[0037] The file management initiation process shown in Figure 5 is the process from when the user logs into the secret sharing system 1 according to this embodiment until the file list screen for the user to manipulate files is displayed. As shown in Figure 5, the file management initiation process according to this embodiment will be explained separately for the user operating the client 10, the browser 11 executed on the client 10, and the file management server 20.

[0038] In step S101, the user operates the client 10 to launch the browser 11. Then, in step S102, the user operates the client 10 to input (specify) the URL of the file management server 20 according to this embodiment, causing the client 10 to access the file management server 20 via the internet 2. As a result, in step S103, the login screen information is sent from the file management server 20 to the client 10, and the login screen is displayed on the browser 11.

[0039] In step S104, the user operates the client 10 and enters their user ID and password on the login screen displayed in the browser 11. In step S105, the user ID and password entered in the browser 11 are sent from the client 10 to the file management server 20. Then, in step S106, the file management server 20 authenticates the user based on the received user ID and password. User authentication can be performed using a publicly known method. Once the user is authenticated, the process proceeds to step S107, where the file management server 20 sends information about the file list screen associated with that user to the client 10, and it is displayed on the browser 11 of the client 10.

[0040] Figure 9 shows an example of a file list screen. The file list screen is displayed in browser 11. As shown in Figure 9, the file list screen includes information such as the file name, upload time, size, and type of files to which the user has access rights. The file type can be set as appropriate, including information about the file type.

[0041] In this way, the file list screen allows the user to select files to view, edit, or delete from among the files they can access. Furthermore, the user can also register files they have created locally for management by the secret sharing system according to this embodiment by dragging and dropping the created file onto the file list screen displayed in the browser 11, or by pressing the "File Upload" button shown in Figure 9 and selecting the file to upload. The following describes the processes shown in Figures 6-8 that are executed when the user registers, views, edits, or deletes a file after the file management start process shown in Figure 5 has been executed. In the following description, it is assumed that of the shares of the file the user views, edits, or deletes, share A is stored in the first storage 30 and share B is stored in the second storage 40.

[0042] First, the file registration process shown in Figure 6 will be explained. First, the user instructs the browser 11 to register a new file (step S201). As a result, the browser 11 obtains file attribute information such as the user identification number, file identification number, file identification number sub-number, file name, latest upload date and time, file creation date and time, file update date and time, and share storage location (step S202), and sends the obtained file attribute information from the client 10 to the file management server 20 (step 203). As a result, the file management server 20 stores the file attribute information of the file to be registered (step S204). When registering a new file, the file identification number sub-number is set to "1". In addition, in this embodiment, there is a separate screen where the user sets where to store the file's share, and the information of the share storage location set on that screen is included in the file attribute information.

[0043] In step S206, the browser 11 performs secret sharing of the file that the user intends to register. This distributes the file that the user intends to register between share A and share B. Next, based on the share storage location information received in step S205, the browser 11 sends share A to the first storage 30 (step S207) and share B to the second storage 40 (step S208). As a result, share A is stored in the first storage 30 (step S209) and share B is stored in the second storage 40 (step S210). Then, the file management server 20 sends information about the file list display screen with the newly registered file to the client 10, causing the browser 11 to update the file list display screen displayed on the display (step S211).

[0044] Next, the file retrieval process shown in Figure 7 will be explained. In step S301, the user selects a file to retrieve from the file list screen displayed in the browser 11 during the file management start process shown in Figure 5. The user can select a file to retrieve by operating the client 10 and clicking on the displayed file on the browser 11. In step S302, the client 10 (browser 11) sends the file identification number of the file selected by the user in step 301 to the file management server 20. In step S302, the user's user identification number is also sent along with the file identification number. As a result, in step S303, the file management server 20 refers to the access rights table stored in the file management server 20 based on the file identification number and user identification number received in step S302, and verifies the user's access rights.

[0045] If, in step S303, it is determined that the user has permission to view, edit, etc., then in step S304, the file management server 20 sends information about the storage locations of shares A and B of the file specified by the user to the client 10. Based on the information about the storage locations of shares A and B obtained, the client 10 (browser 11) sends a request for share A to the first storage 30 (step S305) and a request for share B to the second storage 40 (step S306). As a result, the first storage 30 sends share A to the client 10 (step S307), and the second storage 40 sends share B to the client 10 (step S308). In step S309, the client 10 performs secret sharing processing on the browser 11 and decrypts the file specified by the user from the received shares A and B. Then, in step S310, the file decrypted by the browser 11 is downloaded locally to the client 10, and the client 10 can view, edit, etc. If the user wishes to save the acquired file after editing it, the process will then proceed from step S201 of the file registration process shown in Figure 6.

[0046] Next, the file deletion process shown in Figure 8 will be explained. Steps S401 to S403 are the same as steps S301 to S303 shown in Figure 7. From the file list screen displayed in the browser 11, the user selects the file to be deleted (step S401). The file identification information of the selected file is sent from the client 10 to the file management server 20 (step S402), and the access rights are confirmed at the file management server 20 (step S403). Before the process in step S402, a screen asking the user to confirm whether it is OK to delete the file can be displayed on the browser 11, and the process can proceed to step S402 if the user confirms.

[0047] If it is determined that the user has permission to delete the file, the process proceeds to step S405, where the file management server 20 obtains file attribute information, such as the storage location of the share of the file to be deleted. Then, based on the file attribute information, the file management server 20 sends an instruction to delete share A to the first storage 30 (step S406) and an instruction to delete share B to the second storage 40 (step S407). As a result, share A is deleted by the first storage 30 (step S408) and share B is deleted by the second storage 40 (step S409). Next, in step S410, the file management server 20 sends information about the file list display screen after the file has been deleted to the client 10, and the browser 11 updates the file list display screen displayed on the display.

[0048] Furthermore, users can share files managed by the file management system 1 with other users by pressing the "Share" button provided for each file as shown in Figure 9. For example, when a user presses the "Share" button shown in Figure 9, the browser 11 displays the file sharing settings screen as shown in Figure 10. On the file sharing settings screen shown in Figure 10, the user specifies the other users with whom to share the file and their access levels. By pressing the "Share" button on this screen, the browser 11 can configure the selected other users to access the file. Specifically, by specifying the other users with whom to share the file and their access levels on the file sharing settings screen shown in Figure 10, the browser 11 sends an instruction to the file management server 20 to add the other users to the access management table. More specifically, if the file to be shared is the target file and the other users with whom to share the file are the target users, the browser sends an instruction to the file management server 20 to add the file identification number and file identification sub-number of the target file, the user identification number of the target users with whom to share the file, and their access levels to the access management table, as shown in Figure 4. As a result, the file identification number and file identification sub-number of the target file, the user identification number of the user sharing the file, and the access level are set on the file management server 20. When the target user accesses the file list screen in the browser 11 using their login ID / password and displays the file list screen, the newly shared file will be displayed on the file list screen, and they will be able to view, edit, delete, etc., according to their access level. Figure 10 is an example of a file sharing settings screen, showing a scenario where a file has already been shared with "testuser01" and is also being shared with another user, "admin".

[0049] The file management process described above is merely an example and is not limited to the method described above. For example, in the file retrieval process shown in Figure 7, the file management server 20 sends the storage locations of Share A and Share B to the client 10, and the browser 11 of the client 10 sends a request to the first storage 30 and the second storage 40 to retrieve the shares. However, the configuration is not limited to this, and for example, the file management server 20 can directly send a request to the first storage 30 and the second storage 40 to send the shares to the client 10. Also, in the file deletion process shown in Figure 8, the file management server 20 instructs the first storage 30 and the second storage 40 to delete the shares. However, the file management server 20 also sends the storage locations of Share A and Share B to the client 10, and the browser 11 of the client 10 sends a request to the first storage 30 and the second storage 40 to delete the shares.

[0050] The type of data protected by the secret sharing system 1 according to the present invention is not particularly limited, but because the present invention offers high security, it is particularly effective for data requiring a high level of confidentiality, such as medical data, financial data, and personal data, as will be described later. Furthermore, the secret sharing system 1 according to the present invention can be used in various business models, for example, in security-focused cloud storage services in the SaaS model, license management services that license patented technology to cloud providers and enterprise solution providers, and services that deploy end-user applications such as personal data protection apps. In particular, the secret sharing system 1 according to the present invention can achieve a higher level of security and efficiency compared to other distributed storage technologies (for example, IPFS and redundant distributed storage methods), and can therefore provide a higher level of security in the above-mentioned services.

[0051] Specifically, examples of how the secret sharing system 1 according to this embodiment can be applied to medical data, financial data, and personal data will be illustrated and explained.

[0052] (1) Examples of application to medical data (1-1) Electronic health records (EHR) management Medical institutions manage patients' electronic medical records as digital data, which is highly confidential. By using the secret sharing system 1 according to this embodiment, patient data can be divided into multiple shares and distributed and stored across multiple storage devices, including the first storage 30 and the second storage 40, thereby enhancing the security of patient data. Specifically, even if one of the first storage 30 or the second storage 40 is hacked and a share of patient data is leaked, the patient data cannot be decrypted using only that share, thus preventing data leakage. In particular, the secret sharing system 1 can avoid a single point of failure (SPOF), improving resilience to cyberattacks and insider fraud, and increasing the reliability of the system. Furthermore, by using the secret sharing system 1 according to this embodiment, doctors and authorized personnel can select patient data files from the screen of the browser 11 on the client 10, allowing the browser 11 to collect shares of patient data, restore the patient data, and view, edit, delete, etc. Furthermore, it is believed that using the secret sharing system 1 according to this embodiment makes it easier to meet stringent data protection regulations such as GDPR (General Data Protection Regulation) and HIPAA (Human Health Information Privacy Regulation).

[0053] (1-2) Data sharing between medical institutions When sharing patient data among multiple medical institutions, protecting privacy and ensuring the secure transfer of patient data become challenges. By utilizing the secret sharing system 1 according to this embodiment, patient data can be securely shared among multiple medical institutions. Specifically, patient data can be securely shared by dividing it into shares and storing them separately in each medical institution's system. Furthermore, by setting a threshold (threshold t) for the number of shares required to restore the data, it is possible to limit the medical institutions that can restore the data to those authorized for access, so that patient data can only be restored when a certain number of medical institutions exchange shares (even if shares are leaked to a third party, it is possible to control the system so that the third party alone cannot restore the patient data). In addition, access authentication to patient data can be integrated into the access rights of the secret sharing system 1 according to this embodiment, allowing only medical professionals to restore patient data. Moreover, patient data shared among multiple medical institutions can be limited to the minimum necessary information. By limiting access, patient privacy can be protected. Furthermore, the secret sharing system 1 according to this embodiment can also manage file logs, making it possible to track who accessed which share (file).

[0054] (1-3) Telemedicine and medical research data management In telemedicine, patient data and diagnostic results are transferred and stored via the cloud, making it suitable for the highly secure secret sharing system 1 according to this embodiment. Furthermore, since medical research data (such as genetic information and clinical trial results) also requires secure management, secret sharing by the secret sharing system 1 according to this embodiment can be effectively utilized. Specifically, the secret sharing system 1 according to this embodiment can distribute and securely transmit data used in telemedicine. In addition, medical research data can be securely stored in the cloud or elsewhere through secret sharing, and access rights can be strictly managed to prevent unauthorized access, editing, or deletion of medical research data. Moreover, researchers can recover medical research data by logging in via a browser 11, even when located remotely, thus reducing infrastructure costs. In addition, the secret sharing system 1 according to this embodiment can strictly protect medical research data even when shared across multiple countries, thus complying with international data protection regulations and other legal regulations.

[0055] (2) Examples of application to financial data (2-1) Protection of customer data and enhanced privacy Customer data held by banks (personal information, transaction history, etc.) is highly confidential, but the secret sharing system 1 according to this embodiment uses secret sharing technology to securely store this customer data and prevent unauthorized access. For example, by dividing customer data into multiple shares and storing the customer data in physically different storage or cloud storage, the customer data can be stored securely. Furthermore, by storing some shares on the customer's own device (e.g., a smartphone), it is possible to prevent unauthorized viewing, editing, or deletion of customer data without the customer's consent. In addition, the secret sharing system 1 according to this embodiment allows for log management, making it possible to track access history to each share and detect and prevent unauthorized access. Moreover, since a certain number of shares are required to restore the distributed customer data, the risk of leakage due to unauthorized access is significantly reduced (even if some shares are leaked, customer data cannot be restored unless a certain number of shares are gathered), and privacy protection is enhanced. Furthermore, by using the secret sharing system 1 according to this embodiment, it becomes easy to build a system that complies with GDPR and financial industry privacy protection regulations.

[0056] (2-2) Data Security in Decentralized Finance (DeFi) In decentralized finance (DeFi), data security is crucial because assets are managed using smart contracts. The secret sharing system 1 according to this embodiment enhances data protection and transaction management of smart contracts by utilizing secret sharing technology. Specifically, important data contained within smart contracts can be divided into shares and stored securely, and transaction audits can be performed using the decentralized data to securely audit transaction history. Furthermore, log management is possible, allowing for the protection of confidential information without compromising transaction transparency. In addition, the secret sharing system 1 according to this embodiment can be integrated with existing distributed ledger technologies.

[0057] (3) Application to personal data (3-1) Password Management While password manager services centrally manage user passwords, this itself can pose a security risk. The secret sharing system 1 according to this embodiment uses secret sharing technology to enable more secure storage and management of password information. For example, each password can be divided into multiple shares and stored in different storage devices. The number of shares required for recovery can then be set, allowing only authenticated users to recover their passwords. Furthermore, even if some shares are leaked, the password data cannot be recovered until a certain number of shares are collected, thus reducing the risk of data leakage. In addition, because the secret sharing system 1 according to this embodiment has high security, it can improve service utilization rates and enhance user trust.

[0058] (3-2) Privacy protection in messaging apps Chat history and attachments in messaging apps contain private information, making user privacy protection crucial. The secret sharing system 1 according to this embodiment utilizes secret sharing technology to store conversation data more securely. For example, message data such as chat history can be divided into shares and stored on multiple servers. When a user opens a conversation, the necessary shares can be restored and displayed in real time. Furthermore, by distributing and storing shares across multiple servers, a single server cannot access the conversation content, thus enhancing privacy protection. Additionally, even if one server experiences a system failure, the data can be decrypted if a predetermined number of shares are available, thus increasing data reliability.

[0059] As described above, the secret sharing system 1 according to this embodiment includes a client 10, a first storage 30, a second storage 40, and a file management server 20. The client 10 includes a secret sharing processing means for secretly sharing a plaintext file and generating two or more shares through secret sharing processing, and a client transmission means for transmitting the two or more shares generated by the secret sharing processing means to the first storage 30 and the second storage 40, respectively. The first storage 30 includes a storage means for storing the shares transmitted by the client 10 and a transmission means for transmitting the shares stored in the storage means to the client 10. The second storage 40 also includes a storage means for storing the shares transmitted by the client 10 and a transmission means for transmitting the shares stored in the storage means to the client 10. Furthermore, the file management server 20 includes a storage means for storing information about files that can be viewed, edited, or deleted by the user, and the storage location of the shares of those files, and a transmission means for transmitting the file information and the storage location information of the shares to the client. In addition, the client 10 receives file information and share storage location information from the file management server 20, and further has receiving means to receive two or more shares from the first storage 30 and second storage 40, which are share storage locations, based on the received file information and share storage location information, and the secret sharing processing means of the client 10 decrypts the two or more received shares within the client by secret sharing processing. As a result, in the secret sharing system 1 according to this embodiment, files are communicated between the client 10 and the first storage 30 and second storage 40 as concealed shares, thereby enhancing the security of the entire system.

[0060] Furthermore, in the secret sharing system 1 according to this embodiment, by configuring the system to perform secret sharing using a browser 11, the file management processing according to the present invention can be performed without being tied to a specific terminal, compared to the case where a dedicated application for secret sharing is installed on the terminal. In other words, if a dedicated application for secret sharing is installed on the terminal, the secret sharing system 1 according to this embodiment cannot be used unless that terminal is used. However, in this embodiment, by configuring the system to perform secret sharing using a browser 11, the secret sharing system 1 according to this embodiment can be used on various models such as personal computers, smartphones, and tablets, and even when using different terminals.

[0061] Although preferred embodiments of the present invention have been described above, the technical scope of the present invention is not limited to the embodiments described above. Various modifications and improvements can be made to the above embodiments, and such modified or improved forms are also included in the technical scope of the present invention.

[0062] For example, in the embodiment described above, the client 10 is shown as having a configuration in which it performs secret sharing using a browser 11. However, the configuration is not limited to the above, as long as the client 10 processes files that are plaintext data. For example, the client 10 can be configured to perform secret sharing using an application installed on the client 10, a web application that can be run temporarily on the client 10, etc. In this case as well, the files will be communicated between the client 10 and the first storage 30 and the second storage 40 as an anonymized share, thereby enhancing the security of the entire system.

[0063] Furthermore, although the above-described embodiment illustrates a configuration in which the user determines the storage location of the share, the configuration is not limited to this, and it is possible to configure the file management server 20 to automatically determine the storage location of the share. [Explanation of symbols]

[0064] 1…Secret sharing system 10…Client 11…Browser 20…File management server 30...First Storage 40...Second Storage 2…Internet

Claims

1. A secret sharing system comprising a client, a first storage, a second storage, and a file management server, The aforementioned client, A secret sharing processing means that generates two or more shares by secretly sharing a plaintext file through secret sharing processing, The secret sharing processing means includes a client transmission means that transmits the two or more shares generated by the secret sharing processing means to the first storage and the second storage, respectively. The first storage is, A first storage means for storing the share transmitted by the client transmission means, The system includes a first storage transmission means that transmits the share stored in the first storage means to the client, The aforementioned second storage is A second storage means for storing the share transmitted by the client transmission means, The system includes a second storage transmission means that transmits the share stored in the second storage means to the client, The aforementioned file management server is A server storage means that stores information about files that users can view, edit, or delete, and the storage location of the shared files, The server includes a means for transmitting information about the file and information about the storage location of the share to the client. The aforementioned client, The system further includes receiving means that receive information about the files and the storage location of the shares from the file management server, and that receive two or more shares from the first storage and the second storage, which are the storage locations of the shares, based on the received information about the files and the storage location of the shares. The secret sharing processing means is a secret sharing system that decrypts the two or more shares received by the receiving means within the client by secret sharing processing.

2. In the aforementioned file management server, The server storage means stores user information and a list of files that the user can view, edit, or delete. The secret sharing system according to claim 1, wherein when the user information is transmitted from the client to the file management server, the system identifies the user and transmits to the client a list of files that the user can view, edit, or delete.

3. The secret sharing system according to claim 1, wherein the client launches a browser and performs secret sharing processing on the browser to secretly share a plaintext file to generate the two or more shares, and / or decrypts the received two or more shares within the client.

4. The aforementioned file management server stores information about the storage location of the share. The secret sharing system according to claim 1, wherein the client obtains information about the storage location of the share from the file management server, and obtains the share from the first storage and / or second storage which are the storage locations of the share based on the obtained information about the storage location of the share.

5. The secret sharing system according to claim 1, wherein the file management server also serves as the first storage or the second storage.

6. The secret sharing system according to claim 1, wherein the client also serves as the first storage or the second storage.

7. A server that communicates with a client capable of distributing files to multiple shares through secret sharing, and manages the files that the client has secretly shared, A storage means for storing information about the storage location of the aforementioned share, A receiving means for receiving a request from the client for information on the storage location of the share, A server having, upon receiving the aforementioned request, a transmitting means that transmits to the client information about the storage location of the share stored in the storage means.

8. A computer program that communicates with a client capable of distributing files to multiple shares through secret sharing, and is executed on a server that manages the secretly shared files of the client, A storage function that stores information about the storage location of the aforementioned shares in the storage unit of the server, A receiving function that receives a request from the client for information on the storage location of the share, A computer program that causes the server to execute a transmission function that, upon receiving the aforementioned request, transmits information about the storage location of the share to the client.

Images