The invention relates to the field of identification processes, comprising the obtaining of candidate referenced data to be compared to a data to be identified, and the comparison of the candidate data with the data to be identified to detect a matching, for instance in order to carry out identification of individuals based on the comparison of some biometric features.
The invention can in particular be implemented in the field of cloud computing, wherein the data is stored by a remote storage server.
The rise of cloud computing leads to new opportunities for biometric applications. Large biometric databases can be stored at small cost on servers that are accessible by any device, even with low computational capacities. However, using remote databases on untrusted servers raises privacy issues, especially with biometric data that are particularly sensitive.
Two main concerns are the confidentiality of these data and the privacy of access patterns. Encryption alone is consequently insufficient, since it does not protect the access patterns. Furthermore, encrypting data can have a big impact on the usability of the database. If the user has to retrieve the whole database to perform an identification protocol, then he loses the benefit of outsourcing his data. It has been proposed in EP2248071 an identification protocol over encrypted biometric data that preserves the privacy of the users. The identification process follows the structure of the “Beacon Guided Search” (BGS) introduced by Hao et al. in the publication by F. Hao, J. Daugman, and P. Zielinsky, “A fast search algorithm for a large fuzzy database”, IEEE Transactions on Information Forensics and Security, 3(2):203-212, 2008.
In this scheme, to identify a biometric acquisition against a database, this acquisition is hashed by several locality-sensitive hash functions. These hash functions output, with good probability, the same value on data that are sufficiently close and different values for data that are sufficiently different.
More specifically, the mathematical definition of a Locality-Sensitive Hashing function (LSH function) is as follows: let B be a metric space, U a set with smaller dimensionality, r1,r2∈ with r1<r2, and p1,p2∈[0,1] with pt>p2. A family H={H1, . . . , Hk}, Hj:B→U is (r1,r2,p1,p2)−LSH if for all h∈H, x, x′∈B, Pr[h(x)=h(x′)]>p1 if dB(x,x′)<r1) and Pr[h(x)=h(x′)]<p2 if dB(x,x′)>r2.
The elements of the database that lead to common hashed values are then selected for full matching operations from which we can deduct the identification results.
The biometric references are stored in an encrypted fashion in one remote biometric database. In other remote database, the hashed values of these references are also encrypted and stored.
To achieve this scheme while preserving privacy of the access patterns, some cryptographic patterns known as private information retrieval (PIR) and private information storage (PIS) are used; that respectively enable to read from or to write on a database, without revealing the indices of the data that are read (resp. written).
Unfortunately, such protocols are not yet usable in practice, especially with the sizes of the databases and the number of requests considered in the aforementioned publication, as they are too costly in terms of computation time.
Moreover, the identification protocol disclosed in EP2248071 requires the use of Bloom filters, which make it even more costly in computation time and even less efficient.
For these reasons there is a need for providing a more efficient identification method, for using data stored in a remote storage system, which ensures both data confidentiality and privacy of the access patterns.
Thus, one object of the invention is to provide a process for obtaining candidate reference data to be compared to a data to be identified that can be implemented through the use of a remote storage server, and that ensures both confidentiality of the stored data and privacy of the access patterns to the remote server.
According to the invention, a process for obtaining candidate reference data to compare to a data to be identified is provided, implemented in a system comprising a client unit and a storage server comprising two databases, in which:
In some embodiments, the process can comprise the following features:
A data processing method is also provided, implemented in a system comprising a client unit and a storage server comprising two databases, in which:
The invention also provides systems, units and computer program products for implementing said process and method.
A system for the secure storage and access to data is also provided, comprising a client unit, and a storage server comprising two databases, the system being configured to implement the aforementioned process, wherein:
An initialization process is also provided for the above-mentioned system, comprising the steps during which:
A process is also provided for enrolling an i-th reference data in the above-mentioned system, comprising the steps during which:
The features and advantages of the invention will be apparent from the following more detailed description of certain embodiments of the invention and as illustrated in the accompanying drawings, in which:
With reference to
The system 1 comprises a storage server 10, comprising two databases DB 1 and DB2.
The first database DB1 comprises N indexed memory blocks of n bits. In this database are stored reference data, such as biometric data. n is thus the bit length of each reference data stored in this database.
If reference data are biometric data, they can be of various natures, such as iris codes, fingerprints codes, etc.
As a non-limiting example, reference data can be iris codes, which can for instance be obtained using the encoding process disclosed in the publication by J. Daugman, “How Iris Recognition Works” (IEEE Transactions on Circuits and Systems for Video Technology, Vol 14, No. 1, January 2004). In this case each iris codes comprises iris bits describing a small zone of the iris X=(X1, . . . , Xn) and mask information M=(M1, . . . , Mn), which indicates zones of the iris that are not relevant for the identification, as they may be hidden by eyelids, lashes, reflects, or may be blurred, and which therefore must not be considered. One data comprising the iris and the mask is coded on 512 bytes.
The second database DB2 also comprises indexed memory blocks that are described below.
The system 1 also comprises a client unit 20, which can be for instance a server of a service provider for one or a plurality of clients 30 (which are not part of the system), the client unit 20 being configured to communicate with said clients 30. Said clients 30 can be mobile terminals, or else the client unit can itself be a data processing unit of a mobile terminal of a client having access to the storage server 10.
Advantageously, the storage server 10 (and its databases) is a remote server part of a public cloud, i.e. a server that is not part nor has any physical link with the client unit 20 but can be accessed through a network.
The databases are hence also remote from the client unit 20 and provide additional memory capacities to the client unit.
The storage server 10 and the client unit 20 are configured to carry out a protocol called Oblivious RAM protocol. More specifically, they are configured to implement two distinct instances of this protocol, one for each database.
Oblivious RAM (for Random-Access Memory) is a primitive for hiding storage access patterns, originally intended to hide a program's memory access patterns, as originally disclosed in the publication by O. Goldreich and R. Ostrovsky; “Software protection and simulation on oblivious rams”, J. ACM, 43(3):431-473, 1996, 1, 2.
In the model of oblivious RAM, we consider a client C that stores data on a remote untrusted server S. The data of the client C consist in N blocks of size B bytes. The blocks are encrypted, in order to preserve their confidentiality, and they are organized in a specific way to preserve de client's privacy.
The client can make two kinds of requests.
An ORAM request is written (op,u,data), where op=read or write, u denotes the block that is being read or written and data is the data being written. The read request is thus written read(u) and the write request is written write(u,data).
When a client makes a request, this request is compiled by an ORAM construction into instructions for the server on this real storage that preserve privacy of the requests, i.e. instructions such that the server learns no information on the original request and cross-check different requests to infer some pieces of information.
Instead of using cryptographic techniques as in PIR constructions, oblivious RAM privacy guarantees are mostly based on the way the user accesses its remotely stored data. Consequently, operations performed by the client and the server have a very small cost, the performance measured being the ratio between the bandwidth required by the Oblivious RAM protocol and the bandwidth that would have been required for remote storage access without privacy considerations.
Another protocol than the Oblivious RAM may be implemented such that the oblivious storage, disclosed in the publication by M. T. Goodrich, M. Miztsenmacher, O. Ohrimenko, and R. Tamassia: “Practical oblivious storage”, CODASPY 2012: 13-24.
An initialization process 100 of the system 1 is described with reference to
The client unit 20 selects 110 a LSH family H of k (for instance k=128) indexed hash functions from B to U, where B is the space of the reference data stored in the first database, with n being the bit-length of the elements of B. Advantageously, the family is adapted to the biometric data involved in the identification process disclosed below.
Let m be the bit-length of the elements of U. Let ϕ(H,N) be an estimation of the maximum number of reference data, out of N being the maximum number of reference data stored in DB1, that will share the same output, over all possible outputs, of all k LSH functions of H.
In the example of data being iris codes, the hash functions are preferably projections of the part of the iris codes which does not contain the masks on smaller 10-bit vectors.
The client unit and the storage server set up, during a step 120, two instances of Oblivious RAM:
The client unit 20 also initializes the second database DB2 during a step 130, by indexing all the memory blocks of DB2 by all possible hash values obtained by the hash functions of H.
For instance, the indexes of the 2m first blocks of DB2 will correspond to the 2m possible hash values obtainable with H1. The indexes of the 2m next blocks will correspond to the 2m possible hash values obtainable with H2 etc.
Data processing comprises enrolment steps 200 for enrolling new reference data into the databases, and identification steps 300 when a user provides the client unit with a (possibly unregistered) data b, which is advantageously a biometric sample.
As shown on
With reference to
All the reference data are enrolled in the first database DB1 under an encrypted form, as the remote server is untrusted. To this end, the client unit may receive via a secure connection (for instance from clients 30) or acquire the reference data under unencrypted form and encrypt them during a step 205 prior to enrolling them.
During a step 220, the client unit 20 computes the k hashed value of the reference data bi, under an unencrypted form, obtained by each one of the k hash functions H1, . . . , Hk, denoted by hi1, . . . hik. For j=1, . . . , k, the client unit reads the memory block DB 2 indexed by hj, concatenates I to the content of this blocks and writes the modified content of this block at the same index hj. Thus, the client unit adds the index i of the enrolled reference data bi to the contents of all the memory blocks of DB2 corresponding to hash values of bi by the hash functions, using a write instruction of the ORAM2 instance.
The ORAM instructions are noted: block:=read(ORAM2,Hj(b)∥j), then write(ORAM2,hij,block∥i), where ∥ denotes concatenation.
Then, as shown in
Thus, during the process of obtaining candidate reference data of an identification process, the client unit computes 310 the hash values of the data b to be identified obtained by every hash function.
The client unit makes k read requests 320 to the second database DB2, by implementing the ORAM 2 protocol, on the blocks indexed by the hashed value thus obtained by the hash functions Hk out of the biometric data b to be identified. The k blocks thus obtained contain lists of indices of reference data having the same hash values by the same functions.
The ORAM instructions are as follows: for j=1, . . . , k, let hj=(Hj(b)∥j), the client unit executes blockj=read(ORAM2,hj).
The client unit looks 330 for the indices i1, . . . , il that appear in at least t out of these k blocks, where t is a given threshold comprised between 0 and k, that is chosen as a trade-off between accuracy and efficiency. For instance t=3.
The client unit then gets 340 the candidate reference data indexed by using read calls by implementing the ORAM1 protocol associated with the first database DB1, bi=read(ORAM1,i), for i=i1, . . . , il.
The identification process based on the comparison of the candidate reference data to the data to be identified then comprises the comparison 350, by the client-unit, of the data b to be identified with each of these data.
In the case of data to be compared being iris codes, the comparison may be carried out by computing the Hamming Distance between a reference data and the data b to be identified.
The Hamming Distance is therefore written, for two data B1=(X1,M1) and B2=(X2,B2) to be compared:
The comparison is preferably carried out between the data in unencrypted form, thus the client unit decrypts 345 the reference data prior to carrying out the comparison.
If there is a match between the data b and one of the reference data bi, the identification process outputs 360 a signal indicative that a matching occurred. For instance the signal may be “1”, or the index match. If there is no match, another signal, such as “0” may by output.
Thus, the proposed process allows to securely store reference biometric data in a remote database, and to easily access some of these data in order to perform identification without having to download the whole set of stored database.
Number | Date | Country | Kind |
---|---|---|---|
13305268 | Mar 2013 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2014/054697 | 3/11/2014 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2014/140009 | 9/18/2014 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
8706701 | Stefanov | Apr 2014 | B1 |
9729548 | Patey | Aug 2017 | B2 |
20010025342 | Uchida | Sep 2001 | A1 |
20070005511 | Martinez | Jan 2007 | A1 |
20070046476 | Hinkamp | Mar 2007 | A1 |
20090074259 | Baltatu | Mar 2009 | A1 |
20100033304 | Takagi | Feb 2010 | A1 |
Number | Date | Country |
---|---|---|
WO-2012093216 | Jul 2012 | WO |
Entry |
---|
European Search Report and Written Opinion, dated Apr. 9, 2014, European Application No. 13305268. |
International Search Report and Written Opinion, dated Sep. 18, 2014, Application No. PCT/EP2014/054697. |
Bringer, Julien , et al., “Identification with Encrypted Biometric Data”, Retrieved from the Internet: http://arvix.org/pdf/0901.1062v2.pdf, (Sep. 7, 2009). |
Kozak, Stepan , et al., “Secure Metric-Based Index for Similarity Cloud”, Secure Data Managment, (Aug. 27, 2012), 130-147. |
Kuzu, Mehmet , et al., “Efficient Similarity Search over Encrypted Data”, 28th International Conference on Data Engineering, (Apr. 1, 2012), 1156-1167. |
Lu, Steve , et al., “How to Garble RAM Programs”, International Association for Cryptological Research, vol. 20130313:162324, (Mar. 8, 2013), 1-27. |
Park, Hyun-A , et al., “Efficient Keyword Index Search over Encrypted Documents of Groups”, Intelligence and Security Informatics, (Jun. 17, 2008), 225-229. |
Pinkas, Benny , et al., “Oblivious RAM Revisited”, International Associated for Cryptologic Research, vol. 20100625:125210, (Jun. 22, 2010), 1-11. |
Stefanov, Emil , et al., “Towards Practical Oblivious RAM”, ARXIV, (Dec. 18, 2012). |
Number | Date | Country | |
---|---|---|---|
20160019211 A1 | Jan 2016 | US |