Method for confidentially querying a database

Abstract

A method for confidentially querying a database (DB) by a user (U) to obtain desired information, the method comprising the following steps: S10) the user determines a hash; S20) the user computes a query (R) comprising a ciphertext collision class identifier vector (VIC) based on the hash and a ciphertext record identifier vector (VIE); S30) using a private information retrieval method, the server determines the FHE ciphertext(s) of the desired collision class (V); S50) from the record identifier vector (VIE), the server determines a ciphertext of the desired information by homomorphic computation and transmits it to the user; and S60) the user then decrypts the ciphertext of the desired information. Figure 2 for the abstract

Description

Title of the invention: Method for confidentially querying a database TECHNICAL FIELD OF THE INVENTION

[0001] The field of the invention is that of the confidential interrogation of databases for the purpose of recovering private information. STATE OF THE ART

[0002] 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 in return obtains 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.

[0003] Such operations are performed 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 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.

[0004] To enable the maintenance of such confidentiality conditions in the context of externalized databases in particular, different methods of recovering private information have been developed, these methods using in particular homomorphic encryption methods.

[0005] In the field of cryptography, an encryption function is a function that operates on a set whose elements are called 'plaintexts'. To each plaintext, the encryption function associates one or more images (possibly probabilistically) called 'ciphertext(s)'. Conversely, the function that associates the corresponding plaintext with a ciphertext is called the decryption function. The function of encryption and the associated decryption function together constitute a cryptosystem.

[0006] Among the cryptosystems, homomorphic encryption cryptosystems have notably been used to perform private information recovery functions.

[0007] 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 international patent application WO2020 / 070455 AL

[0008] 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 manner from the ciphertext E(x) of the record.

[0009] Among homomorphic cryptosystems, an additive homomorphic cryptosystem is a cryptosystem comprising at least addition as an elementary homomorphic calculation operation.

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

[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 encryption systems are presented by documents Ref.2, 6 and 7 listed below.

[0012] Document Ref.[l] 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 comprising a vector of ciphertexts, only one of which is the ciphertext of the collision class in which the searched record is located; based on this query, the server determines a ciphertext of this collision class, by implementing an encryption function of an additive homomorphic cryptosystem. This ciphertext is returned to the user, who decrypts it and can then obtain the sought 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 documents present methods in the field of homomorphic encryption. Document [Ref.7] presents in particular different known FHE cryptosystems, in particular the BFV, BGV, CCKS and TFHE cryptosystems. List of cited documents

[0016] [1] EnQuery, LLC, « EncryptedQuery: Scalable Private Information Retrieval », 2018

[0017] [2] M. Zuber, S. Carpov and R. Sirdey, "Towards real-time hidden speaker ré cognition by means of fully homomorphic encryption", Proceedings of the 22nd International Conférence on Information and Communications Security, LNCS 12282, pp. 403-421, 2020.

[0018] [3] Fan, J., Vercauteren, F.: Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, Report 2012 / 144 (2012)

[0019] [4] hen, H., Laine, K., Player, R.: Simple encrypted arithmetic library - seal v2.1 (2017)

[0020] [5] Brakerski, Z., Gentry, C., Vaikuntanathan, V.: Fully homomorphic encryption without bootstrapping. Cryptology ePrint Archive, Report 2011 / 277 (2011)

[0021] [6] Gentry, C.: Fully homomorphic encryption using idéal lattices. In: Proceedings of the Forty-first Annual ACM Symposium on Theory of Computing. STOC '09 (2009)

[0022] [7] Jiang, L., & Ju, L. (2022). Fhebench: Benchmarking fully homomorphic in encryption schemes. arXiv preprint arXiv:2203.00728. Statement of the invention

[0023] 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 for confidentially querying a database hosted by a server making it possible to obtain sought information, 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.

[0024] For this purpose, 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 information sought relating to (or depending on) one or more records of the database satisfying a criterion, the criterion being a function of a key record identification, the record identification key being a vector of value(s) of one or more fields of a record;

[0025] a hash function being defined such that, for a given criterion, all records that satisfy the criterion generate the same hash;

[0026] a set of records having the same hash being called a collision class;

[0027] the method comprising the following steps for obtaining a sought information, depending on a recording identification key:

[0028] S10) the user determines a hash, called hash of the collision class sought, common to all the records satisfying the criterion defined according to the record identification key;

[0029] S20) the user calculates a query comprising an identification vector of collision class, encrypted, function of the hash of the collision class sought, as well as a record identification vector, encrypted, function of the record identification key, and sends the request to the server;

[0030] S30) based on the collision class identification vector, by a method of private information recovery the server determines one or more FHE ciphers of the sought collision class, representing the collision class of the hash of the sought collision class;

[0031] S50) from the record identification vector, the server determines by homomorphic calculation of a cipher of the information sought as a function of 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

[0032] S60) the user then decrypts the ciphertext of the information sought and thus obtains the information sought.

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

[0034] The method defined above mainly comprises, for the server, two calculation steps.

[0035] For the implementation of the method, the hash function is previously chosen so as to ensure that all the records which 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.

[0036] 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.

[0037] This collision class is the collision class that all records belong to. events that satisfy the criterion defined according to the record identification key: these records are those that will make it possible to obtain the information sought. This sought collision class is identified by one or more ciphers, called 'ciphers of the sought collision class'.

[0038] From step S30, advantageously the calculations are executed solely on the basis of the figures of the collision class sought, that is to say normally on a number of records considerably lower than the total number of records in the database.

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

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

[0041] Preferably, step S50 comprises the following steps:

[0042] S52) the server evaluates the criterion for the cipher(s) of the collision class searched by performing the following operations:

[0043] S521) the server performs one or more distance calculations; and

[0044] S522) the server compares one or more results obtained in step S521 to a threshold (this comparison may consist of verifying one or more equation(s) and / or one or more inequality(s)); then

[0045] S54) the server calculates the encrypted value of the information sought.

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

[0047] The second step S50 is preferably carried out entirely by the server. Since the ciphers of the sought collision class are FHE ciphers, the calculations carried out in step S50 are executed by the server on FHE ciphers. No usable information is therefore communicated in clear to the server. Thus, advantageously the user only has to execute a small quantity of calculations in step S60, corresponding to the decryption of the sought information.

[0048] 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 quantity 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.

[0049] In certain cases, the calculations carried out on the server in step S50 do not lead to find information corresponding to the information sought.

[0050] In this case, naturally, 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 value of the information sought, or an encrypted value meaning that no response has been found. For example, conventionally, in the latter case the server can return an encrypted value of -1, the value '-1' conventionally meaning that no valid response has been found.

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

[0052] 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'.

[0053] In other implementation modes, conversely, we seek to identify records that are either close to a certain predetermined record, or therefore one or more fields contain values ​​close to corresponding values ​​of fields of 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 of the database (It therefore corresponds to the image obtained by the function Argmin 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'.

[0054] 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.

[0055] 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.

[0056] For example, in one implementation mode the hash function provides as output a hash coded on m bits.

[0057] 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).

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

[0059] In certain embodiments, when the hashes provided by the hashing function are coded on m bits, the collision class identification vector comprises 2m components; each component of index i among said 2m components 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:

[0060] v = £. v with vs = R,* Ij. (E)

[0061] For this implementation mode to be of real interest, 2m must preferably be significantly smaller than the number K of elements in the database. In addition, for a collision class to be contained in a single row, preferably L is chosen such that 2mL 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 2m (conventionally noted 'O(2m)') 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.

[0062] The record identification vector contains the specific information relating to the information sought which will allow the server to extract an encrypted version of the information sought.

[0063] 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.

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

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

[0066] Naturally, the evaluation of the criterion, then the calculation of the encrypted value of the 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.

[0067] The criterion may 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) which minimize(s) the output value for a certain function, called an 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.

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

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

[0070] 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 by recording the collision class; such a cipher is called 'record cipher'.

[0071] As far as database encryption is concerned, different solutions can be chosen.

[0072] In some implementations, the database records are encrypted by an encryption function of a non-homomorphic cryptosystem, in particular a symmetric cryptosystem.

[0073] In some implementations, the database records are stored in clear text or in the form of non-FHE ciphertexts or in the form of hashes obtained by a second secret key hash function.

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

[0075] 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.

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

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

[0078] 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.

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

[0080] To ensure the conversion from one cryptosystem to another, in certain embodiments 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.

[0081] 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.

[0082] 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.

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

[0084] 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.

[0085] Above, the expression “FHE stream key base” designates a key base in which the stream keys are FHE ciphers.

[0086] In certain embodiments, in step S50 the server determines the encryption of the information sought using:

[0087] - a levelled homomorphic cryptosystem (from English: 'levelled homomorphic en- encryption scheme'), in particular a BGV-type cryptosystem; or

[0088] - a SHE-type cryptosystem (from English: 'somewhat homomorphic encryption scheme'), in particular a cryptosystem of the BFV or CKKS type.

[0089] 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).

[0090] BGV type cryptosystems are presented in particular by Ref.5. These crypto systems 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.

[0091] In certain implementation modes in which in step S50 the server (S) uses a cryptosystem of type BFV, BGV or CKKS, 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.

[0092] 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.

[0093] In certain embodiments, 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.

[0094] The methods according to the present disclosure can be implemented to search for information in databases comprising both exact data 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'.

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

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

[0097] 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 means any record in which at least one of the fields is noisy data relating to a human person or an animal. BRIEF DESCRIPTION OF THE FIGURES

[0098] Other advantages, aims and particular characteristics of the present invention will emerge from the following non-limiting description of at least one embodiment particular of the devices and methods which are the subject of the present invention, with reference to the appended drawings, in which:

[0099] - [Fig.l] is a schematic view of a user and a server which implement implements a query method according to this disclosure; and

[0100] - [Fig.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

[0101] The present 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.

[0102] As non-limiting examples of embodiment, two methods of confidential querying of a database according to the present disclosure will be described below in the context of a client-server architecture illustrated by [Fig.l].

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

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

[0105] The user U includes in particular one or more PG processors, and a memory M g .

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

[0107] 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 or encrypted form. In particular, it can be a cipher obtained by encryption using a symmetric cryptosystem.

[0108] The records in the database can be of any nature (textual data (character strings, CSV, etc.), images, audio or video files, etc.).

[0109] The recordings can be encoded (or encrypted) by an encoder, for example of the neural network type, before storage in the database (see the NN encoder indicated in [Fig.l]).

[0110] The first method according to the present disclosure which will be presented concerns a case of exact data matching.

[0111] Two variants of this method will be presented below.

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

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

[0114] A hash function h is determined beforehand. Any hash function can be used since, when searching for certain information concerning record(s) in the database satisfying a criterion, all the records which satisfy the criterion generate the same hash.

[0115] If the result of the hash function is a word of m bits, m is preferably chosen such that 2m is small compared to the number K of records in the database.

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

[0117] The records in the database are for example stored in the form of a table (a table T), in which each row corresponds to one of the possible hash values. This table therefore has 2m rows, some rows possibly being empty, the others comprising one or more X records.

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

[0119] In table T, each collision class is recorded on one line.

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

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

[0122] In the first variant of the method presented here, the information sought is simply the fact that a Sought 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 sought individual.

[0123] The method is implemented as follows.

[0124] 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).

[0125] 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 106 collision classes.

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

[0127] In step S30, the numbers of the collision class sought are determined.

[0128] These are recording ciphers.

[0129] For 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 assume 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.

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

[0131] Then in step S50, for each of the figures obtained in step S30, we evaluate by homomorphic calculation if the applicable criterion is satisfied.

[0132] The applicable criterion, in this case, defined according to 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.

[0133] The result of the evaluation of the criterion for a given record is therefore a cipher of 1, E(l), 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.l]).

[0134] 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.

[0135] 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 matching).

[0136] The information sought is the cipher obtained by adding the ciphers (E(0) or E(l)) 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(l) if the individual sought is recorded in the database, and a figure of 0 E(0) otherwise.

[0137] 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.

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

[0139] 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 ​​'Address_IC' and 'Telephone number_IC' of the database record whose field 'Social Security Number' corresponds to the individual sought IC.

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

[0141] It is assumed here that the result of the hash function h is a word of m bits.

[0142] In a first step S10, the user first calculates the request R to be sent to the server.

[0143] 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.

[0144] The first vector VIC, which comprises 2m components Ri of index i, where i varies from 0 to 2m-l, is calculated from the hash of the collision class sought in the following manner: for each value of i different from the hash of the collision class sought, the component Ri of 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(l)).

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

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

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

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

[0149] 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.

[0150] 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.

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

[0152] 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).

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

[0154] In the example presented here, upon receipt of the request R, in 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:

[0155] In a first step S32, having received the request R from the user, for each possible hash value (each index value i, i varying from 0 to 2m-l), 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.

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

[0157] V - £.¾

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

[0159] 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.

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

[0161] In certain embodiments, 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:

[0162] S40) the server applies a transcryption operation to the encrypted(s) of the collision class, so as to obtain one or more ciphers which are encrypted with the cryptosystem provided for step S50.

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

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

[0165] During this step, the server evaluates the criterion for each of the ciphers of the collision class sought. 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 sought. If this difference is a cipher of '1', this means that the criterion is satisfied, that is to say that the considered record of the collision class is indeed a record having the same social security number as that of the individual sought.

[0166] In step S54, the server therefore calculates the encrypted value of the information sought and transmits it to the user. This encrypted value is obtained by simply adding the encrypted values ​​obtained for all the encrypted values ​​of the collision class.

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

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

[0169] 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 clear text space are replaced by so-called 'homomorphic' operations carried out in the cipher text space.

[0170] 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.

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

[0172] In this case, to avoid transmitting information about the information sought, preferably an upper limit of the number of records which will be considered as satisfying the criterion is fixed in advance: for example, a number N is chosen as this upper limit.

[0173] 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.

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

[0175] 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.

[0176] In addition, the collision class sought is not disclosed to the server (only the collision class ciphers are known to the server).

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

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

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

[0180] The result of such a search can be provided by an evaluation function of argmin / argmax type, 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.

[0181] 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.

[0182] According to the present disclosure, it is preferable on the contrary 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 space of the ciphers, using a first FHE cryptosystem.

[0183] In one embodiment, 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.

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

[0185] 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 the present disclosure. The user U obviously has the biometric profile of the person sought.

[0186] To calculate the query R, ​​the hash function is previously chosen from among the hash functions applicable to noisy data. A hash function is chosen which gives the same hash for biometric profiles which only differ from each other by a value lower than the predetermined proximity threshold.

[0187] 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 coded on 128 values. Thus, the hash function makes it possible to classify the records into 128 collision classes corresponding to 128 encodings of the different possible eye colors.

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

[0189] 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.

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

[0191] In step S50, in the space of the ciphers, 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.

[0192] 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.

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

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

[0195] In step S60, the user decrypts each cipher of the list of ciphers of detected person records and thus obtains the set of person records sought.

[0196] Different encryption possibilities for the database

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

[0198] In a first case, the records of the database 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.

[0199] Thus, for example, the database may be a secondary database, consisting of the hashes of initial records which are stored in clear text in a primary database, these hashes being obtained using an initial hash function with a secret key.

[0200] It is then sufficient to consult the secondary database containing the hashes initial records for example when we only want to assess the presence of one or more specific records in the database.

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

[0202] 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, an FHE encrypted text of the collision class is therefore recovered.

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

[0204] In this second case, in step S32 the homomorphic multiplications carried out are multiplications between a cipher and a cipher, 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 cipher of the collision class on which it will be able to continue the processing in step S50.

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

[0206] In this case, in step S32 the homomorphic multiplications carried out 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.

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

[0208] 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 cleartext 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.

[0209] To reduce this calculation time, in certain implementation modes a flow of encryption keys (or 'keystreams') used for the encryption is calculated in advance. FHE system used.

[0210] 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.

[0211] 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.

[0212] 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 of confidential query 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 records that 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 to obtain the information sought, depending on 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 version of the information sought based on the result(s) of an evaluation of the criterion for the encrypted version(s) of the collision class sought, and transmits the encrypted version 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.

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

3. The query method according to claim 2, wherein the collision class identification vector (VIC) comprises 2m components (Ri); each component (Ri) of index i among said 2m components is a cipher of 1 (E(l)) if the index i is equal to the hash of the searched collision class, or a cipher of 0 (E(0)) otherwise; and in step S30, a cipher V of the searched collision class is determined by the equation: v = ^.Vjwith vi = Ri* h

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 FHE stream key basis using a symmetric stream cipher primitive; and 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, this transcryption operation being carried out by an exclusive OR operation in a homomorphic manner between the cipher(s) of the sought collision class (V) and the FHE cipher of the corresponding stream key.

10. Query method according to any one of claims 1 to 9, wherein in step S50, the server determines the cipher 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. 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: S521) the server performs a distance calculation; and S522) the server compares one or more results obtained in step S521 with a threshold; then S54) the server calculates the cipher of the information sought; the homomorphic calculations performed in step S30 and optionally in step S522 are performed using the same first cryptosystem, in particular a BFV or BGV cryptosystem; and the homomorphic calculations performed in steps S524 and S54 are performed 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 records are images, or are obtained from from images, for example using an encoder (E), notably 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