WO2018031597A1

WO2018031597A1 - Systems and methods for data aggregation based on one-time pad based sharing

Info

Publication number: WO2018031597A1
Application number: PCT/US2017/045992
Authority: WO
Inventors: Benjamin KREUTER; Karn SETH; Sarvar Patel
Original assignee: Google Llc
Priority date: 2016-08-08
Filing date: 2017-08-08
Publication date: 2018-02-15

Abstract

Systems and methods for data aggregation based on one-time pad based sharing is/are described, including receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares and each of the second plurality of key shares comprises a share of a secure key based on a secret sharing scheme, and transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state.

Description

SYSTEMS AND METHODS FOR DATA AGGREGATION BASED ON ONE-TIME

PAD BASED SHARING

BACKGROUND

Field

[0001] The subject matter discussed herein relates generally to data sharing and aggregation systems and, more particularly, to systems and methods for data aggregation based on one-time pad based sharing.

Related Background

[0002] In the related art secure communication protocols between a host (e.g., server) and a client, it is assumed that the server facilitating data aggregation for clients is a dishonest server throughout protocol execution. An attacker may secretly alter the communications (e.g., the attacker acts as a relay between the parties but secretly and maliciously alters their communications), made during key exchange (e.g., clients exchanging public keys to simulate secure authenticated channels). The malicious server may also be lying about which clients have dropped out, to reveal client secrets and target specific clients.

[0003] In a related art implementation, secure aggregation for n parties is provided as follows. In one example, aggregation means to compute a function, for example a sum, of n values each provided by one of the parties. Secure aggregation means, for example, that none of the parties or any third party is aware of the individual value provide by any other party. All parties agree on a generator g of a group G of order q, where the decisional Diffie- Hellman (DH) assumption holds, and agree on message length N. The parties agree on a pseudorandom generator (PRG) that maps individual elements in G to sequences of pseudorandom values < 2N. Each client can communicate with the server, and the server will faithfully forward messages between clients.

[0004] Each client i chooses a secret xi e 1q. Each client computes g^xl, and sends the value to the server. The server then sends g^XJ for every j = i to client i. [0005] Each client i proceeds as follows. Initially, each client computes k_y = (g^XJ)^xl = g^M*^XJ and computes vi = mi +∑i<j PRG(k_y) -∑i>j PRG(k_y). In some examples, k_y = k_ji and k_y is a key shared between clients i and j . Then, client i sends vi to the server. The server computes ∑iVi, and outputs the result as the answer.

[0006] If each client is honest, then the value output by the server will be∑!¾ as required. This result occurs because each PRG(k_y) term cancels with a - PRG(k_y) term in ∑vi. However, if a client drops out, there will be unmatched PRG(k_y) terms which will mask the output value.

SUMMARY

[0007] The subject matter includes a computer-implemented method, comprising receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares and each of the second plurality of key shares comprises a share of a secure key based on a secret sharing scheme, and transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state. The secure key associated with the first plurality of key shares may differ from the secure key associated with the second plurality of key shares.

[0008] The methods are implemented using one or more computing devices and/or systems. The methods may be stored as executable instructions in a computer-readable medium.

[0009] Additionally, the subject matter may include a means for receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares and each of the second plurality of key shares comprises a share of a secure key based on a secret sharing scheme, and a means for transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1. illustrates an example flow diagram from the modified secure aggregation protocol, in accordance with an example implementation. [0011] FIG. 2 illustrates a flow diagram from the client perspective, in accordance with an example implementation.

[0012] FIG. 3 illustrates a flow diagram from the server perspective, in accordance with an example implementation.

[0013] FIG. 4 illustrates an example of a process implementation, in accordance with an example implementation.

[0014] FIG. 5 illustrates an example environment suitable for some example implementations.

[0015] FIG. 6 illustrates an example computing environment with an example computing device suitable for use in some example implementations.

DETAILED DESCRIPTION

[0016] The subject matter described herein is taught by way of example implementations. Various details have been omitted for the sake of clarity and to avoid obscuring the subject matter. The examples shown below are directed to structures and functions for implementing systems and methods for data aggregation based on one-time pad based sharing.

[0017] The related art scheme for secure communication between a host and a client requires all n parties to remain live in order to provide their values vi for aggregation. However, in situations where clients j can get dropped, there should be robustness when up to (n-t) clients drop out. Accordingly, when clients drop out, there is a need to remove all unpaired PRG(ky) terms from∑vi of the remaining live clients i.

[0018] A related art approach is for the server to request each live client i to give the server its shared key k_y- with each dropped client j, allowing the server to appropriately remove the unmatched PRG(k_y) terms from∑vi. In a related art implementation, each client i chooses a secret xi e 1q. It computes g^M, and sends this value to the server. The server sends g^XJ for every j != i to client i. Clients j that drop before this step are ignored.

[0019] According to this related art approach, each client i performs the following operations. Initially, each client computes k_y- = (g^xj)^M = g^xl*xj. Then, each client computes vi = mi +∑i_<j PRG(ki_j) -∑i_>j PRG(ki_j) and client i then sends vi to the server. The server sends each client i a list L of clients j that dropped. For each client j on list L, client i sends the server ky. If any additional clients drop, the flows can be repeated to give the server kij for the newly dropped clients, and the list L is updated. Further, the server computes an adjustment factor adjust = (∑ (je_L, i alive, i<j) PRG(ky) -∑ (j_eL; i _ai_ive; i>j) PRG(ki_j)) mod N. The server outputs v = (∑ _(i alive) i - adjust) mod N..

[0020] The above related art approach may add robustness, at the cost of potentially only a single extra round trip of communication between each client and the server. However, if more clients drop before responding to the request, the server must request the remaining clients to send k_y- for the newly dropped clients. More clients could drop during this request by the server, leading to a potentially unbounded number of rounds if the participants are prone to dropouts.

[0021] A malicious server could provide false information about clients dropping out. For example, the malicious server could provide information to one client that half the other clients have dropped out. By appropriately lying, the server can obtain all k_y- and recover the messages mi of all clients i. This lying is undetectable in the related art unless the clients directly communicate, or an additional audit mechanism is used.

[0022] The example implementations described herein are directed to addressing the related art issues through the use of encryption by adding both the random value generated from the pseudorandom generator based on the key values shared across each client, as well as having each client add its own one-time pad to the message, which is also shared across clients through the key sharing scheme. Thus, the message transmitted from each client is encrypted by both a random value and a one-time pad. As will be understood to those skilled in the art, a one-time pad, also referred to as Vernam-cipher or the perfect cipher, is a crypto algorithm where plaintext may be combined with a random key in a way that perfectly hides the plaintext.

[0023] The server can request from the random value corresponding to a client if the client has dropped, or the one-time pad from the client if the client has not dropped, in which case the clients will transmit the corresponding key shares to either the random value or the one-time pad to reconstruct the random value or one-time pad. However, through utilizing the security protocol in the example implementations, the server is prevented from obtaining both the random value and the one-time pad corresponding to the same client through this protocol, thereby ensuring that the message sent from a given client remains encrypted.

[0024] In example implementations, the related art schemes can be modified to securely handle up to (n-t) dropouts, while addressing the above-noted issues. For example, in the modified scheme of the example implementations, the following aspects may be achieved:

[0025] 1. As long as at least t clients survive to the end, the server can robustly compute ∑rrii for the surviving clients in a fixed number of rounds.

[0026] 2. If t > (2/3)n, then a malicious server that lies about which other clients have dropped still cannot learn more than a single∑!¾, where the sum includes the values of at least (l/2)n clients.

[0027] 3. If t > (4/5)n, then a malicious server that controls (n-t) of the clients and additionally lies to the honest clients about which other clients have dropped cannot learn more than a single∑!¾, where the sum includes the values of at least 55% of the honest clients.

[0028] In example implementations, each client /^', sends the other clients t-out-of-n shares of the secret xi it uses in each ky. Any t of these shares will be sufficient to reconstruct xi, but knowing less than t shares means xi will be information-theoretically secured (i.e., cannot be broken even if unlimited computing resources are applied).

[0029] If a client i drops out during the protocol according to the example implementation, the server will request the remaining clients to provide their shares of xi. As long as at least t of the clients respond with their shares, the server will be able to reconstruct xi. Given this, and the server's previous knowledge of g^XJ for all j, the server will be able to compute ky = g^xl*xj for all j, and remove all of client z's unmatched term in∑vi.

[0030] Additionally, in example implementations, each client z adds an additional term PRG(Si) to its value Vi , where Si is a new random element of G known only to client z. Without this term, if a server lies about a client dropping, the server will be able to remove all PRG(kij) terms from client z's value vi and learn mi. However, example implementations described herein introduce an extraneous PRG(si) term into∑vi. To remove these terms, each client is configured to use t-out-of-n secret sharing to split Si into n shares, and to send one share to each other party. The server will then determine from each undropped client i their share of Sj for each other undropped client j. As long as at least t clients respond with their shares, the server will be able to reconstruct all Sj, and remove the extraneous PRG(si) terms from∑Vi.

[0031] In example implementations, there is an additional constraint that the server may only query each client i for either its share of Xj or its share of Sj (but not both for a single j). Further, the server may query each client i for shares of Xj for only up to (n-t) clients j (client i can be configured not to provide any more). These two conditions, together with the security of the t-out-of-n secret sharing scheme, may address the related art issues as mentioned above. More specifically, for each client /^', the server will only be able to acquire t shares of one of xi or si, but not both. The former (xi) will allow the server to remove client i from the sum, while the latter (si) will allow the server to include client i. However, since the server cannot learn both, it will be unable to learn the unencrypted mi.

[0032] Further, the total number of shares of Xj, over all j, obtainable by the server is (n-t) * n, and since it needs at least t shares to reconstruct any Xj, the maximum number of Xj the server can reconstruct is [((n-t) * n) / tj, wherein [ ... J denotes the floor function on integer values.. For example, if t > ¾ n, then the maximum number of Xj the server learns is ½ n, and thus must include at least the remaining ½ n clients in the sum∑vi.

[0033] To send the shares described above to each other, example implementations utilize a secure way for client i to communicate with client j. The example implementations achieve this by having each client produce a public key pki for an encryption scheme. All other clients j will use pki to encrypt messages that they send to client i.

[0034] In an example implementation as described herein, there is a modified secure aggregation protocol that uses the t-out-of-n secret sharing scheme as described above. In a t- out-of-n secret sharing scheme, a secret is divided into parts, giving each of the n clients its own unique part, where some threshold t out of all of the parts n are needed in order to reconstruct the secret. FIG. 1 illustrates an example flow diagram 100 from the modified secure aggregation protocol, in accordance with an example implementation.

[0035] At 101, the clients generate a public key and a secret for exchanging with other clients. During this operation, each client i chooses a secret xi e 1q and generates a public key pki for an encryption scheme. Each client computes g^xl, and sends g^M and pki to the server.

[0036] At 102, the server facilitates the exchanging of public keys and secrets between clients. During this operation, the server sends g^XJ and pk_j for every j != i to client i. Any clients that are dropped or disconnected before the flow at 102 can be ignored in the remainder.

[0037] At 103, each client generates a one-time pad, conducts secret sharing of the onetime pad and the secret, and submits the cipher text to the server. Each client i proceeds as follows.

[0038] 1. Each client chooses a random r e 2q and sets one-time pad Si = g^r.

[0039] 2. Each client computes a t-out-of-n secret sharing of each of xi and si. Let the y'th shares be denoted share_j(xi) and share_j(si) respectively.

[0040] 3. Each client computes, for every j != /^', ctexty = Enc(pk_j, share_j(xi) || share_j(si)), where || denotes concatenation.

[0041] 4. Client i then sends the server ctexty for all j != i.

[0042] At 104, each client receives cipher text of the other clients from the server. During this operation, the server sends client i ctext_ji for each j != /^', a cipher text from client j sent to client i. Any clients that drop before this operation are ignored in the remainder.

[0043] At 105, each client submits its message aggregated with its one-time pad and secret, and transmits the result to the server. During this operation, each client i proceeds as follows. Each client computes ky = (g^XJ)^xl = g^M*^XJ for all undropped clients j. Each client computes vi = mi +∑i<j PRG(ky) -∑i>j PRG(ky) + PRG(si). Client i then sends vi to the server.

[0044] At 106, the server sends a list of dropped clients to the remaining clients. During this operation, the server sends each client i that responded a list L of clients j that dropped between the flows at 104 and 106. At 107, the clients generate a response to the server based on the list of dropped clients. During this operation, if the number of dropped clients overall is greater than (n-t) including those on list L and those that previously dropped, client i terminates. Otherwise, client / performs the following operations: [0045] 1. For each client j on list L, client i decrypts ctext_ji and sends the server sharei(x_j).

[0046] 2. For each "undropped" client j, client i decrypts ctext_ji and sends the server sharei(s_j).

[0047] At 108, the server proceeds based on the response from the remaining clients. That is, if the server receives less than t responses in the previous step, the server aborts. Otherwise, the server proceeds as follows. For all undropped clients j, the server combines any t of the shares of Sj it received to recover Sj. For all dropped clients j on the list L, the server combines any t of the shares of Xj it received to recover Xj. It combines these with each g^M for live clients i to obtain ky.

[0048] The server computes an adjustment factor for the dropped clients: [0049] adjust = (∑ _α¾> i aiive, i<j) PRG(kij) -∑ _{α ¾> i alive; i>} PRG(ky)) mod N. [0050] The server outputs: [0051] v = (∑ (i aiive) i - adjust) mod N.

[0052] The adjustment factor removed the unmatched PRG(k_y) terms from V, as well as the extra terms of the form PRG(Si).

[0053] Through the use of example implementations, the number of rounds (e.g., round trip communications) is fixed and bounded, as long as at least t clients survive. The number of rounds conducted is fixed as the server will send each client i that responded a list L of clients j that dropped, and receive the responses from the client i and abort if the responses are less than < t without resubmission of the list. Further, stronger guarantees against a malicious server and colluding clients may be achieved through example implementations.

[0054] FIG. 2 illustrates a flow diagram 200 from the client perspective, in accordance with an example implementation. The example implementation is directed to a secret-sharing protocol that includes public values, secret values, and shared secrets. For example, but not by way of limitation, the secret-sharing protocol in accordance with the example implementation may be such that the decisional Diffie-Hellman (DH) assumption holds, and includes a Diffie-Hellman secret value, a Diffie-Hellman public value, and a Diffie-Hellman shared secret. However, the example implementations are not limited thereto, and other secret-sharing protocols may be substituted therefor.

[0055] At 201, each of the clients generates a public key for an encryption scheme, and a secret value. The secret value is encrypted with g to produce that client's public value. Both the public key for the encryption scheme, and the public value are transmitted to the server. At 202, each client receives public keys and public values of the other clients from the server. At 203, each client generates a one-time pad and transmits secret shares of the one-time pad and secret shares of the secret value corresponding to the client to the server for distribution. In example implementations, the secret shares are transmitted in the form of a cipher text as described in 103.

[0056] At 204, each client receives cipher texts corresponding to secret shares of the onetime pads and secrets of the other clients from the server. At 205, each client combines its secret value with the public values it received to generate shared secrets, and then generates a message and transmits the message by aggregating the message with the shared secrets and the one-time pad as described at 105. At 206, each client receives a list of transmission states for the other clients from the server and proceeds to process the transmission states for each client. The transmission state indicates whether the client has transmitted the message. When the client is not in the transmission state, then the client has not transmitted the message, and can be indicated in the list as not being in the transmission state, or omitted from the list depending on the desired implementation.

[0057] At 207, a determination is made for each client in the list as to if the client is a dropped client. If so (Yes), then the client is not in the transmission state and the flow proceeds to 208, wherein the client proceeds to transmit a keyshare of the secret value corresponding to the processed client. Otherwise (No), the client is in the transmission state, and the flow proceeds to 209, where the client proceeds to transmit a keyshare of the onetime pad corresponding to the processed client.

[0058] In another example implementation to mitigate the server lying about dropouts, the clients can be configured to communicate with each other and confirm the list of dead clients received from the server. That is, when the server requests shares for a list L of dead clients, each client first signs and sends the list it received from the server to all other clients using the keys they exchange at the start of the protocol. Each client then waits to receive L from the other clients, and as soon as it receives ½ n lists that agree with its own, it responds with the appropriate shares, together with its own si in plaintext.

[0059] Receiving ½ n identical lists (plus its own) is sufficient for any client, because by the pigeonhole principle, any two subsets of ½ n + 1 identical lists must share at least one client's list in common, and thus both subsets must be of the same list L. Thus, as long as the clients receive ½ n lists from other clients, every client will arrive at the same list L.

[0060] In such an example implementation, the clients can proceed even if there is a malicious server that lies about which clients have been dropped, except when the server controls or colludes with some clients; in the latter case, the clients cannot proceed securely. This is because a malicious server could instruct clients under its control to send different clients different lists L, rather than sending the same list L to all clients, which would invalidate the above security argument.

[0061] The example implementation of FIG. 2 utilizes the t-out-of-n secret sharing scheme for two purposes simultaneously: (i) to allow for recovery when clients drop, and (ii) to secure against a server that lies about who drops out. In the list-exchange example implementation, the t-out-of-n secret sharing scheme does not need to be relied upon to provide property (ii), since that property is now enforced by clients communicating with each other to verify the dropped client list, which thereby can permit a lower threshold t of ½ n.

[0062] In such an example implementation, a smaller threshold can be utilized (e.g. as small as ½ n even if the server lies about clients dropping), while still guaranteeing that the sum includes at least ½ n clients. In exchange, the list-exchange example implementation may require an extra round of communication (for the clients to exchange lists L) and requires more total communication.

[0063] In such a list-exchange example implementation, the flow at 207 to 209 can be replaced with a flow as follows. At first, for the received list L, each client i sends ctext'y = Enc(pk_j, L) to each other client j. In an example implementation, each client can send the ciphertexts to the server, and the server can then forward the ciphertexts to the clients. In an example implementation, a signature/hash based message authentication code (HMAC) on L can be transmitted rather than the whole list, depending on the desired implementation.

[0064] Then, each client i, upon receiving the ctext'_ji's from the server, acts as follows: [0065] 1) Client i ensures that all L obtained by decrypting ctext' y are the same as the L received from the server, and ensures that it has received at least ½ n such ciphertexts ctext'_ji. In the case where only a signature/HMAC was sent, it verifies that each signature/HMAC corresponds to L.

[0066] 2) Client i ensures that L is consistent with the clients that responded, that is, it verifies that it did not receive a message from a "dead" client on the list L. It also verifies that i itself is not on L.

[0067] 3) Client i verifies that |L| < ½ n. If any of the above tests fail, client i exits the protocol.

[0068] 4) For each client j on list L, client [ decrypts ctext_ji and sends the server sharei(x_j).

[0069] 5) For all undropped clients, the client sends the server the share sharei(s_j).

[0070] Subsequently, if the server receives less than t responses in the previous step, the server aborts. Otherwise, the server proceeds as follows:

[0071] 1) For all undropped clients j, the server combines any t of the shares of Sj it received to recover Sj.

[0072] 2) For all dropped clients j on the list L, the server combines any t of the shares of X_j it received to recover x_j. It combines these shares with each g^xl for live clients i to obtain

H

[0073] 3) The server computes an adjustment factor

[0074] adjust = (∑ _α¾> i aiive, i<j) PRG(k_y) -∑ _{α¾> i alive; i>} PRG(k_y)) mod N.

[0075] 4) The server outputs:

[0076] v = (∑ (i aiive) i - adjust) mod N.

[0077] The adjustment factor removed the unmatched PRG(k_y) terms from V, as well as the extra terms of the form PRG(si).

[0078] In this example list-exchange implementation, there is an additional communication of 64 kb per client (32B per ctext'y, 1000 sent out and 1000 received). This computation assumes that ctext'y contains only a signature from L (using the signature component of the secure encryption scheme previously set up). The total communication cost can be, for example, 288KB + 3MB.

[0079] In another example implementation, each client pair can utilize a symmetric communication key used for hiding communications from server and others. Then each client has a master key xi and uses it to create Ky = PRF(xi, j) and shares Ky with the respective parties, xi is (t,n) shared with other parties, such that if client i drops out then other parties can recreate xi and recover all Ky parts. In such an example, DH can be replaced by another encryption scheme according to the desired implementation.

[0080] FIG. 3 illustrates a flow diagram 300 from the server perspective, in accordance with an example implementation. At 301, the server distributes all received public keys and public values (e.g., Diffie-Hellman) that were received at 201 of FIG. 2 to the clients. At 302, the server distributes all received cipher texts received at 203 to clients. At 303, the server aggregates encrypted messages from clients at 205 of FIG. 2. At 304, the server determines which clients dropped during the process, generates a list of dropped clients and transmits the list to the clients as described at 106. At 305, the server receives keyshares and generates the keys corresponding to each client based on the aggregated key shares as described at 107. At 306, the generated keys may be used to decrypt the aggregated message.

[0081] Cost comparisons

[0082] As shown in TABLE 1, below, an example cost comparison was applied involving 1000 clients each with 2 megabytes (MB) of data, involving a 1 million element vector of 2 bytes each. Each element is expanded by one byte to accommodate summing and weights. The size of the Diffie-Hellman (DH) modulus is 256 bits, and the public key encryption scheme used in example implementations is also DH, combined with a one-time pad-style stream cipher. In the example cost comparison, a maximum of 10% of users drop.

Communication per 3MB + 32KB 3MB + 35.2KB 3MB + 224KB client

Robustness to No Yes, but can increase Yes, up to n-t dropouts rounds

Secure if server lies N/A No Yes, if t > (2/3) n about dropouts

Secure if server fakes No No Yes, if t > (4/5) n some clients

TAB] _E 1

[0083] FIG. 4 shows an example of a process implementation, in accordance with an example implementation. At 405, the process involves receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares and each of the second plurality of key shares comprises a share of a secure key based on a secret sharing scheme, as described at 204 of FIG. 2. At 410, the process involves transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state as described at 206-209 of FIG. 2.

[0084] In some examples, process 400 may be implemented with different, fewer, or more blocks. Process 400 may be implemented as computer executable instructions, which can be stored on a medium, loaded onto one or more processors of one or more computing devices, and executed as a computer-implemented method.

[0085] The following examples are provided with respect to the foregoing example implementations. Any numerical examples are for illustrative purposes only, and are not intended to limit the scope of the example implementations. Other values may be substituted for the provided information without departing from the scope of the example implementations.

[0086] The protocol according to the example implementation may allow the server to learn the sum of clients' values, but not their individual values. Further, the server does not learn an individual client's value by having each client use two secret values, xi and si, such that the server learns the former when the client is dropped, and the latter when the client is live, but never both.

[0087] Additionally, the example implementation guarantees that the sum still includes a large fraction of clients. For example, the server may not reduce the size of the sum so that it includes only 1 or 2 clients, since this result may effectively reveal or expose those clients' private messages.

[0088] Concretely, the protocol must thus bound the total number of Xj that the server learns, since learning Xj allows the server to remove client j from the sum. If the server can only ever learn less than ½ n of the Xj values, then the sum that the server learns contains at least ½ n clients.

[0089] As shown in the following numerical examples, a malicious server lying about dropouts only learns < ½ n Xj if t > ¾ n, and a malicious server that controls or colludes with up to (n-t) clients only learns < ½ n Xj if t > Vs n.

[0090] In a first example, a server lies about dropouts. For a scenario where that are n = 100 clients, the threshold is set at t = 67 > ¾ n. The lying server will cheat when submitting a list of dropped clients to the remaining clients (e.g., operation 106 of FIG. 1), sending each client a different list L of dropped clients. Assuming that the server sends each client a list L of the maximum size n-t = 33 when submitting a list of dropped clients to the remaining clients (e.g., operation 106 of FIG. 1), the server can learn a maximum of 33 * 100 sharei(x_j) values. Reconstructing any particular Xj value requires at least t sharei(x_j) shares; thus, the maximum number of Xj that the server can recover is < (33 * 100 / 67) < 50. Thus it can exclude < 50 clients' values from the sum, and must include at least 50 = ½ n clients.

[0091] In a second example, the server additionally controls or colludes with clients. For a scenario n = 100 clients, the threshold is set at t = 80 = Vs n. The server is allowed to collude with up to n-t = 20 clients. Examining the protocol, the server learns all 100 shares of both Xj and Sj that each of those clients possesses. Focusing only on the Xj shares, the server learns 20* 100 = 2000 Xj shares through this collusion. Additionally, to the remaining 80 honest players, the server will cheat when submitting a list of dropped clients to the remaining clients (e.g., operation 106 of FIG. 1), sending each client a different list L of dropped clients, of the maximum size n-t = 20. From this, the server can learn a maximum of 20 * 80 = 1600 sharei(x_j) values. Reconstructing any particular Xj value requires at least t sharei(xj) shares; thus, the maximum number of Xj that the server can recover is < (2000 + 1600 / 80) = 45 < 50. Thus, the server can exclude < 50 clients' values from the sum, and must include at least 50 = ½ n clients.

[0092] Through such example implementations, implementations involving federated averaging or federated learning can be facilitated. In an example implementation, the secure aggregation protocol described above can be utilized in conjunction with a coordinating server without the need to store user data in a cloud. For example, the coordinating server will only initiate the decryption of the update (e.g., average update) if a threshold of client devices have participated in the protocol, so that no individual user device can be expected before conducting the operation (e.g., averaging) Such implementations can be applied to deep-network-sized problems and real-world connectivity constraints.

[0093] FIG. 5 shows an example environment suitable for some example implementations. Environment 500 includes devices 505-545, and each is communicatively connected to at least one other device via, for example, network 560 (e.g., by wired and/or wireless connections). Some devices may be communicatively connected to one or more storage devices 530 and 545.

[0094] An example of one or more devices 505-545 may be computing device 605 described below in FIG. 6. Devices 505-545 may include, but are not limited to, a computer 505 (e.g., a laptop computing device), a mobile device 510 (e.g., smartphone or tablet), a television 515, a device associated with a vehicle 520, a server computer 525, computing devices 535-540, storage devices 530 and 545. Other devices may be substituted therefor (e.g., wearable device, sensor, or other device capable of receiving, transmitting, or processing electronic information).

[0095] In some implementations, client devices 505-520 may be considered user devices (e.g., devices used by users to access a social media platform and post or share visual content such as photos, videos, drawings, and illustrations), which transmit data to aggregate devices such as aggregate server 525. Aggregate devices 525-545 may be devices associated with service providers (e.g., used by service providers to provide services and/or store data, such as webpages, text, text portions, images, image portions, audios, audio segments, videos, video segments, and/or information thereabout). [0096] For example, client devices 505-520 transmit information and messages in accordance with FIG. 2 to aggregate server device 525 on a network supported by one or more devices 525-545. Aggregate server device 525 may proceed based on the flow of FIG. 3 and utilize one or more of the service provider devices 530-545 to facilitate the flow of FIG. 3 in accordance with the desired implementation.

[0097] FIG. 6 shows an example computing environment with an example computing device suitable for use in some example implementations. Computing device 605 in computing environment 600 can include one or more processing units, cores, or processors 610, memory 615 (e.g., RAM, ROM, and/or the like), internal storage 620 (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface 625, any of which can be coupled on a communication mechanism or bus 630 for communicating information or embedded in the computing device 605.

[0098] Computing device 605 can be communicatively coupled to input/user interface 635 and output device/interface 640. Either one or both of input/user interface 635 and output device/interface 640 can be a wired or wireless interface and can be detachable. Input/user interface 635 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface 640 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 635 and output device/interface 640 can be embedded with or physically coupled to the computing device 605. In other example implementations, other computing devices may function as or provide the functions of input/user interface 635 and output device/interface 640 for a computing device 605.

[0099] Examples of computing device 605 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like). [0100] Computing device 605 can be communicatively coupled (e.g., via I/O interface 625) to external storage 645 and network 650 for communicating with any number of networked components, devices, and systems, including one or more computing devices of the same or different configuration. Computing device 605 or any connected computing device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special -purpose machine, or another label.

[0101] The I/O interface 625 may include wireless communication components (not shown) that facilitate wireless communication over a voice and/or over a data network. The wireless communication components may include an antenna system with one or more antennae, a radio system, a baseband system, or any combination thereof. Radio frequency (RF) signals may be transmitted and received over the air by the antenna system under the management of the radio system.

[0102] I/O interface 625 can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, 802. l lx, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 600. Network 650 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).

[0103] Computing device 605 can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0104] Computing device 605 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others). [0105] Processor(s) 610 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 660, application programming interface (API) unit 665, input unit 670, output unit 675, one-time pad generation unit 680, encryption unit 685, keyshare generator 690, and inter-unit communication mechanism 695 for the different units to communicate with each other, with the OS, and with other applications (not shown). For example, one-time pad generation unit 680, encryption unit 685, and keyshare generator 690 may implement one or more processes as described in FIGS. 1, 2 and 4. The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided.

[0106] In some example implementations, when information or an execution instruction is received by API unit 665, it may be communicated to one or more other units (e.g., logic unit 660, input unit 670, output unit 675, one-time pad generation unit 680, encryption unit 685, and keyshare generator 690). For example, computing device 605 may invoke one-time pad generation unit 680 to generate a one-time pad, and generate keyshares to distribute to other clients with keyshare generator 690. When computing device 605 is to transmit a message, the computing device encrypts the message by using encryption unit 685 to encrypt the message with the one-time pad and the secrets in accordance with FIGs. 1, 2 and 4.

[0107] In some instances, logic unit 660 may be configured to control the information flow among the units and direct the services provided by API unit 665, input unit 670, output unit 675, one-time pad generation unit 680, encryption unit 685, and keyshare generator 690 in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 660 alone or in conjunction with API unit 665. In the following example implementations, the implementations can be conducted in singular or in any combination with other implementations as described herein. In example implementations, memory 615 can be configured to store a first plurality of key shares, and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key as described in FIGS. 1-4. For example, the first secure key corresponding to the first plurality of key shares can be a one-time pad, and the second secure key corresponding to the second plurality of key shares can be an encryption key other than a one-time pad, such as a DH encryption key or other encryption key according to the desired implementation. Further, the first plurality of key shares can correspond to a plurality of apparatuses including the apparatus, and the second plurality of key shares can correspond to the plurality of apparatuses excluding the apparatus as illustrated in FIGS. 1-4. In an example implementation the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server as described in FIGS. 1-4.

[0108] In example implementations, processor(s) 610 can be configured to transmit one of the first plurality of key shares for an apparatus in a transmission state, and transmit one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation as described in FIGS. 1-4. As described herein, such a secret sharing scheme can involve a t- out-of-n sharing scheme.

[0109] In example implementations, processor(s) 610 can be configured to receive a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list as described in FIGS. 1-3.

[0110] In example implementations, processor(s) 610 can be further configured to transmit an encrypted message keyshare aggregated with the first plurality of key shares and the second plurality of key shares as described with respect to FIGS. 1-4.

[0111] Any of the software components described herein may take a variety of forms. For example, a component may be a stand-alone software package, or it may be a software package incorporated as a "tool" in a larger software product. It may be downloadable from a network, for example, a website, as a stand-alone product or as an add-in package for installation in an existing software application. It may also be available as a client-server software application, as a web-enabled software application, and/or as a mobile application.

[0112] Further implementations are summarized in the following examples:

[0113] Example 1 : A computer-implemented method, comprising: receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key; and transmitting one of the first plurality of key shares for an apparatus in a transmission state indicative of the apparatus having transmitted a message, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

[0114] Example 2: The computer implemented method of example 1, wherein the secret sharing scheme is a t out of n sharing scheme.

[0115] Example 3 : The computer implemented method of example 1 or 2, wherein the first secure key corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a one-time pad.

[0116] Example 4: The computer implemented method of one of examples 1 to 3, further comprising receiving a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

[0117] Example 5: The computer implemented method of one of examples 1 to 4, wherein the first plurality of encryption key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of encryption key shares corresponding to the plurality of apparatuses excluding the apparatus.

[0118] Example 6: The computer implemented method of one of examples 1 to 5, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server.

[0119] Example 7: The computer implemented method of example 1, further comprising transmitting an encrypted message keyshare aggregated with the first plurality of key shares and the plurality second key shares. [0120] Example 8: A computer-implemented device, comprising: a memory, configured to store a first plurality of key shares, and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key; and a processor, configured to transmit one of the first plurality of key shares for an apparatus in a transmission state, and transmit one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

[0121] Example 9: The computer-implemented device of example 8, wherein the secret sharing scheme is a t out of n sharing scheme.

[0122] Example 10: The computer-implemented device of example 8 or 9, wherein the first secure key corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a one-time pad.

[0123] Example 11 : The computer-implemented device of one of examples 8 to 10, wherein the processor is configured to receive a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

[0124] Example 12: The computer-implemented device of one of examples 8 to 11, wherein the first plurality of key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of key shares corresponds to the plurality of apparatuses excluding the apparatus.

[0125] Example 13 : The computer-implemented device of one of examples 8 to 12, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server.

[0126] Example 14: The computer-implemented device of one of examples 8 to 13, further comprising transmitting an encrypted message key share aggregated with the first plurality of key shares and the second plurality of key shares. [0127] Example 15: A non-transitory computer-readable medium including executable instructions stored in a memory and configured to be executed by a processor, the executable instructions comprising: receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key; and transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

[0128] Example 16: The non-transitory computer-readable medium of example 15, wherein the secret sharing scheme is a t out of n sharing scheme.

[0129] Example 17: The non-transitory computer-readable medium of example 15 or 16, wherein the first secure key corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a one-time pad.

[0130] Example 18: The non-transitory computer-readable medium of one of examples 15 to 17, further comprising receiving a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

[0131] Example 19: The non-transitory computer-readable medium of one of examples 15 to 18, wherein the first plurality of key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of key shares corresponding to the plurality of apparatuses excluding the apparatus.

[0132] Example 20: The non-transitory computer-readable medium one of examples 15 to 19, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server, and further comprising transmitting an encrypted message keyshare aggregated with the first plurality of key shares and the plurality second key shares. [0133] Although a few example implementations have been shown and described, these example implementations are provided to convey the subject matter described herein to people who are familiar with this field. It should be understood that the subject matter described herein may be implemented in various forms without being limited to the described example implementations. The subject matter described herein can be practiced without those specifically defined or described matters or with other or different elements or matters not described. It will be appreciated by those familiar with this field that changes may be made in these example implementations without departing from the subject matter described herein as defined in the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A computer- implemented method, comprising:

receiving a first plurality of key shares and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key; and

transmitting one of the first plurality of key shares for an apparatus in a transmission state indicative of the apparatus having transmitted a message, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

2. The computer implemented method of claim 1, wherein the secret sharing scheme is a t out of n sharing scheme.

3. The computer implemented method of claim 1, wherein the first secure key

corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a one-time pad.

4. The computer implemented method of claim 1, further comprising receiving a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

5. The computer implemented method of claim 1, wherein the first plurality of encryption key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of encryption key shares corresponding to the plurality of apparatuses excluding the apparatus.

6. The computer implemented method of claim 1, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server.

7. The computer implemented method of claim 1, further comprising transmitting an

encrypted message keyshare aggregated with the first plurality of key shares and the plurality second key shares.

8. A computer-implemented device, comprising:

a memory, configured to store a first plurality of key shares, and a second plurality of key shares, wherein each of the first plurality of key shares comprises a share of a first secure key based on a secret sharing scheme, and each of the second plurality of key shares comprises a share of a second secure key based on the secret sharing scheme, wherein the first secure key is different from the second secure key; and

a processor, configured to transmit one of the first plurality of key shares for an apparatus in a transmission state, and transmit one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

9. The computer-implemented device of claim 8, wherein the secret sharing scheme is a t out of n sharing scheme.

10. The computer-implemented device of claim 8, wherein the first secure key corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a onetime pad.

11. The computer-implemented device of claim 8, wherein the processor is configured to receive a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

12. The computer-implemented device of claim 8, wherein the first plurality of key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of key shares corresponds to the plurality of apparatuses excluding the apparatus.

13. The computer-implemented device of claim 8, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server.

14. The computer-implemented device of claim 8, further comprising transmitting an encrypted message keyshare aggregated with the first plurality of key shares and the second plurality of key shares.

15. A non-transitory computer-readable medium including executable instructions stored in a memory and configured to be executed by a processor, the executable instructions comprising:

transmitting one of the first plurality of key shares for an apparatus in a transmission state, and transmitting one of the second plurality of key shares for the apparatus not in the transmission state to provide responses for a aggregation server to perform computation for a secure aggregation.

16. The non-transitory computer-readable medium of claim 15, wherein the secret sharing scheme is a t out of n sharing scheme.

17. The non-transitory computer-readable medium of claim 15, wherein the first secure key corresponding to the first plurality of key shares is a one-time pad, and wherein the second secure key corresponding to the second plurality of key shares is an encryption key other than a one-time pad.

18. The non-transitory computer-readable medium of claim 15, further comprising receiving a list that provides the state of the apparatus, wherein for the apparatus not being in the transmission state, the apparatus is listed as not being in the transmission state, or is omitted from the list.

19. The non-transitory computer-readable medium of claim 15, wherein the first plurality of key shares corresponds to a plurality of apparatuses including the apparatus, and the second plurality of key shares corresponding to the plurality of apparatuses excluding the apparatus.

20. The non-transitory computer-readable medium of claim 15, wherein the apparatus is a client and wherein the one of the first plurality of key shares for an apparatus in a transmission state, and the one of the second plurality of key shares for the apparatus not in the transmission state is transmitted to an aggregation server, and further comprising transmitting an encrypted message keyshare aggregated with the first plurality of key shares and the plurality second key shares.