The present invention relates to multi-server private information retrieval schemes, and in particular to enabling database updates to occur concurrently with user queries, without allowing the update process to compromise the privacy of user queries and the database content.
A critical privacy protection that users crave is preventing information they consider sensitive from being inadvertently leaked as they query or access Internet services. In other words, users see the problem of preserving their access privacy to online services as an important concern that must be addressed. A cryptographically sound approach to protect access privacy it to use the technique of private information retrieval (PIR). PIR schemes, as are known in the art, allow a user to access data from service providers without the service providers being able to learn any information about which particular data item was accessed or retrieved.
One such PIR scheme requires a database to be replicated to two or more servers that are assumed not to be colluding. A query received from a user is separated into different parts, and each part is sent to a different server. The returned result from each server, based on the portion of the query each received, is returned back to the client where the results are combined to provide a complete response to the full query. However, concerns remain about the practicality of having an organization replicate its database to the servers of multiple different cloud services that are assumed not to collude. Replicating a database to multiple independent cloud servers increases the chances of the data being broken into, used without consent, or used for illegitimate purposes. In short, it is inconceivable that an organization would ever want to give out a copy of its database especially as it may represent their intellectual property, trade secret, or asset.
To address the database replication problem, a random server model of PIR was introduced by Gertner et al. (Yael Gertner, Shafi Goldwasser, and Tal Malkin. A Random Server Model for Private Information Retrieval or how to Achieve Information Theoretic PIR Avoiding Database Replication. In RANDOM '98, pages 200-217, 1998). This model attempts to separate the task of providing query privacy from that of information retrieval using auxiliary random servers running databases containing random data. The database server uses the service of two or more random servers to generate an encrypted and permuted version of its database and to help keep the user queries private. Of particular interest in this solution are universal random servers, which are a type of auxiliary servers holding random data that is completely independent of the content of the database. Gertner et al. proposed a scheme that achieves total independence, i.e., all random servers are of the universal type—they contain no information derived from content of the dataset, thereby addressing the database replication problem. In other words, the scheme provides user privacy according to the underlying PIR scheme used with the scheme, and database privacy (no single server or a coalition can learn any information about the content of the database).
Gertner et al.'s secure multi-party computation (SMC) protocol enables the server holding a database x and two auxiliary random servers each holding a random database α and a pseudorandom permutator π, to compute an initial oblivious database y=π(x⊕α). However, their protocol must be rerun to re-compute y after a large (e.g., sublinear) number of queries have been run or whenever the database x is updated. But, naively updating the oblivious database y with updates from x leaks information about π. In other words, an update to some record xi would require an update to be made to some oblivious database block yj and the server maintaining the database is able to learn that j=π−1(i). Hence, finding a periodic downtime to rerun the SMC is prescribed to update the oblivious database y. As a result, users would have to suspend making query requests during the SMC protocol rerun because the random servers would be preoccupied. Such a wait is undesirable in environments where database changes are frequent and query downtimes are unacceptable. The second problem with this scheme is that it expects the same random database to be used to mask multiple databases belonging to different organizations, which can lead to significant attacks in practice (i.e., the attacker learns r by running several queries across databases and uses this knowledge to learn the blocks of a target y much faster).
The present invention alleviates the problems described above by providing a system and methods to provide updates of the database x without compromising privacy guarantees, and without requiring a periodic downtime to re-initialize the database. According to embodiments of the present invention, update caches are provided at the random servers that are not emptied or sent to the oblivious database y after every update in a predictable fashion. Instead, updates are made incrementally to the oblivious database in an order that is independent of how the database x is updated. Hence there is no way for the server to learn which record yj corresponds to an undated block xi. Utilizing the present invention makes a multi-server PIR deployment more feasible in an environment where the database changes frequently.
Therefore, it should now be apparent that the invention substantially achieves all the above aspects and advantages. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
The accompanying drawings illustrate presently preferred embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the principles of the invention. As shown throughout the drawings, like reference numerals designate like or corresponding parts.
In describing the present invention, reference is made to the drawings, wherein there is seen in
Referring now to
In step 60, server A1 20 creates a vector z of length n and initializes each of its elements to the current timestamp, computes a temporary dataset u=π(x01⊕α1), and sends u to server D 10. In step 62, server A2 22 similarly creates a vector z and initializes each of its elements to the current timestamp. However, it computes a temporary dataset v=π(x02⊕α2⊕f(K,“AppName”∥α∥z)) and sends v to server D 10. In step 64, server D 10 computes the initial oblivious database 18 y as u⊕v=π(x⊕α⊕f(K,“AppName”∥α∥z)). Additionally, servers A1 20 and A2 22 respectively discard their snare of x01and x02, and reset u and v to ⊥ (empty value).
Referring now to , where
is the current version of the database and i is the index or address of the block sought). The result will be in step 82 for the client device to obtain from the random servers 20-24 a block α
⊕f(K,“AppName”∥α
∥z
), j=π−1(i). In step 84, the client device 16 asks the server D 10 for the jth block of the oblivious database, i.e., y
. In step 86, the client device 16 computes the the desired block x
=α
⊕f(K,“AppName”∥α
∥z
)⊕y
.
Referring now to (i.e., x
), making it necessary to update the corresponding oblivious database block y
, which is queried directly by users. However, it is desired to make changes in a way that does not allow server 10 to establish that j=π−1(i). If changes to y
are naively made shortly after x
is updated, then the server 10 will be able to learn the permutation. The present invention is based on making changes, to the oblivious database y
in an order that is independent of how the database x
changes, and in a way that keeps the changes in y
unpredictable from the known changes in x
. In other words, each incremental change made to y
does not reveal to the server 10 which of the x
's it was that triggered the change.
In step 100, prior to receiving the first update from server D 10, the random servers A1 20 and A2 22 jointly agree on a new pseudorandom permutation π0, which will be used to define the order to send bits of data that will be used to update the oblivious database y. Note that π0 is unrelated to π held by the random servers 20, 22. Additionally, they establish a coin toss that allows them to switch roles in the protocol either as a randomizer or a timer. A randomizer deals out a share of α
to the other random server(s), such that the sum of their shares (mod2) is the same as α
. A timer adds the evaluation of f(K,“AppName”∥α
∥z
) (using the current timestamp z
) to its update piece for y
(described below). The coin toss might be established from the bits output by a pseudorandom generator sharing a common key and state (e.g., AES on the string of the application name with the same key and initialization vector, where a ‘0’ and ‘1’ could indicate a randomizer or timer). Suppose that the original ith block is x
and the updated ith block is x
.
In step 102, server D 10 computes =x
⊕x
,
1, and
2, such that
1⊕
2=
. Then it sends {i,
1} to server A1 20 and {i,
2} to server A2 22. In step 104, on receipt of
1, server A1 20 computes u
=
1⊕α
1⊕f(K,“AppName”∥α
∥z
) using the current timestamp z
for z
if role is timer, otherwise it uses the saved timestamp value if role is randomizer. In either case, it updates the value of z
←z0 after the computation. It then saves u
to a dataset u stored in an update cache in server A1 20. In step 106, on receipt of
2, server A2 22 computes v
=
2⊕α
2⊕f(K,“AppName”∥α
∥z
) using the current timestamp z
for z
if role is timer or the saved time if role is randomizer. Afterwards, it then updates the timestamp z
←z
and saves v
to a dataset v stored in an update cache in server A2 22. In step 108, both server A1 20 and server A2 22 follow the order defined by π0 to respectively send a single block of u and v to the database server D 10. Once a block u
or v
is sent, each random server 20, 22 resets its slot to ⊥. In step 110, on receipt of {j,u
} and {j,v
}, server D 10 can compute the new block as y
=y
⊕u
⊕v
={circumflex over (x)}
⊕α
⊕f(K,“AppName”∥α
∥z
). Note that f(K,“AppName”∥α
∥z
) re-randomizes y
irrespective of whether x
changes or not. The database owner will be unable to predict if x
has changed or not. After all the blocks of u and v corresponding to the last index of π0 has been processed, the random servers 20, 22 picks a different π0, a different π and then repeats the above steps to help update the oblivious database y
. Finally, server D 10 can compute a new block of oblivious data y
=π12(u1)⊕v1⊕y0, which would give π1(x1⊕α1) for the updated block of x and π1(x0⊕α1) for the unchanged blocks.
While preferred embodiments of the invention have been described and illustrated above, it should be understood that these are exemplary of the invention and are not to be considered as limiting. Additions, deletions, substitutions, and other modifications can be made without departing from the spirit or scope of the present invention. Accordingly, the invention is not to be considered as limited by the foregoing description but is only limited by the scope of the appended claims.
This application claims the benefit of U.S. Provisional Application Ser. No. 61/817,463, filed Apr. 30, 2013, the specification of which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
61817463 | Apr 2013 | US |