Apparatus for secret sharing-based multi-party computation

Abstract

To further enhance safety for data leakage in operation of a secret dispersion base MPC.SOLUTION: A device is a device for taking part in multi-party calculation of a secret dispersion base. Original data can be restored by combining a share that the device has and a corresponding share that other device has. The device includes means for acquiring a random number, and means for updating the share of the device based on the acquired random number. An updating method in the updating means is designed so that influence by the random number is canceled and original data is restored by combining a share of the device updated based on the acquired random number and a corresponding share of the other device updated based on the random number.SELECTED DRAWING: Figure 13

Description

[Technical Field]

[0001] The present invention relates to an apparatus for holding shares used in secret sharing-based multi-party computation. [Background technology]

[0002] The Sustainable Development Goals (SDGs) are international goals that aim to create a sustainable and better world. The Ministry of Foreign Affairs of Japan is supporting the SDGs, as they are universal goals that not only developing countries but developed countries themselves should work towards.

[0003] While the use of so-called big data is recognized as a factor that contributes to achieving the SDGs, it is also recognized that there are risks to "human rights" and "privacy." If the use of big data can be achieved while protecting privacy, it is believed that social value can be created in addition to economic value.

[0004] One example of promoting data utilization is the provision of data to third parties. Data that could potentially identify individuals is often pseudonymized or anonymized. However, these methods force a trade-off between the usefulness of the data and confidentiality. In other words, users are forced to choose between prioritizing obtaining highly accurate aggregated results at the expense of strong privacy protection, or, conversely, prioritizing privacy protection and giving up on the accuracy of the aggregated results.

[0005] "Secure computation" is a technology that can resolve this trade-off problem and support the creation of economic and social value (see Non-Patent Document 1). Secure computation is a technology that enables calculations while keeping input values ​​hidden. This technology makes it possible to change the trade-off situation mentioned above into a trade-on.

[0006] Furthermore, in order to realize a data-driven society, the issue of data management responsibility within organizations is attracting significant attention. For example, there have been many cases of improper data handling by organizations in the past, and consumers, who are the data subjects, often have difficulty determining whether they can trust an organization to provide their data to. On the other hand, for organizations, the leakage of data accumulated through business or services can lead not only to economic losses but also to a loss of social credibility. Building a sustainable business environment requires not only efforts to increase trust through organizational capabilities or governance, but also fundamental technological innovation to prevent a decline in trust. "Secure computing" is one means that can contribute to this. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] URL: https: / / www.jstage.jst.go.jp / article / isciesci / 63 / 2 / 63_71 / _pdf, retrieved January 29, 2020 Summary of the Invention [Problem to be solved by the invention]

[0008] As mentioned above, the introduction of secure computing systems makes it possible to perform accurate data analysis while reducing the risk of data leaks. However, as seen in the various big data leak incidents that have occurred in recent years, attacks are becoming more sophisticated and large-scale, so further improvements in security are required.

[0009] The present invention has been made in light of these problems, and its purpose is to provide technology that can further improve security against data leakage in secret sharing-based multi-party computation (MPC), which is one type of secure computation. [Means for solving the problem]

[0010] One aspect of the present invention relates to an apparatus. The apparatus is an apparatus participating in secret sharing-based multi-party computation. Original data can be restored by combining a share held by the apparatus with corresponding shares held by other apparatuses. The apparatus includes: means for acquiring a share update random number, which is updated based on a predetermined rule, each time the share update random number is updated; and means for updating the apparatus's share based on the acquired share update random number. The updating method used by the updating means is designed so that, when the apparatus's share updated based on the acquired share update random number is combined with the corresponding shares of other apparatuses updated based on the share update random number, the influence of the share update random number is canceled out and the original data can be restored. The apparatus updates the apparatus's share by applying a first type of operation using the acquired share update random number, and the corresponding shares of the other apparatuses include shares updated by applying a second type of operation using the share update random number that is different from the first type of operation. Furthermore, the device includes means for storing the shares of the device in association with a value specifying the revision of the share, and the updating means performs processing to match the revision of the share of the device updated based on the acquired random number for share update with the revision of the corresponding share of the other device updated based on the random number for share update by communicating with the other device.

[0011] In addition, any combination of the above components, or mutual substitution of the components or expressions of the present invention between devices, methods, systems, computer programs, recording media storing computer programs, etc., are also valid aspects of the present invention. [Effects of the Invention]

[0012] According to the present invention, it is possible to further improve security against data leakage in secret sharing-based multi-party computation, which is one type of secure computation. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram showing 2-out-of-2 secret shared data. [Figure 2] FIG. 1 is a schematic diagram showing 2-out-of-3 secret shared data. [Figure 3] FIG. 1 is a schematic diagram of a system that realizes secret sharing-based MPC. [Figure 4]FIG. 10 is a schematic diagram for explaining the processing in an adder of secret sharing-based MPC. [Figure 5] FIG. 1 is a schematic diagram showing an overview of a Beavers triple used in a multiplier of secret sharing-based MPC. [Figure 6] FIG. 10 is a schematic diagram for explaining the processing in a multiplier of secret sharing-based MPC. [Figure 7] FIG. 1 is a schematic diagram illustrating an overview of a server-aided model. [Figure 8] FIG. 1 is a schematic diagram illustrating an overview of a client-aided model. [Figure 9] FIG. 10 is a schematic diagram illustrating a first pattern in which leakage occurs. [Figure 10] FIG. 10 is a schematic diagram illustrating a second pattern in which leakage occurs. [Figure 11] FIG. 1 is a schematic diagram for explaining the concept of secret sharing-based MPC according to an embodiment. [Figure 12] FIG. 1 is a schematic diagram illustrating the basis of security of the secret sharing-based MPC according to the present embodiment. [Figure 13] 1 is a schematic diagram showing the configuration of a secret sharing-based MPC system according to an embodiment. [Figure 14] FIG. 14 is a hardware configuration diagram of the environment A device in FIG. 13. [Figure 15] FIG. 14 is a block diagram showing the functions and configuration of the environment A device in FIG. 13. [Figure 16] 16 is a data structure diagram showing an example of a share holding unit in FIG. 15. [Figure 17] 16 is a data structure diagram showing an example of an access history storage unit in FIG. 15. [Figure 18] 14 is a chart showing the flow of a series of processes in the secret sharing-based MPC system of FIG. 13. [Figure 19] FIG. 1 is a schematic diagram illustrating an improvement in traceability by a secret sharing-based MPC system according to an embodiment of the present invention. [Figure 20] FIG. 1 is a schematic diagram for explaining an application example of secret sharing-based MPC according to the present embodiment. [Figure 21]FIG. 10 is a schematic diagram illustrating the concept of secret sharing-based MPC according to a modified example. [Figure 22] FIG. 22 is a schematic diagram showing changes in share values ​​corresponding to FIG. 21. [Figure 23] FIG. 10 is a diagram illustrating an example of a calculation process of a multiplier. [Figure 24] FIG. 11 is a diagram showing supplementary information for FIG. 10. [Figure 25] FIG. 10 is a diagram showing random number generation between two parties (flow from the perspective of environment A). [Figure 26] FIG. 1 is a diagram illustrating random number generation using the hash value of an Ethereum transaction. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, the same or equivalent components, parts, and processes shown in each drawing will be denoted by the same reference numerals, and redundant explanations will be omitted where appropriate. In addition, some parts that are not important for the explanation will be omitted in each drawing.

[0015] <Overview of secret sharing scheme> Secret sharing is a method in which data is divided into two or more parts, and the original data can be restored if a threshold (a certain number) or more of the divided data is collected. The divided values ​​are called "shares" or "tally points." The ISO standard for secret sharing technology is specified in ISO / IEC 19592-2:2017. The advantage of secret sharing is that each share is stored in a different memory area, making it impossible to restore the original data even if shares below the threshold are illegally obtained.

[0016] There are implementations of secret sharing schemes in which data is divided into N (N is an integer greater than or equal to 2) parts and the original data can be restored by collecting T (T is an integer greater than or equal to 2 and less than or equal to N) parts of the data; these are called threshold schemes. An example of a threshold scheme is T-out-of-N secret sharing (also known as (T, N) secret sharing). T-out-of-N secret sharing is a scheme in which confidentiality is maintained (= the secret will not be leaked) even if (T-1) of the N parts are stolen, and integrity is maintained (= the possibility of recovery is not compromised) even if up to (NT) parts are damaged.

[0017] Figure 1 is a schematic diagram showing data that has undergone 2-out-of-2 secret sharing. In this scheme, data 2 is divided into two shares, 4 and 6, and the original data 2 can be restored by collecting these two shares, 4 and 6. The following explains in detail how shares are generated in the case of additive secret sharing. Let d be the data 2 to be kept secret. First, a random number is generated and designated r. Let r be the first share (share 4). Let (dr) be the second share (share 6). In many cases, share values ​​are expressed as discrete data expressed over a finite field. Simply put, before sharing, a modulus value is determined, and the data is divided into the desired number of pieces using a random number. Each piece is then divided by the modulus value (modulo operation, % or mod) to obtain the share value. Typically, the remainder is omitted, and this specification follows this example with some exceptions. Adding the two shares together gives us share 4 + share 6 = r + (dr) = d, and data 2 (d) is successfully restored.

[0018] Figure 2 is a schematic diagram showing data that has been subjected to 2-out-of-3 secret sharing. In this scheme, data 8 is divided into three share pair values ​​10, 12, and 14, and the original data 8 can be restored by collecting two of these three share pair values ​​10, 12, and 14. We will now explain in detail how shares are generated in the additive secret sharing scheme. Let d be the data 8 that we want to keep secret. As in 2-out-of-2 secret sharing, divide data 8 into two shares. For simplicity, (r, dr) are called s1 and s2, respectively. Generate two random numbers locally and call them r1 and r2. For each environment, provide the following paired share values ​​(2-tuple). The paired values ​​passed to each environment alone cannot restore the original data8. (a1=s1+r1, a2=s2-r2) (b1=s1+r2, b2=s2-r1-r2) (c1=s1+r1+r2, c2=s2-r1) In this case, the original data 8 can be restored by adding together the pair values ​​of any two sets of environments. That is, a2+b1=s1+s2=d, a1+c2=s1+s2=d, b2+c1=s1+s2=d.

[0019] Note that secret sharing shares are not limited to addition and subtraction, and may be implemented by, for example, exclusive OR. In this case, the shares are divided into (random number Q) and (original data^random number Q) ("^" represents exclusive OR). When checked, (random number Q)^(original data^random number Q) = original data. In this specification, the expressions using addition and subtraction are used consistently.

[0020] <Overview of secret sharing-based multi-party computation> Secret sharing-based multi-party computation (MPC) is a method for achieving secure computation by using data that has been secretly shared for calculation, and is referred to as "secret sharing-based MPC" in this specification. In secret sharing-based MPC, functional completeness is achieved by providing adders and multipliers. For simplicity, the following explanation assumes an additive secret sharing scheme using addition and subtraction, rather than exclusive OR.

[0021] FIG. 3 is a schematic diagram of a system 16 that implements a secret sharing-based MPC. In the system 16 that implements a secret sharing-based MPC, an extremely large amount of communication occurs between the devices that perform the calculations. In the example of FIG. 3, a large amount of communication occurs between the P environment 18 and the Q environment 20, which share the secrets, to perform the secure calculations. Therefore, communication performance is a major factor that determines the performance of the secret sharing-based MPC. In this case, the issues are how to reduce the number of rounds, communication volume, and number of communications, and also how to improve the communication speed and parallelize the communication.

[0022] 4 is a schematic diagram illustrating the processing in an adder in secret sharing-based MPC. Two clients 22 and 24, which are secret providers (data collection platforms), have first secret data 26 and second secret data 28, respectively. The first client 22 divides the first secret data 26 in half to generate two shares 26a and 26b, and provides (e.g., uploads) these shares to a first device 30 (e.g., a server) and a second device 32 of the data analysis platform, respectively. The second client 24 divides the second secret data 28 in half to generate two shares 28a and 28b, and provides these shares to the first device 30 and the second device 32, respectively.

[0023] The first device 30 generates a first sum share 34a by adding the provided shares 26a and 28a. The second device 32 generates a second sum share 34b by adding the provided shares 26b and 28b. The user device 36 of the calculation results obtains and adds the first sum share 34a and the second sum share 34b to generate sum data 34. From the definition of a share, the sum data 34 is the sum of the first secret data 26 and the second secret data 28. In this way, the device 36 can calculate the sum of the first secret data 26 and the second secret data 28 without knowing these data.

[0024] Figure 5 is a schematic diagram showing the outline of the Beaver's Triple used in the multiplier of secret sharing-based MPC. A Beaver's Triple (BT) is a value that is discarded each time the multiplier is used. One set of BTs is discarded after each multiplication. Because reusing BTs could compromise security, they are not reused. BTs consist of a triplet (a, b, c) that satisfies c = a × b (c is the multiplication result of a × b). In the example shown in Figure 5, in an 8-bit environment (modulus 256), a = 47, b = 93, and c = 19. To facilitate understanding, c = 19 because (a × b) = (47 × 93) % 256 = 19 = c. Each value of the BT is randomly shared and then distributed to the device performing the calculation. In the example shown in Figure 5, c = 19 is divided into 187 and 88. Adding these two shares together gives us (187 + 88)%256 = 19, which restores the original c = 19. The same is true for a and b. Hereafter, the stage of generating BT is called the "offline phase." BT can also be created and stored in advance before the calculation is performed.

[0025] Figure 6 is a schematic diagram for explaining the processing in a multiplier of secret sharing-based MPC. BT is generated as a set of three values ​​38, 40, and 42 by BT generation in the offline phase.

[0026] The first client divides the first secret data in two to generate two shares 26a, 26b, which are provided to a first device 30 and a second device 32 of the data analysis platform, respectively. The second client divides the second secret data in two to generate two shares 28a, 28b, which are provided to the first device 30 and the second device 32, respectively. The first device 30 also obtains BT's shares 38a, 40a, 42a, and the second device 32 obtains BT's corresponding shares 38b, 40b, 42b.

[0027] As shown in FIG. 23, the first device 30 generates a first product share 44a by performing a predetermined process, including communication with the second device 32, on the provided shares 26a, 28a, 38a, 40a, and 42a. The second device 32 generates a second product share 44b by performing a predetermined process, including communication with the first device 30, on the provided shares 26b, 28b, 38b, 40b, and 42b. The first device 30 and the second device 32 communicate and share intermediate values ​​during the above arithmetic process. The device 36, the user of the calculation results, generates product data 44 from the first product share 44a and the second product share 44b. In this way, the device 36 can calculate the product of the first secret data and the second secret data without knowing them.

[0028] <Implementation model of secret sharing-based MPC> The model for generating BT can be categorized into several types. For example, as shown below, we can consider a device that has a share value of data to be kept secret and a third-party device that does not have a share value of data to be kept secret but assists in BT generation or calculation, and roughly classify them based on the role assigned to each. A model in which BT is generated only between two parties (for example, using oblivious transfer or homomorphic encryption). This model is relatively expensive in terms of computational complexity and communication. However, because the confidentiality of 2-out-of-2 secret sharing is maintained, it is more robust than the client-aided and server-aided models described below. Client-Aided: A model in which a third-party client generates BTs. In this model, the authority to generate BTs is delegated to the client, who is the data provider. The more clients that participate, the more decentralized the system is, and the computational load of generating BTs is distributed. As will be explained later, if two of the three parties, including the client, betray each other (i.e. cooperate in an attack), secrets can be leaked. In other words, this model has less confidentiality than a model in which BTs are generated between only two parties. Server-Aided: A model in which a third party, the server, generates BTs. In this model, in addition to the two parties responsible for the calculation, the authority to generate BTs is delegated to a third party. As with the client-aided model, if two of the three parties, including the server, betray their faith, secrets can be leaked. In other words, this model has less confidentiality than a model in which BTs are generated only between two parties.

[0029] 7 is a schematic diagram showing an overview of the server-aided model. In the server-aided model, a server 46 located in a third-party environment, different from the first device 30 and the second device 32, generates a BT (a set of values ​​38, 40, 42). The server 46 converts the generated BT into shares and provides one of the shares to the first device 30 and the other to the second device 32.

[0030] 8 is a schematic diagram showing an overview of the client-aided model. In the client-aided model, the first client 22 is authenticated by both the first device 30 and the second device 32. The authenticated first client 22 generates a BT (a set of values ​​38, 40, and 42). The first client 22 converts the generated BT into shares and provides one of the shares to the first device 30 and the other share to the second device 32.

[0031] <Conditions for ensuring the security of secret sharing-based MPC> In secret sharing-based MPC, there are two patterns in which the original data can be restored, i.e., the data can be leaked.

[0032] Figure 9 is a schematic diagram illustrating the first pattern in which leakage occurs. In the first pattern, an attacker collects both shares and restores the original data. For example, an attacker illegally obtains two shares (values: 189 and 80) generated by dividing the original data (value: 13). The attacker can restore the original data by combining these shares ((189 + 80) % 256 = 13).

[0033] Figure 10 is a schematic diagram illustrating the second pattern in which leakage occurs. In the second pattern, an attacker collects BT and the multiplication process during the multiplication process to restore the original data. As an example, Figure 24 specifically shows the restoration of a secret that occurs when the BT generator and environment A collude. The values ​​in Figures 10 and 24 are based on the values ​​in Figure 23.

[0034] Assume that original data 1 (value: 13) is split into share 1-1 (random value: 242) and share 1-2 (random value: 27), original data 2 (value: 17) is split into share 2-1 (random value: 213) and share 2-2 (value: 60), BT3 (random value: 11) is split into share 3-1 (random value: 56) and share 3-2 (value: 211), BT4 (random value: 205) is split into share 4-1 (random value: 240) and share 4-2 (value: 221), and BT5 (value: 207) is split into share 5-1 (random value: 129) and share 5-2 (value: 78). The attacker obtains the sum of shares 1-1 and BT3-1 ((242+56)%256=42), the sum of shares 1-2 and BT3-2 ((27+211)%256=238), the sum of shares 2-1 and BT4-1 ((213+240)%256=197), the sum of shares 2-2 and BT4-2 ((60+221)%256=25), as well as BT3 and BT4. At this time, the attacker can restore the original data 1 (value: 13) from the difference ((42+238-11)%256=13) between the sum of shares 1-1 and BT3-1 (calculation result: 42) and the sum of shares 1-2 and BT3-2 (calculation result: 238) and BT3 (value: 11). Similarly, the original data 2 (value: 17) can be restored from the difference between the sum of share 2-1 and BT4-1 (calculation result: 197) and the sum of share 2-2 and BT4-2 (calculation result: 25) and BT4 (value: 205) ((197 + 25 - 205) % 256 = 17).

[0035] In the client-aided and server-aided models, either of these two patterns is met when two of the three parties, including the creator of the BT, betray one another. In the model where BTs are generated only between two parties, this is met when two of the two parties betray one another.

[0036] <Concept of secret sharing-based MPC according to the embodiment> In the secret sharing-based MPC according to the embodiment, as a countermeasure against secret leakage due to collusion among participants in the calculation, the share values ​​are periodically updated in each environment participating in the secret sharing-based MPC, thereby improving security and traceability.

[0037] 11 is a schematic diagram illustrating the concept of secret sharing-based MPC according to an embodiment. In this embodiment, a random number generation mechanism 54 is provided that periodically (e.g., periodically) generates random numbers 56. The random numbers 56 generated by this random number generation mechanism 54 are different from the random numbers for generating shares described in FIGS. 1 and 2, and are also different from BTs. Hereinafter, the random numbers 56 generated by the random number generation mechanism 54 will be referred to as share update random numbers.

[0038] Figure 25 shows an example of how the random number generation mechanism 54 can be implemented. It is implemented between all environments that have the share values ​​necessary for decryption. Based on the format of Figure 11, this range is "all" refers to environment A and environment B, and for environment A, "everyone except itself" refers to environment B, and for environment B, "everyone except itself" refers to environment A. All devices randomly select a number (generate a random value). The number determined at this time is called the share update random number seed. After generating a public key and private key for public key cryptography (asymmetric key cryptography), an irreversible process such as a hash function is applied to the share update random number seed, and the output value is signed with the private key. The pair of signed value and public key is called the seed verification value.

[0039] First, a device sends a seed verification value to all devices other than itself. Then, when it receives seed verification values ​​from all devices other than itself, it associates each seed verification value with its sender and stores it. Once a device has received seed verification values ​​from all devices other than itself, it sends its own random number seed for share update to all devices other than itself. Once a device has received all random number seeds for share update other than itself, it authenticates the received random number seed for share update using the public key of the seed verification value, which has the same sender.

[0040] If any authentication fails, exception processing is initiated. As an example of exception processing, the share update processing may be stopped.

[0041] Conversely, if all authentications are successful, all received share update random number seeds are summed. This sum, or the output value obtained by applying an irreversible process such as a hash function to the sum, is called the provisional share update random number. The provisional share update random number is provided to all devices other than itself. At the same time, provisional share update random numbers are received from all devices other than itself. If all provisional share update random numbers match, this value is officially designated as the share update random number for the next update.

[0042] Here is an alternative to the procedure described above. One method is to have one of the environments, party K (where K is an integer between 1 and N) or another environment, such as a device responsible for generating or calculating BT, generate random numbers for share updates. However, if party K's environment or other environments collude and set the sum of the share values ​​associated with the secret under attack to an arbitrary value (e.g., 0) on a device on party K, the secret can be decrypted by combining the shares in the remaining (NK) environments. Taking Figure 11 as an example, if the share in environment A can be intentionally set to 0, the share in environment B can be made equivalent to the original data (= secret). In other words, if an attacker on environment A can warn someone on environment B before a share update that the secret will be restored in environment B after the next share update, an attacker on environment B can obtain the secret simply by accessing environment B after the next share update. The disadvantage of this situation is that a situation in which secrets can be leaked simply by accessing the environment where the secrets have been restored could be realized if an attacker intends to do so, invalidating the traceability that utilizes access history, as described below. Therefore, a method for generating random numbers that cannot be manipulated by the intentions of environments smaller than N is recommended. Of course, even if a random number is agreed upon by all N, as in the example above, a similar attack is possible if there is an attacker who can manipulate the random number in each environment within N. Therefore, it is most desirable for a random number that is equally accessible to all parties holding shares and obtained by a method that makes it difficult for the intentions of the parties holding shares to be involved, to be calculated (e.g., added or subtracted) with the total value of the random number seed for share updates. For example, as shown in Figure 26, if direct Internet connection is allowed from all environments, a method can be considered for obtaining random numbers from the hash values ​​of transactions held by a public chain such as Ethereum. To make the random number for share update unpredictable, all environments obtain the random number from a block height that is further in the future than the block height at which they receive the seed verification value, and after several blocks (Confirmations) have passed from that block height, all environments send and receive the random number seed for share update.

[0043] If the above concerns are accepted and it is acceptable to operate in a way that traces accesses that occur simultaneously in less than T locations out of N locations, then it is acceptable to use a random number generation method that can be agreed upon by less than N environments.

[0044] The original data 58 is divided into two shares 58a and 58b, which are then secretly distributed to different environments A and B. At a predetermined timing, environments A and B obtain the same share update random number 56 via a random number generation mechanism 54. Having obtained the share update random number 56, environments A and B communicate with each other and verify the share update random number 56. In other words, by mutually verifying the share update random number between all environments that hold shares, data corruption due to mismatches in the share update random number 56 can be prevented.

[0045] In environment A, the share update process involves adding the share update random number 56 to the share 58a to generate a new share 60a. In environment B, the share update process involves subtracting the share update random number 56 from the share 58b to generate a new share 60b. When the new share 60a of environment A and the new share 60b of environment B are added together, the influence of the share update random number 56 is offset and the original data 58 is restored. That is, Share 60a + Share 60b = (Share 58a + random number for share update 56) + (share 58b - random number for share update 56) = Share 58a + Share 58b = Original data 58 In this way, even if the shares are updated by the share update random number 56, the original data is not damaged and no problems occur in the secret sharing-based MPC.

[0046] In the secret sharing-based MPC according to this embodiment as shown in Fig. 11, the secret cannot be revealed unless attacks on both environments A and B are successful simultaneously, particularly within the same period (i.e., the period from the time of addition / subtraction to the same share update random number 56 until the next update occurs). This places strong constraints on attacks.

[0047] 12 is a schematic diagram illustrating the basis of security of the secret sharing-based MPC according to this embodiment. Assume that an attacker 62 successfully attacks environment B at a certain timing and obtains a share 58b that environment B holds at that timing. Then, assume that the attacker 62 successfully attacks environment A at a different timing across a share value update and obtains a share 60a that environment A holds at that different timing. The attacker 62 attempts to restore the original data 58 from the two acquired shares 58b and 60a, but fails to do so because the share value is updated by the share update random number 56. Thus, in the secret sharing-based MPC according to this embodiment, even if both shares are leaked, the original data cannot be restored if the leak timings are sufficiently different.

[0048] <Detailed Description of a System for Realizing Secret Sharing-Based MPC According to an Embodiment> 13 is a schematic diagram showing the configuration of a secret sharing-based MPC system 70 according to an embodiment. The secret sharing-based MPC system 70 includes a random number generation mechanism 54, an environment A device 72 provided in environment A, and an environment B device 74 provided in environment B. The random number generation mechanism 54, environment A device 72, and environment B device 74 communicate with each other via a network such as the Internet. Although not shown in FIG. 13, it will be understood by those skilled in the art after reading this specification that the secret sharing-based MPC system 70 includes other elements such as a client.

[0049] Environment A and environment B are different environments, and for example, environment A and environment B may be groups of cloud servers managed and operated by different entities. Both environment A device 72 and environment B device 74 participate in the secret sharing-based MPC according to the embodiment. The original data can be restored by combining the share held by environment A device 72 and the corresponding share held by environment B device 74, but the secret sharing that cannot be restored by one share alone is realized by the above mechanism.

[0050] Fig. 14 is a hardware configuration diagram of the environment A device 72 of Fig. 13. The environment B device 74 and the random number generation mechanism 54 may have a hardware configuration similar to the hardware configuration shown in Fig. 14. The environment A device 72 includes a memory 130, a processor 132, a communication interface 134, a display 136, and an input interface 138. These elements are each connected to a bus 140 and communicate with each other via the bus 140.

[0051] The memory 130 is a storage area for storing data and programs. The data and programs may be stored in the memory 130 permanently or temporarily. The processor 132 executes the programs stored in the memory 130 to realize various functions of the environment A device 72. The communication interface 134 is an interface for transmitting and receiving data to and from the outside of the environment A device 72. For example, the communication interface 134 includes an interface for accessing a network, and transmits and receives data to and from the environment B device 74 and the random number generation mechanism 54 via the network. The display 136 is a device for displaying various information, such as a liquid crystal display or an organic EL (electroluminescence) display. The input interface 138 is a device for receiving input from a user. The input interface 138 includes, for example, a mouse, a keyboard, and a touch panel provided on the display 138.

[0052] Figure 15 is a block diagram showing the functions and configuration of environment A device 72 in Figure 13. Each block shown here can be realized in hardware by elements or mechanical devices such as a computer CPU, and in software by a computer program, etc., but here we depict functional blocks realized by the cooperation of these. Therefore, those skilled in the art who have read this specification will understand that these functional blocks can be realized in various ways by combining hardware and software. Environment B device 74 has the same functions and configuration as environment A device 72 shown in Figure 15.

[0053] The environment A device 72 includes a share update random number acquisition unit 102 , a share update random number confirmation unit 104 , a share update unit 106 , an access management unit 108 , a share holding unit 110 , and an access history holding unit 112 .

[0054] FIG. 16 is a data structure diagram showing an example of the share storage unit 110 in FIG. 15. The share storage unit 110 stores a share ID indicating the correspondence between shares in the secret sharing-based MPC system 70, a share value, and a revision number that identifies the revision of the share, in association with each other. Multiple shares may always have the same revision number, or a revision number may be managed for each share. In the secret sharing-based MPC system 70, the same share ID is assigned to two or more shares generated by dividing original data at a client that provides the secret. Therefore, shares with matching share IDs indicate that the shares are corresponding shares generated by dividing the same original data. In the example of FIG. 1, shares 4 and 6 generated by dividing original data 2 have the same share ID (e.g., "SH01"). The revision number is updated each time the share is updated. It is recommended that the revision number be updated by incrementing or by using a unidirectional method such as a hash function. For simplicity, the term "increment" will be used hereinafter.

[0055] Fig. 17 is a data structure diagram showing an example of the access history storage unit 112 of Fig. 15. For each share stored in the share storage unit 110, the access history storage unit 112 associates the revision number of the share with information about access to the share with that revision number, and stores the revision number at the time of access. In the example of Fig. 17, the access information includes a user ID that identifies the user who accessed the share. In the access history storage unit 112, an entry with the updated revision number is added every time the share update random number is updated, that is, every time a share is updated.

[0056] 15, the share update random number acquisition unit 102 acquires a share update random number from the random number generation mechanism 54. The random number generation mechanism 54 periodically updates the share update random number, for example, every hour, every eight hours, every 12 hours, every day, etc. Every time the share update random number is updated in the random number generation mechanism 54, the share update random number acquisition unit 102 acquires the updated share update random number.

[0057] The random number for updating the share can be updated according to a predetermined rule, and can be updated periodically or at irregular intervals. The more irregular the update cycle of the random number for updating the share (= share update cycle), the more difficult the attack becomes.

[0058] The share update random number verification unit 104 verifies the validity of the share update random number acquired by the share update random number acquisition unit 102. When the share update random number acquisition unit 102 acquires a share update random number, the share update random number verification unit 104 communicates with the share update random number verification unit of the environment B device 74 via the network to determine whether the share update random number acquired by the environment A device 72 matches the share update random number acquired by the environment B device 74. If the share update random number verification unit 104 determines that they match, it passes the process to the share update unit 106. If the share update random number verification unit 104 determines that they do not match, it executes a specified share update random number generation abnormality process.

[0059] The share update unit 106 updates the share of the environment A device 72 stored in the share storage unit 110 based on the share update random number acquired by the share update random number acquisition unit 102. The update method in this share update unit 106 is designed so that when the share of the environment A device 72 updated based on the acquired share update random number is combined with the corresponding share of the environment B device 74 updated based on the share update random number, the influence of the share update random number is offset and the original data is restored.

[0060] In this embodiment, the influence of the share update random number is canceled out by adding the share update random number to the share of the environment A device 72 while subtracting the share update random number from the corresponding share of the environment B device 74 (see FIGS. 11 and 12). Once the update has been successful in all environments and they are no longer needed for subsequent processing, the pre-update share values ​​and share update random numbers must be promptly discarded from all of the environment A devices 72 to make them unrecoverable. When the share update random number acquisition unit 102 acquires an updated share update random number other than by discarding, the share update unit 106 further updates the shares that have already been updated using the pre-update share update random number based on the updated share update random number.

[0061] Just as environment A performs addition and environment B performs subtraction, the role that performs the calculation for each environment is determined by a predetermined means. Any means is sufficient as long as the operations performed through the share updates are canceled out (zero sum) across the whole. For example, in a situation where secret sharing is performed across three environments, if one environment is assigned to the adder role and two environments are assigned to the subtracter role, an agreement is made that the adder role will add twice the random number used for share update. As a result, the overall share update will be (random number used for share update x 2) - (random number used for share update + random number used for share update) = 0.

[0062] The share update unit 106 communicates with the environment B device 74 to perform processing to match the revision number of the share in the environment A device 72, which has been updated based on the acquired random number for share update, with the revision number of the corresponding share in the environment B device 74, which has been updated based on the random number for share update. By confirming that the update of the share value has been completed on each device and managing the revision for each update, it becomes possible to keep the share unique even after the update.

[0063] The share updating unit 106 includes an updated share calculation unit 114, a revision synchronization unit 116, a share switching unit 118, and a revision transition management unit 120. Further details of the share updating unit 106 will be described later with reference to FIG.

[0064] The access management unit 108 manages access to shares held in the share holding unit 110. The access management unit 108 receives requests for access to shares held in the share holding unit 110 from users via the input interface 138 or via a network. The access management unit 108 performs user authentication of the requesting user, and denies access if authentication fails. If authentication is successful, the access management unit 108 reads the share specified in the received access request from the share holding unit 110 and provides it to the requester. The access management unit 108 also registers in the access history holding unit 112 the revision number of the provided share and the user ID of the user to whom the share is to be provided, in association with each other.

[0065] The operation of the secret sharing-based MPC system 70 configured as above will now be described. Fig. 18 is a chart showing the flow of a series of processes in the secret sharing-based MPC system 70 of Fig. 13. The share update random number acquisition unit 102 of the environment A device 72 and the share update random number acquisition unit of the environment B device 74 each acquire a share update random number generated or updated by the random number generation mechanism 54 (S802). The share update random number confirmation unit 104 of the environment A device 72 communicates with the share update random number confirmation unit of the environment B device 74 to confirm the share update random number acquired in step S802 (S804). The update share calculation unit 114 of the share update unit 106 of the environment A device 72 reads the share ID and current share value of the share held in the share holding unit 110, and calculates the update share by adding the read share value to the share update random number acquired in step S802 (S806). At the same time, the update share calculation unit 114 reads the current revision number of the share value read in step S806 from the share holding unit 110, and calculates a new revision number by incrementing the read revision number (or by performing a hash calculation using a hash function to determine the next revision number) (S808). Similarly, the update share calculation unit of the share update unit of environment B device 74 reads the share ID and current share value of the share held in the share holding unit of environment B device 74, and calculates an update share by subtracting the share update random number acquired in step S802 from the read share value (S810). At the same time, the update share calculation unit reads the current revision number of the share value read in step S810 from the share holding unit, and calculates a new revision number by incrementing the read revision number (or by performing a hash calculation using a hash function to determine the next revision number) (S812).

[0066] The revision synchronization unit 116 of the share update unit 106 of the environment A device 72 notifies the revision synchronization unit of the share update unit of the environment B device 74 of the share ID of the share to be updated and the new revision number calculated in step S808 via the network (S814). The revision synchronization unit of the share update unit of the environment B device 74 receives the notification. The revision synchronization unit identifies, from the update shares calculated in step S810, an update share having a share ID that matches the notified share ID. The revision synchronization unit compares the new revision number calculated in step S812 for the identified update share with the new revision number notified in step S814 (S816).

[0067] If it is determined in step S816 that the new revision numbers do not match (N in S818), the revision synchronization unit of the share update unit of the environment B device 74 executes a predetermined exception handling process (S820). For example, the revision synchronization unit may discard the updated share and execute a process to resynchronize and update the revision.

[0068] If it is determined in step S816 that the new revision numbers match (Y in S818), the share switching unit of the share update unit in environment B device 74 discards the old share and switches to the updated share (S822), and updates the revision number of that share with the new revision number (S824). The share switching unit identifies a share having a share ID that matches the share ID notified in step S814 from among the shares held in the share holding unit in environment B device 74. The share switching unit discards the value of the identified share and registers instead the value of the updated share (calculated in step S810) that has a share ID that matches the notified share ID. The share switching unit also rewrites the revision number of the identified share to the new revision number (calculated in step S812).

[0069] When the switch to the updated share is completed in the environment B device 74, the share switching unit of the share update unit of the environment B device 74 notifies the share switching unit 118 of the environment A device 72 of the update completion (S826). Upon receiving the update completion notification, the share switching unit 118 discards the old share and switches to the updated share (S828), and updates the revision number of the share with the new revision number (S830). The share switching unit 118 identifies the share to be updated from among the shares held in the share holding unit 110 of the environment A device 72 (i.e., the share having the share ID matching the share ID notified in step S814). The share switching unit 118 discards the value of the identified share and registers instead the updated share value of the share to be updated (calculated in step S806). The share switching unit 118 also rewrites the revision number of the identified share with the new revision number (calculated in step S808).

[0070] The share update unit 106 of the environment A device 72 discards the random number for share update acquired in step S802 (S832). Environment A leaves a timestamp of the update completion time in log format. At this time, environment A notifies environment B that step S830 has ended successfully (S834). When environment B receives the notification, the share update unit of environment B discards the random number for share update acquired in step S802 (S836). Environment B leaves a timestamp of the update completion time in log format.

[0071] If the notification in step S834 is not received for a certain period of time (Y in S838), exception processing is performed (S840). For example, after communicating with environment A and confirming that environment A has terminated normally, the share update unit of environment B discards the share update random number acquired in step S802 and returns to normal operation. Conversely, if normal termination cannot be confirmed, it is necessary to revert all environments to the state before the update. For example, for shares for which the update operation has been completed, the share update random number may be used to restore the original share. Shares that were added using the share update random number may be decremented using the share update random number, shares that were subtracted using the share update random number may be incremented using the share update random number, and the updated revision number may be reset to the previous number by one, thereby restoring the shares to the state before the update. At the same time, the revision numbers of shares for which the update operation has been completed are also restored to the state before the update. If increments are used to assign revision numbers, they are decremented. However, if a one-way numbering method such as a hash function is used for revision numbers, the old revision number must be retained until successful completion can be confirmed. Once successful completion of the share update can be confirmed, the old revision number may be discarded for safety reasons. The timestamp left during the update is also invalidated.

[0072] The revision transition management unit 120 of the share update unit 106 of the environment A device 72 performs processing to prevent inconsistencies in the revisions of the operands (= shares) of the calculations performed within each device during the share update procedure. Such revision inconsistencies can occur, for example, when a calculation occurs between the end of the share switching on the environment B device 74 side and the end of the share switching on the environment A device 72 side (between step S824 and step S830 in FIG. 18). Specifically, the shares used in the calculation in progress on the environment A device 72 become an older revision. To prevent such revision inconsistencies, measures are implemented. For example, the revision transition management unit 120 may perform one of the following two transition management processes.

[0073] (1) During synchronization of share revisions, i.e., from before the start of step S814 in FIG. 18 until the completion of step S830, the revision transition management unit 120 of the environment A device 72 and the revision transition management unit of the environment B device 74 each stop the calculations of the environment A device 72 and the calculations of the environment B device 74 in the following manner. (Stop procedure) First, both the environment A device 72 and the environment B device 74 stop accepting the start of a calculation process. Then, the two devices share the currently running calculation processes. If there is a difference, there are two options for how to handle it: Option 1: Allow both devices to complete their collaborative work on the computational process before shutting down. Option 2: The device that is currently executing the differential process will interrupt the process and postpone it until after the share update. After step S830 is completed, the revision transition management unit 120 of the environment A device 72 sends an additional notification to the revision transition management unit of the environment B device 74, and the calculations are resumed using the updated shares.

[0074] The first transition management process has high availability because it takes less time to process remaining processes, especially when the granularity of the calculation process is small. It also requires less communication bandwidth than the second transition management process described below.

[0075] (2) In all calculation processes that occur on each device, the revision number is associated with the share that is used as the operand. When a calculation occurs, this revision number is notified from the revision transition management unit 120 of the environment A device 72 to the revision transition management unit of the environment B device 74. Note that if a multiplier is included in the series of processes, one or more rounds of communication will occur between the two devices, so notification may also be done at that timing.

[0076] In the environment B device 74, if the revision number of a process collaborating in the same calculation does not match the revision number notified from the environment A device 72 (i.e., if the revision number notified from the environment A device 72 is older (because, if the procedure in Figure 18 is followed, the environment B device 74 performs the share switch first)), the revision transition management unit of the environment B device 74 notifies the revision transition management unit 120 of the environment A device 72.

[0077] Upon receiving the notification, the revision transition management unit 120 of the environment A device 72 restarts the calculation process from the beginning only on the environment A device 72 side after acquiring the share of the new revision.

[0078] The transition management process in Item 2 has a relatively small impact on availability. For example, when a mismatch occurs, only a slight delay occurs on the environment A device 72 side. This transition management process is also more suitable when the share update cycle is irregular. This is particularly limited to cases where all shares across the entire environment are managed by linking them to a single revision number. However, if a calculation that uses a share as an operand and generates a round (e.g., a multiplier) is successful even once, there is no need to notify the other party of the revision number. This is because, based on the assumption that shares are managed with the same revision number across the entire environment, the success of a calculation in which all environments communicate (generates a round) guarantees that all shares in all environments are up to date. In addition to the method of agreement via the multiplier, an agreement can be made in which both parties notify each other of the revision number after a share update and agree on it before resuming the calculation.

[0079] Whether to adopt the first transition management process or the second transition management process may be determined based on the requirements of the system.

[0080] In the above-described embodiments, examples of the storage unit are a hard disk and a semiconductor memory. Furthermore, based on the description in this specification, it will be understood by those skilled in the art that each unit can be realized by a CPU (not shown), an installed application program module, a system program module, a semiconductor memory that temporarily stores the contents of data read from a hard disk, or the like.

[0081] The secret sharing-based MPC system 70 according to this embodiment can reduce the risk of original data being leaked due to insufficient capabilities of the device administrator, etc. In conventional secret sharing-based MPC, if a delay in detecting the leakage of one share value causes the other share value to be leaked in the meantime, this is considered to be data leakage. In contrast, the secret sharing-based MPC system 70 according to this embodiment periodically generates random numbers for share update and updates the shares, so that leakage of original data will not occur unless share values ​​of the same revision are leaked at approximately the same time.

[0082] Furthermore, the secret sharing-based MPC system 70 according to this embodiment can contribute to forensics by preventing malicious attacks and narrowing down suspects even if data leakage occurs. The secret sharing-based MPC system 70 improves traceability by matching the access history of the environment A device 72 with the access history of the environment B device 74, thereby increasing the psychological barrier to attack execution. If data leakage occurs, it is highly likely that it occurred between the time of "data creation / modification" and the time of "the revision where simultaneous access occurred," which can support forensics when a problem occurs. This improves accountability.

[0083] FIG. 19 is a schematic diagram illustrating improved traceability achieved by the secret sharing-based MPC system 70 according to this embodiment. The upper part of FIG. 19 shows the access history in the environment A device 72 to one share 80 obtained by dividing the original data. The lower part of FIG. 19 shows the access history in the environment B device 74 to the other share 82. The original data can be restored by combining the two shares 80, 82 of the same revision. In this way, the secret sharing-based MPC system 70 according to this embodiment can hash the timeline at the time of share update, making it possible to narrow down the suspect who caused the leak.

[0084] In the example of Figure 19, simultaneous access to two shares 80 and 82 occurred when the revision numbers were "Rev4," "Rev5," and "Rev6." Therefore, if a leak of the original data were to occur, users 84, 86, 88, 90, 92, and 94 associated with revision numbers "Rev4," "Rev5," and "Rev6" would be suspect. If the same user had accessed two shares 80 and 82 of the same revision, that user would naturally be the most suspicious. Therefore, in the example of Figure 19, user 94 is the most suspicious person responsible for the leak. Next, since users who access multiple shares are suspicious, user 86, who accessed the revision numbers "Rev4," "Rev5," and "Rev6" twice, would be suspicious. Furthermore, considering the possibility of different users colluding, collusion is suspected between the pair of users 84 and 86 (Rev4) and the pair of users 92 and 86 (Rev6), who are accessing two shares 80 and 82 with the same revision. Conversely, if the revisions are different, there is no problem even if the two shares 80 and 82 are accessed, so it can be said that the probability of collusion between users 88 and 86, for example, is low.

[0085] In this way, the secret sharing-based MPC system 70 according to this embodiment can realize an anti-collusion scheme that supports system auditing.

[0086] <Application example> 20 is a schematic diagram for explaining an application example of the secret sharing-based MPC according to this embodiment. In this application example, by applying the secret sharing-based MPC according to this embodiment to support M&A using secure computation, the risk of leakage of sensitive data is reduced and traceability in the event of an emergency is improved.

[0087] When considering M&A with a competitor, it is said that the M&A effect is greater if the target customer's customer base does not overlap. If differences in customer profiles, past consumption activities, preferences, etc. can be analyzed, overlapping customer bases can be minimized, but such analysis requires the disclosure of customer information. If the M&A fails after the disclosure of customer information, it could have a significant impact on future competitiveness.

[0088] Therefore, in this application example, in accordance with a secure computation scheme, each company conceals (shares) customer information and then shares it in a computing environment. Analyzing the information directly using secure computation enables more accurate decision-making. Furthermore, by providing a random number generation mechanism similar to the random number generation mechanism 54 of the embodiment, configuring the device in the vendor P environment similar to the environment A device 72, and configuring the device in the vendor Q environment similar to the environment B device 74, the risk of customer information leakage can be reduced. Even if a leakage does occur, it becomes easier to narrow down suspects.

[0089] The above describes the configuration and operation of the secret sharing-based MPC system 70 according to the embodiment. This embodiment is merely an example, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component and each process, and that such modifications are also within the scope of the present invention.

[0090] <Modification> In the embodiment, a case has been described in which a share update random number is added to a share in the environment A device 72, while a share update random number is subtracted from the corresponding share in the environment B device 74, so that the influence of the share update random number is canceled out when the two updated shares are combined, but this is not limited to this. For example, the share update method may be designed so that, taking the modulus into consideration, the influence of the share update random number is eliminated when the updated shares are combined, e.g., "+0."

[0091] Fig. 21 is a schematic diagram showing the concept of secret sharing-based MPC according to a modified example. Fig. 21 shows the amount of change in shares when the shares are updated. Fig. 22 is a schematic diagram showing the change in share values ​​corresponding to Fig. 21. This modified example enhances security by periodically adding shares with a value of 0 (zero) to change the shares on each device.

[0092] Consider an environment where the modulus is 16, that is, the cycle is 16. In this environment, if you share it with a random number, for example, 7=(15+8)mod16=23mod16=7 0=(3+13)mod16=16mod16=0 In this modification, since adding 0 to the original data multiple times results in 0, the share is updated with a combination of numbers that add up to 0 modulo 16.

[0093] In Figures 21 and 22, the original data "7" is split into Share A "15" and Share B "8," and combining these two shares restores the original data "7" as shown in the calculation example above. If "3" is generated as the random number for share update, Share A is updated by "+3" to become "2," and Share B is updated by "+13" (note: 13 = (-3)%16), which is calculated from the random number for share update "3" modulo 16, to become "5." As a result, combining the two updated shares is (2 + 5) = 7, and as shown in the calculation example above, the influence of the random number for share update becomes "+0," restoring the original data "7."

[0094] In this way, no matter which combination of numbers above and below are added together, the original data ("7") will be obtained by taking the remainder modulo 16. However, if the combination is changed, the original data cannot be recovered except by chance. [Explanation of symbols]

[0095] 54 Random number generation mechanism, 70 Secret sharing based MPC system, 72 Environment A device, 74 Environment B device.

Claims

1. A device that holds shares used in secret sharing-based multi-party computation, wherein original data can be restored by combining the shares held by the device with corresponding shares held by other devices, and the device: means for acquiring a random number for share update, which is updated based on a predetermined rule, every time the random number for share update is updated; means for updating the share of the device based on the acquired random number for share update; a means for storing a share of the device in association with a value specifying the revision of the share; Equipped with The updating method of the updating means is designed so that when the share of the device updated based on the acquired share update random number is combined with the corresponding share of the other device updated based on the share update random number, the influence of the share update random number is offset and the original data is restored; the device updates its share by applying a first type of operation using the acquired share update random number, and the corresponding shares of the other devices include shares updated by applying a second type of operation using the share update random number, which is different from the first type of operation; Furthermore, the updating means performs processing to match the revision of the share of the device updated based on the acquired random number for share update with the revision of the corresponding share of the other device updated based on the random number for share update by communicating with the other device. Device.

2. 2. The device according to claim 1, further comprising means for storing a revision of a share of the device in association with information on access to the share of the revision.

Images