Method for confidential interrogation of a database

Abstract

The invention relates to a method for confidential interrogation by a user (U) of a database (DB), with a view to obtaining sought information, the method comprising the following steps: S10) the user determines a hash; S20) the user calculates a request (R) containing an encrypted collision-class identification vector (VIC) depending on the hash, and an encrypted record identification vector (VIE); S30) via a method for retrieving private information, the server determines the FHE ciphertext(s) of the sought collision class (V); S50) based on the record identification vector (VIE), the server determines, via homomorphic calculation, a ciphertext of the sought information, and transmits it to the user; and S60) the user then decrypts the ciphertext of the sought information.

Description

Description Title: Method for confidentially querying a database TECHNICAL FIELD OF THE INVENTION [1] The field of the invention is that of the confidential interrogation of databases for the purpose of recovering private information. STATE OF THE ART [2] Querying databases for the purpose of retrieving private information is an operation in which a user transmits a query, i.e., a request for information to a database, and obtains in return a response from the database from which he can obtain the information sought, the database never having, throughout the transaction, had the slightest information either as to the information sought, or as to whether the information sought was found or not. [3] Such operations are carried out in particular when a user's database is entrusted to a third-party operator, who then stores the database on a remote server. Although the database is stored on the server, it remains the property of the user. In this context, it is necessary to provide guarantees of confidentiality on the database with respect to the server while allowing the latter to provide the expected service. More precisely, we wish to ensure: - the confidentiality of the recordings stored on the server, vis-à-vis the latter; - the confidentiality of requests from the user, vis-à-vis the server; and - the confidentiality of the information produced by the server in response to requests sent to it (such as indications regarding the presence of certain records in the database, etc.), always with respect to the server. [4] To enable the maintenance of such confidentiality conditions, particularly in the context of outsourced databases, different methods of recovering private information have been developed, these methods using homomorphic encryption methods in particular. [5] In cryptography, a cipher function is a function that operates on a set whose elements are called 'plaintexts'. At each clear, the encryption function associates one or more images (possibly probabilistically) called 'ciphertext(s)'. Conversely, the function which associates the corresponding clear to a ciphertext is called the decryption function. The encryption function and the associated decryption function together constitute a cryptosystem. [6] Among cryptosystems, homomorphic encryption cryptosystems have been used in particular to perform private information recovery functions. [7] Homomorphic encryption allows operations (in practice operations based on addition or multiplication) to be performed on data without ever revealing them. Homomorphic encryption is defined for example in the international patent application WO2020 / 070455 A1. [8] A homomorphic cryptosystem is, ideally, an encryption system permeable to any type of operation on encrypted data. With any record X and evaluation function f, denoting E the encryption function, it allows to obtain the ciphertext E(f(x)) of the image of a record X by the evaluation function f in a non-interactive way from the ciphertext E(x) of the record. [9] Among homomorphic cryptosystems, an additive homomorphic cryptosystem is a cryptosystem comprising at least addition as an elementary operation of homomorphic calculation.

[0010] Furthermore, a homomorphic cryptosystem for which the space of evaluable functions is the space of computable functions is called an FHE cryptosystem. The encryption function of such a system is called 'Fully Homomorphic Encryption' (FHE). A ciphertext obtained by such an encryption function is called an 'FHE ciphertext'.

[0011] In an FHE cryptosystem, the parameters can be chosen independently of the depth of the homomorphic computation to be applied. Examples of fully homomorphic cryptosystems are presented by the papers Ref. 2, 6 and 7 listed below.

[0012] Document Ref.[1] also listed below discloses a known method for retrieving private information. In this method, the database is structured in advance into collision classes. The user sends a query to a server containing a vector of ciphertexts, only one of which is the ciphertext of the collision class in which the requested record is located; based on this request, the server determines a cipher of this collision class, by implementing an encryption function of an additive homomorphic cryptosystem. This cipher is returned to the user, who decrypts it and can then obtain the requested information.

[0013] This method has the advantage of being able to be applied to very large databases; however, it has the disadvantage that it leaves part of the information search task to the user, since he must himself find the information sought within the collision class.

[0014] This method also has the disadvantage of being difficult to apply to obtain information relating to noisy data, for which the information search method must make it possible to find the information sought despite the noise present in the data (non-exact matching).

[0015] The following papers present methods in the field of homomorphic encryption. Paper [Ref.7] presents various known FHE cryptosystems, including the BFV, BGV, CKKS, and TFHE cryptosystems. References: [1] EnQuery, LLC, « EncryptedQuery: Scalable Private Information Retrieval », 2018 [2] M. Zuber, S. Carpov and R. Sirdey, "Towards real-time hidden speaker recognition by means of fully homomorphic encryption", Proceedings of the 22nd International Conference on Information and Communications Security, LNCS 12282, pp. 403-421 , 2020. [3] Fan, J., Vercauteren, F.: Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, Report 2012 / 144 (2012) [4] hen, H., Laine, K., Player, R.: Simple encrypted arithmetic library - seal v2.1 (2017) [5] Brakerski, Z., Gentry, C., Vaikuntanathan, V.: Fully homomorphic encryption without bootstrapping. Cryptology ePrint Archive, Report 2011 / 277 (2011 ) [6] Gentry, C.: Fully homomorphic encryption using ideal lattices. In: Proceedings of the Forty-first Annual ACM Symposium on Theory of Computing. STOC '09 (2009) [7] Jiang, L., & Ju, L. (2022). Fhebench: Benchmarking fully homomorphic encryption schemes. arXiv preprint arXiv:2203.00728. STATEMENT OF THE INVENTION

[0016] The present invention aims to remedy all or part of the drawbacks of the state of the art cited above and to propose a method of confidential interrogation of a database hosted by a server making it possible to obtain the information sought, a method which can be used on large databases, which requires a reasonable amount of calculation and therefore conversely relatively low response times, and finally preferably which can also be used for searching for information in databases containing noisy data.

[0017] To this end, according to the present disclosure, the following method is proposed. This method is a method of confidential query by a user of a database comprising records and hosted by a server to obtain sought information relating to (or a function of) one or more records of the database satisfying a criterion, the criterion being a function of a record identification key, the record identification key being a vector of value(s) of one or more fields of a record; a hash function being defined such that, for a given criterion, all records satisfying the criterion generate the same hash; a set of records having the same hash being called a collision class; the method comprising the following steps to obtain sought information, a function of a record identification key: S10) the user determines a hash, called the hash of the collision class sought, common to all records satisfying the criterion defined based on the record identification key; S20) the user calculates a query comprising an encrypted collision class identification vector, a function of the hash of the collision class sought, as well as an encrypted record identification vector, a function of the record identification key, and sends the query to the server; S30) based on the collision class identification vector, by a private information recovery method the server determines one or more ciphers FHE of the searched collision class, representing the collision class of the hash of the searched collision class; S50) from the record identification vector, the server determines by homomorphic calculation a cipher of the information sought based on the result(s) of an evaluation of the criterion for the cipher(s) of the collision class sought, and transmits the cipher of the information sought to the user; and S60) the user then decrypts the ciphertext of the information sought and thus obtains the information sought.

[0018] In this document, the expression 'encrypted vector' means a vector whose component(s) are encrypted.

[0019] The method defined above mainly involves two calculation steps for the server.

[0020] To implement the method, the hash function is previously chosen to ensure that all records that satisfy the criterion (the criterion then being defined from (or as a function of) the identification key of the record considered) have the same hash, called the hash of the collision class sought.

[0021] In a first step S30, also called pre-processing, the server determines the cipher(s) of the collision class sought. This cipher(s) represents the entire collision class sought.

[0022] This collision class is the collision class that includes all records that meet the criterion defined based on the record identification key: these records are those that will allow the information sought to be obtained. This sought collision class is identified by one or more ciphers, called 'ciphers of the sought collision class'.

[0023] From step S30, the calculations are advantageously carried out solely on the basis of the figures of the collision class sought, i.e. normally on a number of records considerably smaller than the total number of records in the database.

[0024] Preferably, to facilitate the performance of step S30, even before implementing the method, the database is structured into collision classes for the hash function.

[0025] During the second step S50, or post-processing, the value of the criterion is evaluated on the whole of the figure(s) of the collision class sought; a figure of the information sought is then obtained from the results of this / these evaluation(s).

[0026] Preferably, step S50 comprises the following steps: S52) the server evaluates the criterion for the cipher(s) of the collision class sought by performing the following operations: 5521) the server performs one or more distance calculations; and 5522) the server compares one or more results obtained in step S521 to a threshold (this comparison may consist of verifying one or more equations and / or one or more inequalities); then S54) the server calculates the encrypted value of the information sought.

[0027] The distance calculation performed in step S521 may be any calculation in which a distance between data contained in the database and the record identification vector (or some components thereof) is evaluated.

[0028] The second step S50 is preferably performed entirely by the server. Since the ciphertexts of the sought collision class are FHE ciphertexts, the calculations performed in step S50 are executed by the server on FHE ciphertexts. No usable information is therefore communicated in clear to the server. Thus, advantageously, the user only has to perform a small amount of calculations in step S60, corresponding to the decryption of the sought information.

[0029] Advantageously, the method defined above allows a decorrelation between the size of the database and the volume of complex calculations carried out in step S50. Indeed, during this last step, the amount of calculation depends only on the number of records in the collision class selected during the first phase, but does not depend on the total number of records in the database.

[0030] In certain cases, the calculations carried out on the server in step S50 do not result in finding information corresponding to the information sought.

[0031] In this case, of course, to ensure that no information is transmitted to the server, the homomorphic calculations executed on the server produce a result. The server does not know if this result has any meaning: the server returns this result, which can be either an encrypted version of the information sought, or an encrypted version meaning that no answer was found. For example, conventionally, in the latter case the server may return a value of -1 , the value '-1 ' conventionally meaning that no valid response was found.

[0032] The criterion used in step S50 naturally depends on the information sought.

[0033] In some implementations, the aim is to identify a specific, fully known record, or records in which one or more fields contain specific, pre-known values. (The criterion may then be of the form "record = X0" or "fields i and j of the record are equal to (XOi, XOj)"). These implementations are called 'exact matching'.

[0034] In other implementation modes, conversely, we seek to identify records that are either close to a certain predetermined record, or where one or more fields contain values ​​close to corresponding values ​​of fields in a reference record. The criterion can then be of the form "record X is the one that minimizes the value f(X), for all records X in the database (It therefore corresponds to the image obtained by the Argmin function for the function f). The information sought can be the record itself, or a value that identifies this record. These implementation modes are called 'approximate matching'.

[0035] The server is naturally configured to, from the record identification vector (and the cipher(s) of the collision class sought), be able to carry out step S50. For this reason, most often the criterion to be evaluated is already known to the server, as well as the information sought which will then be necessary to calculate from the result(s) of the evaluation of the criterion.

[0036] When the information sought is the identical presence of a record in the database (exact matching), any compression function applicable to the records can be used as a hashing function to carry out step S20.

[0037] For example, in one implementation the hash function outputs a hash encoded on m bits.

[0038] This solution is also particularly interesting in the case of noisy data: the hash can constitute an invariant which will be invariant for all records considered to be identical (for example, concerning the same person if the data is biometric data).

[0039] To implement step S30, any private database query method (or 'PIR' method, from the English 'Private Information Retrieval') can be chosen.

[0040] In some implementations, when the hashes provided by the hash function are encoded on m bits, the collision class identification vector has 2 m components; each component of index i among said 2 mcomponents is a cipher of 1 if the index i is equal to the hash of the collision class sought, or a cipher of 0 otherwise; and in step S30, a cipher V of the collision class is determined by the equation: v = SjVj with Vj = Rj * lj. (E)

[0041] For this method of implementation to be of real interest, 2 m should preferably be significantly smaller than the number K of elements in the database. Furthermore, for a collision class to be contained in a single row, preferably L is chosen such that 2 m L is greater than the number of records K (L designating the size of the rows in the database). The method thus advantageously makes it possible to make the processing time of a query proportional to 2 m (conventionally noted 'O(2 m)') homomorphic operations - and not proportional to the number K of records in the database (noted O(K)) or even a multiple of K (i.e. O(Nk)) in traditional approaches, and consequently to have substantial gains in terms of performance.

[0042] The record identification vector contains the specific information about the information being searched that will allow the server to extract a cipher of the information being searched.

[0043] In step S50, the server evaluates the criterion for the cipher(s) of the sought collision class. Then, on the basis of these evaluations, it determines a cipher of the sought information.

[0044] The information sought can be a Boolean variable, or a value depending on one or more fields of a record.

[0045] In the case of a Boolean variable, the information sought can be, for example, a presence indication, indicating whether a searched record is present in the database.

[0046] Naturally, the evaluation of the criterion, then the calculation of the encrypted information sought must be functions which can be broken down into elementary operations which can be carried out in a homomorphic manner. Examples of such homomorphic operations are for example given in document Ref.2, section 3.2.

[0047] The criterion can be evaluated, in particular, from the contents of the different fields of a record. The criterion may consist, for example, in identifying one (or more) record value(s) that minimize(s) the output value for a certain function, called the evaluation function. In this case, the search for the record that satisfies the criterion amounts to an evaluation of an Argmin (or Argmax) type function. Such a criterion is generally chosen when the database contains noisy data, such as biometric profiles.

[0048] To implement a method according to the present disclosure, the database is preferably structured according to the collision classes of the hash function.

[0049] The server can then advantageously have a function allowing direct access to the collision class corresponding to the hash value considered.

[0050] Depending on the implementation mode, during step S30 the server can determine for a collision class either a single cipher or several ciphers. In the latter case the server can for example calculate a cipher per record of the collision class; such a cipher is called 'record cipher'.

[0051] When it comes to database encryption, there are different solutions that can be chosen.

[0052] In some implementations, database records are encrypted by an encryption function of a non-homomorphic cryptosystem, including a symmetric cryptosystem.

[0053] In some implementations, database records are stored in cleartext or as non-FHE ciphertexts or as hashes obtained by a second secret-key hash function.

[0054] Conversely, in other implementations, the database records are FHE encrypted.

[0055] Furthermore, different cryptosystems may be chosen for implementing methods according to the present disclosure. In all cases, to ensure the security of information exchanges, the encryption functions used are probabilistic encryption functions, which are such that the ciphers of 0 and 1 are computationally indistinguishable.

[0056] The proposed method can be implemented with a single cryptosystem. Thus, in certain implementations, the homomorphic calculations performed in step S30 and in step S50 are performed using the same cryptosystem, in particular a TFHE cryptosystem.

[0057] Conversely, the proposed method can be implemented with several cryptosystems; the goal generally being to use for each calculation step the cryptosystem most suited to this step.

[0058] Step S30 is then normally carried out using a first cryptosystem. This first cryptosystem may also be used (or not) for all or part of step S50.

[0059] In step S50, in addition to or instead of the first cryptosystem, it is thus possible to use one or more cryptosystem(s) that are more suitable and / or more efficient than the first cryptosystem for the calculations to be carried out in step S50, in particular where appropriate for all or part of the different steps S52 and S54 indicated previously.

[0060] To ensure the conversion from one cryptosystem to another, in certain implementations the method further comprises a step S40 in which the server recalculates the cipher(s) of the collision class sought by applying a transcryption operation to it or them.

[0061] In some implementations, the database is encrypted using a symmetric non-homomorphic cryptosystem; the transcryption operation then serves to homomorphically remove the symmetric encryption layer.

[0062] In some of these implementations, a symmetric stream cipher primitive is used, and FHE ciphers of the secret / symmetric key of the stream cipher primitive are stored on the server.

[0063] In this case, the homomorphic ciphers of stream keys can be precomputed and stored in an ad hoc database. Alternatively, they can be computed online, each time the transcryption operation is to be performed.

[0064] Thus in certain cases, when in step S30 the ciphertexts V are calculated using the equation (E) indicated previously, in step S30, the server calculates the products Ri * li on a basis of FHE stream keys using a symmetric stream cipher primitive (or algorithm); and the method further comprises a step S40 in which the server recalculates the ciphertext(s) of the sought collision class by applying to it or them a transciphering operation, this transciphering operation being carried out by an exclusive OR operation in a homomorphic manner between the ciphertext(s) of the sought collision class and the FHE ciphertext of the corresponding stream key.

[0065] Above, the term "FHE stream keybase" means a keybase in which the stream keys are FHE ciphers.

[0066] In certain implementations, at step S50 the server determines the encryption of the information sought using: - a levelled homomorphic encryption scheme, in particular a BGV-type cryptosystem; or - a SHE type cryptosystem (from the English: 'somewhat homomorphic encryption scheme'), notably a BFV or CKKS type cryptosystem.

[0067] Indeed, in the latter case, SHE-type cryptosystems can advantageously withstand a certain level of noise. These SHE cryptosystems can be, for example, BFV-type cryptosystems (presented by document Ref.3), implemented for example by the SEAL library (see Ref.4).

[0068] BGV type cryptosystems are presented in particular by Ref.5. These cryptosystems advantageously allow batch processing, that is to say the performance of elementary operations simultaneously on several records grouped into a single encrypted one, therefore in parallel.

[0069] In certain implementations in which in step S50 the server (S) uses a cryptosystem of type BFV, BGV or CKKS, during the calculations performed in step S50 using this cryptosystem, an upper bound on a multiplicative depth of the homomorphic calculations is taken into account.

[0070] In certain embodiments, step S50 comprises steps S52 and S54 indicated previously; the homomorphic calculations carried out in step S30 and optionally in step S521 are carried out using the same first cryptosystem, in particular a BFV or BGV cryptosystem; and the homomorphic calculations carried out in steps S522 and S54 are carried out using the same second cryptosystem different from the first cryptosystem, in particular a TFHE cryptosystem. In the latter case, the choice of a TFHE cryptosystem is generally linked to the fact that TFHE cryptosystems can be particularly well suited to certain non-linear processing.

[0071] In some implementations, the identification of the collision class cipher(s) that satisfy the criterion in step S50 is done collision class cipher by collision class cipher, each collision class cipher corresponding to a record.

[0072] The methods according to the present disclosure can be implemented to search for information in databases comprising both exact and noisy data. The data can be stored in plain text or encrypted in various ways. In the following, the term 'encrypted' is used in the same sense as 'encoded'.

[0073] In some implementations, the recordings are images, or are obtained from images, for example using an encoder such as a neural network or the like.

[0074] Different types of encoders can be used to store data in the database.

[0075] For example, in some implementations, the records are hashes of noisy data structures. For example, in some implementations, the records correspond to biometric profiles. A 'biometric profile' here refers to any record in which at least one of the fields is noisy data relating to a human or an animal. BRIEF DESCRIPTION OF THE FIGURES

[0076] Other advantages, aims and particular characteristics of the present invention will emerge from the following non-limiting description of at least one particular embodiment of the devices and methods which are the subject of the present invention, with reference to the appended drawings, in which: - Figure 1 is a schematic view of a user and a server implementing a query method according to the present disclosure; and - Figure 2 is a flowchart showing the steps of an implementation mode of a query method according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0077] This disclosure relates to methods for confidential querying by a user of a database hosted by a server on a basis of encrypted records using hashing, PIR (homomorphic dot product) and FHE techniques.

[0078] As non-limiting exemplary embodiments, two methods of confidentially querying a database according to the present disclosure will be described below in the context of a client-server architecture illustrated by Fig. 1.

[0079] This figure shows a user U and a server S. The server S hosts a database T, for example a relational database.

[0080] User U is a computer, for example a PC, from which one seeks to obtain information sought confidentially from the database T.

[0081] The user U includes in particular one or more processors Pu, and a memory Mu.

[0082] The server S is, for example, a cloud computing service provider server. It contains one or more processors Ps, and a memory Ms in which the database T is stored.

[0083] The database T contains a large number K of individual data X. Each individual data X can have one or more fields and is called a 'record'. Each record can be in clear text or encrypted. It can notably be a cipher obtained by encryption using a symmetric cryptosystem.

[0084] Database records can be of any nature (text data (character strings, CSV, etc.), images, audio or video files, etc.).

[0085] The records can be encoded (or encrypted) by an encoder, for example a neural network type, before storage in the database (see the NN encoder shown in Fig. 1).

[0086] The first method following this disclosure that will be presented concerns a case of exact data matching.

[0087] Two variations of this method will be presented below.

[0088] In the first variant, the purpose of a query addressed by the user to the database T is to know whether a certain searched individual 'IC', identified by a unique character string (for example, his social security number), is registered in the database.

[0089] To obtain this information confidentially, that is, without the database having any information as to the subject of the query, a method according to the present disclosure can be implemented in the following manner.

[0090] A hash function h is determined in advance. Any hash function can be used since, when searching for certain information concerning database records satisfying a criterion, all records that satisfy the criterion generate the same hash.

[0091] If the result of the hash function is an m-bit word, we preferably choose m such that 2 m be small compared to the number K of records in the database.

[0092] The database T is then structured according to the collision classes of the hash function h.

[0093] For example, database records are stored as a table (a T table), in which each row corresponds to one of the possible hash values. This table therefore has 2 m lines, some lines possibly being empty, the others comprising one or more X record(s).

[0094] The hash function is chosen to divide the database into collision classes as efficiently as possible.

[0095] In table T, each collision class is recorded on one row.

[0096] Each collision class can contain between 0 (zero) and a predetermined maximum number M of records: table T presents 2 m rows and M columns.

[0097] The number M is preferably significantly less than the number of records K contained in the database itself, but sufficient to be sufficient in any case so that the number of records of a collision class does not exceed M.

[0098] In the first variant of the method presented here, the information sought is simply the fact that a Searched Individual, noted 'IC', identified by his social security number, is referenced or not by the database T. In this case, the registration identification key is the social security number NSS_IC of the searched individual.

[0099] The method is implemented as follows.

[0100] We choose a hash function h which takes as input a complete record X, and gives as output a hash h(X), this hash being calculated only on the basis of the first six digits of the social security number (the social security number being a number comprising thirteen digits).

[0101] Based on this hash function, the database is then structured into collision classes CC: each collision class contains the records of people whose social security number contains the same first six numbers. The database is therefore divided into 10 6 collision classes.

[0102] If the social security number of the individual being searched for begins with the digits 172057, for example, the corresponding hash, h(172057), is the hash of the collision class being searched for.

[0103] In step S30, the numbers of the desired collision class are determined.

[0104] These are recording ciphers.

[0105] To do this, in step S30 the server determines the FHE cipher(s) of the collision class sought by repeatedly performing the same calculation procedure: this calculation procedure is performed successively for each of the M columns of the table T. We therefore obtain M ciphers as output. If we assumes that the collision class sought contains N records with N strictly less than M, then we obtain as output the N record ciphers of the N records of the collision class, followed by MN ciphers 'from nothing', that is to say ciphers not corresponding to any record.

[0106] The details of the method used in step S30 will be provided later.

[0107] Then in step S50, for each of the figures obtained in step S30, it is evaluated by homomorphic calculation whether the applicable criterion is satisfied.

[0108] The applicable criterion, in this case defined based on the record identification key, is simply written (NSS = NSS_IC), NSS being the social security number, which is one of the fields of each record.

[0109] The result of the evaluation of the criterion for a given record is therefore a cipher of 1, E(1), if the criterion is satisfied (the individual considered has as social security number the social security number NSS_IC of the individual sought), and a cipher of 0, E(0), otherwise, E being the encryption function of the FHE cryptosystem. This result is sent to the user U (Fig.1).

[0110] In step S60, the user U decrypts the result and obtains the information sought as to the presence or absence in the database of a record whose social security number corresponds to that of the individual sought.

[0111] In this example, the chosen criterion defines an exact match of the searched record (an exact match) with respect to the record identification key, and not an approximate match (approximate match).

[0112] The information sought is the cipher obtained by adding the ciphers (E(0) or E(1)) returned during the evaluation of the criterion successively for all the ciphers of the collision class. The information returned is therefore a cipher of 1 E(1) if the individual sought is recorded in the database, and a cipher of 0 E(0) otherwise.

[0113] In accordance with the present disclosure, the evaluation of the criterion to be satisfied from the record identification key as well as the calculation of the information sought are done in the space of the ciphers, by homomorphic operations applied to ciphers of the records. The server thus has no information on the meaning of the processing that it carries out in steps S30 to S50.

[0114] In the second variant of the method, the information sought consists of additional information about the individual sought IC. The information The information sought can then be all or part of the X_IC record corresponding to the individual sought IC in the database. The information sought could be the pair comprising the values ​​'AddressJC' and 'Phone numberJC' giving the address and telephone number of the individual sought IC.

[0115] In this second variant, step S30 and then the evaluation of the criterion in step S52 are identical to the first variant. On the other hand, step S54 is different, since in this second case, the encrypted information sought is more complex than in the first case: it includes an encrypted value of the values ​​'AddressJC' and 'Telephone numberJC' of the database record whose field 'Social Security Number' corresponds to the individual sought IC.

[0116] The steps of the method will now be presented in more detail.

[0117] Here we assume that the result of the hash function h is a word of m bits.

[0118] In a first step S10, the user first calculates the query R to send to the server.

[0119] This query R includes two elements: the first encrypted vector VIC of Collision Class identification, function of the hash of the collision class sought, and the second encrypted vector VIE of Record identification, function of the Record identification key. These two elements are encrypted by the same FHE cryptosystem.

[0120] The first VIC vector, which has 2 m components Ri of index i, where i varies from 0 to 2 m -1 , is calculated from the hash of the collision class sought in the following way: for each value of i different from the hash of the collision class sought, the component Ri with index i is a cipher of 0, E(0). Conversely, for the value of i equal to the hash of the collision class sought, the component Ri is a cipher of 1 (E(1 )).

[0121] The first collision class identification VIC vector is thus composed of 2 mdifferent ciphers without the server being able to know which one is a cipher of 1.

[0122] For the implementation of the method according to the present disclosure, a probabilistic cryptosystem is used which admits a multitude of ciphers of 0, a multitude of ciphers of 1 and which are such that the ciphers of 0 and 1 are computationally indistinguishable (by 'multitude' we mean a very large number, for example greater than 2 128 , or a number exponential in the size of the key).

[0123] The characteristics of the second element of the R query, namely the VIE record identification vector, will be described later.

[0124] Once the query R is calculated, the user sends it to the server S.

[0125] Based on the collision class identification vector VIC, by a private information retrieval method, in step S30, the server determines at least a first cipher V of the searched collision class.

[0126] The expression 'at least one first ciphertext V' is used here because depending on the structure of the database T and the private information retrieval method used, the method may return one or more first ciphertexts V. The important thing is that this or these ciphertexts represent the entire collision class.

[0127] For example, in some cases a single ciphertext may be returned: this ciphertext then most often represents a set of several records. In other cases, the private information retrieval method may return one ciphertext per record of the collision class.

[0128] Conversely, in the example presented previously, a predetermined (bounded) number M of record ciphers is returned (the expression 'record cipher' designating a cipher corresponding to a given record).

[0129] Any private information recovery method (PIR method) can be used to perform step S30.

[0130] In the example presented here, upon receipt of the request R, at step S30, the server determines the cipher V of the collision class comprising the records likely to provide the information sought by carrying out the following operations:

[0131] In a first step S32, having received the query R from the user, for each possible hash value (each index value i, i varying from 0 to 2 m-1), the server calculates a cipher of class Vi which is the product of the component Ri by the collision class li associated with the index value considered.

[0132] In a second step S34, the server then calculates the cipher V which is equal to the sum over all possible index values ​​i (when I varies from 0 to 2 m -1) of all class Vi ciphers:

[0133] At the end of step S34, we therefore obtain the first cipher V. This is a cipher of the collision class corresponding to the hash of the collision class sought. If one or more records of the database T contain the information sought, this or these records are necessarily in this collision class.

[0134] To enable the second phase of the method to be carried out (step S50), the request also contains the VIE record identification vector. This contains the additional information enabling the server to identify (without knowing it) the records satisfying the criterion and thus ultimately to provide an encrypted version of the information sought.

[0135] In the example presented here, the VIE record identification vector is simply constituted by an encrypted version of the full social security number of the individual sought IC. In step S20, this second vector integrated into the query R is sent to the server S.

[0136] In some implementations, the FHE cryptosystem used in step S50 is different from that used in step S30: a transcryption operation is then necessary. In this case, the method then comprises the following step S40: S40) the server applies a transcryption operation to the cipher(s) of the collision class, so as to obtain one or more ciphers which are encrypted with the cryptosystem provided for step S50.

[0137] Then, in step S50 the server evaluates whether the criterion is satisfied for each of the encryption(s) of the collision class determined in step S30 (possibly transcrypted in step S40). On the basis of this or these evaluations, the server then calculates an encryption of the information sought. This encryption is then sent to the user.

[0138] In the example presented here, step S50 first comprises the criterion evaluation step S52.

[0139] During this step, the server evaluates the criterion for each of the ciphers of the collision class being searched for. To do this, for each cipher of the collision class, the server calculates a difference between the social security number of the considered cipher of the collision class and a cipher of the social security number of the individual being searched for. If this difference is a cipher of '1', this means that the criterion is satisfied, that is, the considered record of the collision class is indeed a record with the same social security number as that of the individual being searched for.

[0140] In step S54, the server therefore calculates the ciphertext of the information sought and transmits it to the user. This ciphertext is obtained by simply adding the ciphertexts obtained for all the ciphertexts of the collision class.

[0141] Advantageously, step S50 is carried out by the server, only from encrypted files, thanks to the fact that all operations can be carried out between FHE encrypted files.

[0142] This allows the various calculations necessary in step S50 to determine the encrypted information sought based on the result(s) of an evaluation of the criterion for the encrypted information(s) of the collision class to be carried out from encrypted information. Consequently, instead of obtaining the information sought from the list of records, an encrypted information of the sought information is obtained in step S50 from encrypted information of the records.

[0143] We can refer to section 3, and in particular to section 3.2 of document Ref.2 to see how, thanks to an FHE cryptosystem, operations normally carried out in the cleartext space are replaced by so-called 'homomorphic' operations carried out in the ciphertext space.

[0144] Advantageously, these operations, being carried out on encrypted data by the server, make it possible to obtain the encrypted data of the information sought by only requesting the server, but without communicating to it the slightest information in clear text about the object (person) sought.

[0145] In some cases, depending on the type of information sought and the database considered, several records may satisfy the criterion.

[0146] In this case, to avoid transmitting information about the information sought, preferably an upper bound on the number of records that will be considered as satisfying the criterion is set to advance: for example, we choose a number N as this upper bound.

[0147] Thus, during step S50, the server successively evaluates N times for all the records whether the criterion is satisfied. From the N results of evaluation of whether the criterion is satisfied or not, the server then calculates the encrypted version of the information sought, and transmits it to the user.

[0148] Finally, in step S60, upon receipt of the encrypted form of the information sought sent by the server S, the user decrypts this encrypted form and thus obtains the information sought.

[0149] Advantageously, operations S30 and S50 are performed by the server storing the database; they therefore do not require the user to have computing power or storage capacity.

[0150] Additionally, the collision class being searched for is not disclosed to the server (only the collision class ciphers are known to the server).

[0151] The second method according to the present disclosure will now be presented.

[0152] In this second method, the database T contains noisy data, for example images, sound recordings, biometric recordings, etc.

[0153] The user wants to find the record(s) most similar to, closest to, a reference record X0.

[0154] The result of such a search can be provided by an evaluation function of type argmin / argmax, i.e. a function that determines the value (record) that maximizes or minimizes a cost function among a set of possible values ​​- among the records in the database.

[0155] The traditional approach to performing such a search would be to calculate all the distances between the reference record X0 and the different records, then to calculate the minimum or the maximum: Such an approach is known but is difficult to apply if the database contains a large number of records.

[0156] According to the present disclosure, it is preferable instead to organize the database T in advance into location / collision classes. Each class contains several records (preferably with a maximum number of records per collision class). The first step S30, of pre-processing, is carried out in the cipher space, using a first FHE cryptosystem.

[0157] In one implementation, for example, user U attempts to determine whether a record corresponding to a particular person, characterized by their biometric profile, is present in database T.

[0158] This biometric profile can be, for example, encoded data, calculated from certain data relating to the person. The biometric profile in this case is obtained from photos of the person's eyes, by appropriate encoding (carried out for example by a neural network or other).

[0159] In this case, the query R transmitted by the user will aim to obtain the record(s) of persons, recorded in the database, and whose biometric profiles are closest to the biometric profile of the person sought in relation to a predetermined proximity threshold. This condition of proximity between a biometric profile and the biometric profile of the person sought therefore constitutes the criterion which must be satisfied within the meaning of this disclosure. The user U obviously has the biometric profile of the person sought.

[0160] To calculate the query R, ​​we first choose the hash function from among the hash functions applicable to noisy data. We choose a hash function that gives the same hash for biometric profiles that only differ from each other by a value lower than the predetermined proximity threshold.

[0161] In the example presented here, we choose a hash function that returns as output a hash representative of the eye color of the person in question. The hashes are encoded on 128 values. Thus, the hash function allows us to classify the records into 128 collision classes corresponding to 128 encodings of the different possible eye colors.

[0162] In step S10, the user determines the hash of the searched collision class, which corresponds to the eye color of the searched individual.

[0163] In step S20, the user calculates the corresponding query: this includes an encrypted collision class identification vector VIC, which is a function of the hash of the collision class sought, as well as an encrypted record identification vector VIE, which is an encrypted version of the eye color of the person sought. It sends the query R to the server.

[0164] In step S30 the server determines the FHE ciphers of the searched collision class, which represent the collision class of the hash of the searched collision class.

[0165] In step S50, in the cipher space, the server evaluates by homomorphic calculation the evaluation criterion for each of the ciphers of the sought collision class. The server determines - without knowing it - by homomorphic operations between the ciphers of the collision class, the record of the collision class whose biometric profile (eye color) is at the lowest distance from the biometric profile (eye color) of the sought person.

[0166] In another embodiment, at step S50 the server may be configured to identify the N (for example, the 5) records whose biometric profile (eye color) is closest to the biometric profile (eye color) of the person being searched for.

[0167] These different operations are carried out by elementary homomorphic operations, based solely on the numbers of the biometric profiles considered.

[0168] When the above operations have been performed for all the ciphers of the sought collision class, the server S returns the N identified ciphers to the user.

[0169] In step S60, the user decrypts each cipher in the list of ciphers of detected person records and thus obtains the set of person records sought. Different encryption options for the database

[0170] The methods according to the present disclosure can be implemented in different ways with respect to the encryption of the database.

[0171] In the first case, the database records are not obtained by FHE encryption (i.e., they are not FHE ciphers, i.e., ciphers obtained by the encryption function of an FHE cryptosystem). This does not mean, of course, that the records are not encrypted or encoded.

[0172] So for example, the database can be a secondary database, consisting of the initial record hashes that are stored in clear in a primary database, these hashes being obtained using an initial hash function with a secret key.

[0173] It is then sufficient to consult the secondary database containing the hashes of the initial records, for example, when one only seeks to evaluate the presence of one or more specific records in the database.

[0174] The hash function used to structure the secondary database into collision classes can then be the function that outputs the first m bits of the hash obtained by the initial hash function.

[0175] In this first case, at step S32 indicated previously, the homomorphic multiplications carried out are multiplications between a plaintext and an encrypted text. This mode of implementation therefore allows a high level of performance (in terms of required computing power), the plaintext / encrypted multiplications being generally less expensive in computing time than the encrypted / encrypted multiplications. At the end of the scalar product step S32, we therefore recover an FHE encrypted text of the collision class.

[0176] In a second case, the database records are obtained by FHE encryption, which naturally preserves the confidentiality of the stored data.

[0177] In this second case, at step S32 the homomorphic multiplications carried out are multiplications between a ciphertext and a ciphertext, with nevertheless a multiplicative depth cost of only 1. At the end of steps S32 and S34 of calculating the scalar products and summation, as in the previous case, the server obtains an FHE ciphertext of the collision class on which it can continue the processing at step S50.

[0178] In a third case, the database is encrypted using a non-homomorphic cryptosystem, advantageously a symmetric cryptosystem.

[0179] In this case, at step S32 the homomorphic multiplications performed are multiplications between a symmetric ciphertext, which is a non-FHE ciphertext, and an FHE ciphertext. These multiplications are therefore most often simpler than FHE ciphertext-FHE ciphertext multiplications.

[0180] However, at the end of step S34, an FHE cipher is recovered from a symmetric cipher of the collision class.

[0181] In order to continue processing, the server will therefore have to transcrypt, i.e. homomorphically remove the symmetric encryption layer. However, since the collision class is relatively small, this is not prohibitive in terms of performance. In addition, this does not require an intermediate decryption step in the plaintext space. Thus, despite this transcryption operation, due to the small size of the collision class, the computation time generated by the transcryption operation is generally relatively limited and therefore acceptable.

[0182] To reduce this computation time, in some implementations a stream of encryption keys (or 'keystreams') used for the FHE cryptosystem used is computed in advance.

[0183] Operation S30 is then performed taking into account this flow of encryption keys. It provides the first cipher of the collision class corresponding to the characteristic hash, but encrypted using the first cryptosystem, which is symmetric and not FHE.

[0184] At the end of operation S30, it is therefore necessary to carry out a transcryption operation during operation S40, in order to have the second ciphertext V2 of the collision class, encrypted by an FHE cryptosystem. Advantageously, this transcryption can be carried out in a very simple manner, namely by simply carrying out a homomorphic XOR operation between the HE ciphertext of the collision class and the HE ciphertext of the encryption stream.

[0185] The transcryption operation provides the cipher(s) of the collision class for the FHE cryptosystem. The end of the procedure can then be achieved by performing steps S50 and S60 presented previously.

Claims

Claims

1. Method for confidential querying by a user (U) of a database (DB) comprising records (Xi) and hosted by a server (S) to obtain information sought relating to one or more records of the database satisfying a criterion, the criterion being a function of a record identification key, the record identification key being a vector of value(s) of one or more fields of a record; a hash function (h) being defined such that, for a given criterion, all the records which satisfy the criterion generate the same hash; a set of records having the same hash being called a collision class (li); the method comprising the following steps for obtaining information sought, a function of a record identification key: S10) the user determines a hash, called the hash of the collision class sought, common to all records satisfying the criterion defined based on the record identification key; S20) the user calculates a query (R) comprising a collision class identification vector (VIC), encrypted, a function of the hash of the collision class sought, as well as a record identification vector (VIE), encrypted, a function of the record identification key, and sends the query (R) to the server; S30) based on the collision class identification vector (VIC), by a private information retrieval method the server determines one or more FHE ciphers of the sought collision class, V, representing the collision class of the hash of the sought collision class; S50) from the record identification vector (RIV), the server determines by homomorphic calculation an encrypted form of the information sought based on the result(s) of an evaluation of the criterion for the encrypted form(s) of the collision class sought, and transmits the encrypted form of the information sought to the user; and S60) the user then decrypts the encrypted form of the information sought and thus obtains the information sought.

2. A query method according to claim 1, wherein the hash function (h) outputs a hash encoded on m bits.

3. The query method of claim 2, wherein the collision class identification vector (VIC) comprises 2 m components (Ri); each component (Ri) of index i among said 2 mcomponents is a cipher of 1 (E(1 )) if the index i is equal to the hash of the collision class sought, or a cipher of 0 (E(0)) otherwise; and in step S30, a cipher V of the collision class sought is determined by the equation: v = £i Vj with V; = Rj * lj

4. A query method according to any one of claims 1 to 3, wherein the records of the database are encrypted by an encryption function of a non-homomorphic cryptosystem, in particular a symmetric cryptosystem.

5. A query method according to any one of claims 1 to 3, wherein the database records are stored in clear or non-FHE encrypted form or in hashes obtained by a second secret key hash function.

6. A query method according to any one of claims 1 to 3, wherein the database records are FHE encrypted.

7. A query method according to any one of claims 1 to 6, wherein the homomorphic calculations performed in step S30 and step S50 are performed using the same cryptosystem, in particular a TFHE cryptosystem.

8. A query method according to any one of claims 1 to 6, wherein the method further comprises a step S40 in which the server recalculates the cipher(s) of the collision class sought by applying a transciphering operation to it or them.

9. A query method according to claims 3, 4 and 8, wherein: in step S30, the server calculates the products Ri * li on a basis of FHE stream keys using a symmetric stream cipher primitive; and the method further comprises a step S40 in which the server recalculates the ciphertext(s) of the sought collision class by applying to it or them a transciphering operation, this transciphering operation being carried out by an exclusive OR operation in a homomorphic manner between the ciphertext(s), V, of the sought collision class and the FHE ciphertext of the corresponding stream key.

10. A query method according to any one of claims 1 to 9, wherein in step S50, the server determines the ciphertext of the information sought using: - a level-homomorphic cryptosystem, in particular a BGV-type cryptosystem; or - a SHE-type cryptosystem, in particular a BFV or CKKS-type cryptosystem.

11. Query method according to claim 10, in the case where in step S50 the server (S) uses a cryptosystem of type BFV, BGV or CKKS, in which during the calculations carried out in step S50 using this cryptosystem, an upper bound on a multiplicative depth of the homomorphic calculations is taken into account.

12. A query method according to any one of claims 1 to 9, wherein in step S50, the server performs the following steps S52 and S54: S52) the server evaluates the criterion for the cipher(s) of the collision class sought by performing the following operations: 5521) the server performs a distance calculation; and 5522) the server compares one or more results obtained in step S521 to a threshold; then S54) the server calculates the ciphertext of the information sought; the homomorphic calculations carried out in step S30 and optionally in step S522 are carried out using the same first cryptosystem, in particular a BFV or BGV cryptosystem; and the homomorphic calculations carried out in steps S524 and S54 are carried out using the same second cryptosystem different from the first cryptosystem, in particular a TFHE cryptosystem.

13. A query method according to any one of claims 1 to 12, wherein the identification of the collision class ciphertext(s) that satisfy the criterion in step S50 is made collision class ciphertext by collision class ciphertext, each collision class ciphertext corresponding to a record.

14. A method of querying according to any one of claims 1 to 13, wherein the recordings are images, or are obtained from images, for example using an encoder (E), in particular a neural network.

15. A query method according to any one of claims 1 to 13, wherein the records are hashes of noisy data structures.

Images