Method for confidentially querying databases
The method addresses resource-intensive and confidentiality issues in database querying by using distinct cryptosystems for filtering and identification, enabling efficient and secure query processing of sensitive data.
Patent Information
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- EXPLEO FRANCE
- Filing Date
- 2024-06-28
- Publication Date
- 2026-06-05
AI Technical Summary
Existing database query methods for sensitive data are resource-intensive or lack flexibility, preventing commercial-scale exploitation and insufficiently protect data confidentiality from unauthorized access.
A method for confidential querying using encrypted filtering and identification data, employing different cryptosystems for filtering and identification, allowing reduced database extraction and secure query processing.
Enables flexible and efficient querying of large databases with high confidentiality, ensuring data protection from unauthorized access and reducing computational overhead.
Abstract
Description
Title of the invention: Method for confidentially querying databases TECHNICAL FIELD OF THE INVENTION
[0001] The invention relates to methods of confidential querying of databases. STATE OF THE ART
[0002] In the field of computer science, databases have undergone considerable development, thanks to the ease of access they provide to large amounts of information.
[0003] In this context, specific database storage and query methods have been developed for situations in which the recorded data is so sensitive that it is not desired for the server to have knowledge of it, and where it is also desired to be able to search these data and extract the data identified by these searches.
[0004] Storing encrypted data using fully homomorphic encryption (or 'FHE', from the English 'Fully Homomorphic Encryption') and querying data encrypted with FHE are known. However, FHE encryption is resource-intensive and prevents the commercial-scale exploitation of this solution.
[0005] Another solution enabling search on encrypted data is searchable public key encryption or PEKS; but this technique has insufficient possibilities for processing encrypted data.
[0006] There is therefore a need for database query solutions that are flexible, usable on databases of a certain size at a moderate cost and computation time, while ensuring the highest degree of confidentiality for the data stored in the database. In particular, it is desirable that these solutions keep the information stored in the database confidential from the database operator and, more generally, from any third party other than the stakeholders who have direct access to the information recorded in the database and concerning them. References
[0007] Reference 1: Aloufi, A. a. (2021). Computing blindfolded on data homomorphically encrypted under multiple keys: An extended survey. ACM Computing Surveys (CSUR), 1-37. Description of the invention
[0008] The present invention aims to provide a method of confidential interrogation that avoids the risks suggested above.
[0009] To this end, a method of confidential querying by at least one client of a database, hosted by a server, is proposed;
[0010] the database comprising:
[0011] - filtering data, each filtering data field having at least one field of encrypted filtering under a filtering cipher, which is a cryptosystem enabling searchable encryption; and
[0012] - identification data, each identification data having at least an encrypted identification field under an identification encryption, the identification encryption allowing calculation on encrypted data;
[0013] the database being structured in such a way as to allow, from a filtering data, the identification of zero, one or a plurality of identification data associated with the filtering data;
[0014] the process comprising the following steps:
[0015] S10) a client defines a query including a search index and a condition;
[0016] the index sought being a vector defining a value for at least one field of desired filtering;
[0017] the condition being a condition to be satisfied by one or more identification data and a function of the value of at least one identification field;
[0018] the client calculates or has calculated a trapdoor for the index sought, encrypted under said filtering cipher, and transmits or has transmitted to the server (SP) said encrypted trapdoor and said encrypted condition under the identification cipher;
[0019] S20) by applying the extraction backdoor to the database, the server extracts from the database a reduced filtering database, comprising the filtering data whose searched filtering field(s) have values equal to those of the corresponding fields of the searched index;
[0020] S30) the server extracts an identification database from the database reduced, including any identification data associated with at least one data point in the reduced filtering database;
[0021] S40) by implementing a confidential query method, the server identifies within the reduced identification database any identification data satisfying said condition;
[0022] S50) the server determines and sends to the client an encrypted result obtained from the or identified identification data; and
[0023] S60) the client decrypts the encrypted result and obtains the result in plain text.
[0024] The crypto-identification system is preferably chosen so as to be different from the crypto-filtering system. It is chosen in principle so as to generate a lower volume of calculations than that generated by the crypto-identification system.
[0025] The identification cipher can in particular be a completely homomorphic cipher.
[0026] The filtering cipher may in particular be a searchable cipher (SE) with a public key, in particular a PEKS type cipher, or a symmetric cipher.
[0027] The crypto-encryption system enabling computation on encrypted data is preferably different from the searchable crypto-encryption system. In particular, the crypto-encryption system enabling computation on encrypted data is an encryption method that requires, comparatively, less computation time.
[0028] The expression 'confidential query method' here refers to any calculation method on encrypted data allowing, within an identification database, the identification of specific data, called identification data, satisfying a given condition.
[0029] Thanks to the process defined above, thanks to the prior extraction carried out in steps S20 and S30, advantageously the confidential querying step S40 can be carried out on an extracted database whose size is reduced, sometimes considerably reduced, compared to the size of the complete database.
[0030] In certain embodiments of the process, step S10 comprises:
[0031] S12) by applying a transfer cipher, for example by masking, the client calculates a ciphertext of the index sought;
[0032] S14) the customer sends to at least one backdoor service provider, the ciphertext of the index sought;
[0033] S16) from the ciphertext of the sought index, using a secret key, said at least one backdoor service provider(s) calculates an encrypted backdoor under the filtering ciphertext of the sought index ciphertext, called the primary backdoor, and sends the primary backdoor to the client;
[0034] S18) by removing the transfer encryption of the primary backdoor, the client calculates the extraction backdoor and transmits it to the server.
[0035] It is understood that in these implementation modes, the crypto-transfer system includes a decryption operation (Unmask_[3]) associated with the transfer cipher (|3) and which allows the plaintext backdoor (T(m)) to be calculated from the primary backdoor T([m][3), also denoted T(m[3], by the operation:
[0036] Unmaskjlr(mP)) - T(m)-
[0037] In some of these latter embodiments of the method, at step S14, the ciphertext of the sought index is sent to a set of backdoor service providers; the secret key held by each is a partial filtering secret key of the backdoor service provider; and at step S16, from the ciphertext of the sought index, each service provider among a plurality of said backdoor service providers calculates a partial primary backdoor using its partial secret key and returns this (the calculated partial primary backdoor) to the server; from said partial primary backdoors, the server calculates the primary backdoor.
[0038] Preferably, the transfer cipher is a threshold transfer cipher, and at step S16, the server calculates the primary backdoor (T([m][3)) from said partial primary backdoors only if a threshold required by the threshold transfer cipher is reached.
[0039] Furthermore, in certain implementation modes, step S50 includes the following operations:
[0040] S52) the server obtains the encrypted result under double encryption, namely under the identification encryption and an additional encryption, called client encryption, which the client is able to decrypt;
[0041] S54) the server transmits the result under double encryption to at least one decryption service provider;
[0042] S56) said at least one decryption service provider removes the encryption identification of the result under double encryption, thus obtaining the said encrypted result, which it transmits to the client.
[0043] In these implementations, client encryption is applied as an encryption layer on top of the ciphertext under identity encryption (typically, FHE encryption). The client encryption is chosen such that the removal of identity encryption by the service providers at step S56 preserves client encryption.
[0044] Different variants can be chosen to obtain the encrypted result under double encryption.
[0045] According to a first variant, to obtain the result encrypted under double encryption, at step S52 the server determines the result under identification encryption, then applies to this result the client encryption, so as to obtain the result encrypted under double encryption.
[0046] According to a second variant, to obtain the encrypted result under double encryption: at step S10, the client transmits or causes to be transmitted to the server the encrypted condition under double encryption, namely under the identification cipher and under the client cipher; following step S30, the server encrypts the reduced identification database under client encryption; and at step S50, the server determines the encrypted result under double encryption.
[0047] In some of the implementation modes in which the result is encrypted under double encryption, at step S54, the result under double encryption is sent to a set of decryption service providers; the secret key held by each of the service providers is a partial filtering secret key of the decryption service provider; and at step S56, each service provider among a plurality of said decryption service providers performs a partial decryption of the result under double encryption by removing the identification cipher from it using its partial secret key and thus obtains a partially decrypted result which it sends back to the server; from said partially decrypted results, the server calculates the encrypted result.
[0048] In these latter embodiments, preferably the identification encryption is a threshold identification encryption; and at step S50, the server calculates the encrypted result from the partially decrypted results only if a threshold required for the threshold identification encryption is reached.
[0049] Several possibilities can be considered for client encryption.
[0050] In some of these latter modes of implementation, in the case where the identification encryption is a homomorphic encryption, the client encryption is a symmetric encryption.
[0051] Step S52 can then include the application of this symmetric encryption (which is for example an AES encryption, a masking encryption, etc.) to the encrypted result.
[0052] In these implementation modes, after decryption by the service providers, the result remains encrypted under symmetric client encryption, and the server returns this encrypted result to the client.
[0053] Conversely, in other implementations, where the identification cipher is a homomorphic cipher, step S52 includes an extension of the homomorphic ciphertext using (for example, by adding to the ciphertext) an asymmetric public key. An asymmetric public key naturally refers to a public key associated with a secret key within the framework of an asymmetric client cryptosystem.
[0054] Step S52 thus allows the calculation of a ciphertext, encrypted with two distinct public keys. Such an extension of an FHE ciphertext can be done, for example, with a form of concatenation, as described in [Ref.1].
[0055] The client encryption must naturally be decrypted to access the result in plain text.
[0056] In these implementation modes, preferably the server holds said asymmetric public key, and the client holds a corresponding asymmetric secret key; at step S56, client encryption is applied using said asymmetric public key; and at step S60, client encryption is removed using said asymmetric secret key. BRIEF DESCRIPTION OF THE FIGURES
[0057] Other advantages, purposes and particular features of the present invention will become apparent from the following non-limiting description of at least one particular embodiment of the devices and methods of the present invention, with reference to the accompanying drawings, in which: • [Fig. 1] is a schematic perspective view illustrating a freight transportation management system configured to allow the implementation of a process according to this disclosure; • [Fig.2] is a schematic view illustrating a first method of implementing a process according to this disclosure; • Figure 3 is a schematic view illustrating a first variant of a second implementation of a process according to this disclosure; and • [Fig. 4] is a schematic view illustrating a second variant of the second implementation method of a process according to this disclosure. DETAILED DESCRIPTION OF THE INVENTION
[0058] By way of non-limiting example of implementation, two modes of implementation of the confidential interrogation process according to this disclosure will now be presented.
[0059] As illustrated in [Fig. 1], this example considers a situation in which a fleet of trucks C1, C2, C3, ... transports goods between different cities. More precisely, each truck must successively complete different journeys. On each journey, it transports goods from a city of departure to a city of destination.
[0060] Trucks Cl, C2, C3,... transport goods belonging to a number of companies, referred to as 'customers' for the purposes of this disclosure, represented by two customers CL1, CL2 on [Fig.1].
[0061] The management of goods transport carried out by the fleet of trucks is done using a goods management system 100 shown in [Fig. 1]. This system 100 constitutes an example of a confidential query system within the meaning of this disclosure.
[0062] The management of goods transport operations is ensured by a service provider, which interacts with the various actors involved in these operations: the trucks (Cl, C2, C3,...), the customers (CL1, CL2,...), and a set of trusted third parties, called supervisors, noted SV1, SV2, SV3, ... which are integrated into the system to ensure the confidentiality of the processing carried out on the data processed.
[0063] The service provider implements a server S, which includes a database DB in which data relating to the journeys made by the fleet of trucks are stored.
[0064] Each participant, whether a truck, a client, the server, or one of the supervisors, uses a computer with the general architecture of a computer. This architecture is described below in the case of client CL1, but each participant has a computer with a similar architecture.
[0065] The CL1 customer's computer 10 has the hardware architecture of a computer, as schematically illustrated in [Fig. 1]. Generally, any computer comprising at least one memory capable of storing data and the program that will be presented later, and one or more processors capable of executing this program, can be used.
[0066] In this embodiment, the computer 10 includes in particular a processor 12, a non-volatile memory 14, as well as means of communication 16 with other components of the data management system 100, including at least the computer of the server S.
[0067] The non-volatile memory 14 of the computer 10 constitutes a recording medium in accordance with this disclosure, readable by the processor 12 and on which is recorded a computer program in accordance with this disclosure, comprising instructions for the execution of the steps of the confidential query process according to this disclosure which are to be executed by the client CL1.
[0068] To enable the proper execution of the various goods transport operations ordered by customers with the various trucks, the service provider is required to manage data within the database DB.
[0069] These data include in particular data di, i=l.....N, called 'route data', such that each data di contains information relating to a route taken by a truck. Each route data di has five fields: 'truck', 'date', 'departure_city', 'stop-city', 'destination_city'.
[0070] The data also include, for a given route taken by a given truck Ci, a time data comprising two fields: 'departure_time' and 'arrival_time'.
[0071] The data also include, for a given route, another DA data including a 'distance' field.
[0072] Importantly, companies (clients) that use the service provider to assist them in their freight transport operations want their data, i.e. information relating to their operations, to be known neither to other clients nor even to the service provider.
[0073] More specifically, the freight transport operations management system must allow each customer to make queries, i.e., search for information within its data, without either its queries or the results of these queries being accessible to the service provider or other customers.
[0074] To enable this operation, the following measures are taken.
[0075] The data to be recorded in the database is determined in advance. Furthermore, within this data, it is determined which fields will be filter fields and which fields will be identification fields.
[0076] The filtering data are generally keywords and key variables whose value can be specified in order to extract a part of the database and thus be able to perform confidential query operations on a small database.
[0077] In this case, it is determined that the information searches are based on the fields 'truck', 'date', 'departure_city', 'stage_city', 'destination_city': These fields are therefore gathered in DF filtering data, which are therefore in this case the route data.
[0078] In some embodiments, rather than storing the filtering data only under searchable encryption in the database, this data is first 'hashed' (i.e. a hash function is applied to it); and it is the hash of this data that is stored under the filtering encryption in the database.
[0079] It is further determined that the information sought relates to the fields departure_time and arrival_time: These fields are therefore gathered in DI identification data, which in this case are therefore the time-data.
[0080] The database is therefore structured to include:
[0081] - a filtering database containing the DF filtering data, which in This example is route data, including for example a data point { date: 20240419; departure_city: Paris; stop_city: Lyon; destination_city: Marseille}
[0082] - an identification database containing DI identification data, which in this example are the time data, including for example a data { departure_time: 6:00 a.m.; arrival_time: 22:20 p.m.; truck: CL2}
[0083] - another database, containing the other DA data, as in this example a data type { distance: 800 km}.
[0084] The database is further structured in such a way that from each DF filtering data (each route data), the server is able to identify the corresponding DI identification data (the time data).
[0085] Consider the case, for example, where customer CL1 seeks to obtain confidential information relating to the departure time or arrival time of trucks, from the database DB.
[0086] The information sought is identification data, which will be extracted and returned to the customer if it meets a certain condition relating to the identification data (namely, the departure and arrival times of the different trucks), and also provided that it specifically concerns certain trucks, previously selected by filtering in the database according to the filtering data (the route data).
[0087] The database query method comprises two main steps: a filtering step (operations S20-S30) and an identification step (operations S40-S50).
[0088] During the filtering step, the filtering data is used to filter the database data, that is, to extract a subset of filtering data from the database. From this filtering data, the identification data associated with this filtering data will then be extracted, or at least identified as the database data from which the information sought in the database can be extracted.
[0089] The identification step can then take place from the reduced database thus constituted.
[0090] To enable the implementation of the method, a crypto-filtering system SE and a crypto-identification system FHE are chosen in advance.
[0091] Any cryptosystem that allows the implementation of a searchable encryption method (called 'SE', from the English 'Searchable Encryption') can be adopted as a filtering cryptosystem. In the example presented here, a public-key cryptosystem with keyword search (called 'PEKS', from the English 'Public Key Encryption with Keyword Search') is chosen. The PEKS cryptosystem can use elliptic curve cryptography (ECC) or Euclidean lattice cryptography.
[0092] It is also possible to use a crypto-system allowing to perform a symmetric searchable encryption, or 'SSE', from the English Symmetric Search Encryption.
[0093] Furthermore, any cryptosystem that allows calculations on encrypted data can be adopted as an identification cryptosystem. In the example presented here, a A fully homomorphic asymmetric cryptosystem FHE (from the English "Fully Homomorphic Encryptiori") is chosen.
[0094] Once the characteristics of the database are fixed, it is progressively built up.
[0095] Thus, before, during and at the end of each journey, each truck transmits the information necessary to constitute the database DB: For each journey to be made or made by a truck, the latter transmits all information to the database in order to constitute and keep up to date the route data, the time data, and the other data describing the journey to be made or made by the truck.
[0096] When each piece of information is sent to the database, it is encrypted. More specifically, all filtering data is encrypted using the pkSE public key of the filtering cryptosystem, SE; and all identification data and all other data is encrypted using the PKFHe public key of the identification cryptosystem, FHE.
[0097] The database is thus constituted and regularly kept up to date by the trucks and contains all the information relating to their journeys.
[0098] A client can then perform a query in the database in the following manner.
[0099] Such a query aims to extract certain information from the database. The information sought is information determined from relevant data identified within the database. The information sought may be simply all or part (certain fields) of this relevant data, or it may be values determined (by calculation) from this relevant data.
[0100] These relevant data mentioned here are the database data for which the value of at least one filter field is equal to certain predetermined value(s), and furthermore a certain condition is satisfied, a condition which depends on the value of at least one identification field (for example, the identification field has a value which belongs to a certain range of values.
[0101] The relevant data necessarily include values obtained from the identification data, and in some cases also include values obtained from the filtering data to which this identification data is associated.
[0102] Consider for example the case where a query defines the values of two filtering fields, for example: city_departure = Paris and city_arrival = Marseille, and where we want to know the departure times of trucks which verify: departure_time > 07:00.
[0103] The query includes a sought index m and a condition c.
[0104] The search index m is a vector defining a value for at least one searched filter field. In this case, it is the two-component vector
[0105] m = { city_departure : Paris ; city_arrival : Marseille} (defining two values that the indicated filtering fields should take).
[0106] Condition c is a condition to be satisfied by one or more identification data, and which is a function of the value of at least one identification field. In this case, it is the single-component vector c = { departure_time > 07:00.}: This is a condition that the identification field 'departure_time' must satisfy.
[0107] The query may also specify how the result to be returned to the client is determined from the data identified as relevant. This result returned to the client may, in general, be a result calculated from the data identified at the end of the query method, by any appropriate function (for example, in some cases the result may be a boolean value (YES / NO) indicating only the presence or absence of data having the desired values). First implementation method: without supervisors
[0108] A first method of implementing the methods according to this disclosure is shown in [Fig.2].
[0109] In this implementation, the freight transport operations management system does not use supervisors. It only involves trucks, customers, and the service provider, which implements an S server. The S server manages truck route data within the DB database.
[0110] It is assumed here that one of the clients issues both the public / private key pairs (pkSE; skSE) of the SE cryptosystem and (PKEHE; SKEHE) of the FHE cryptosystem. It transmits the public keys to the trucks. It transmits only the public and private keys to the other clients.
[0111] On [Fig.2], the operations carried out by the different actors are schematically represented in four columns; these columns therefore contain the operations carried out respectively by the trucks (C), by the customers (CL), by the service provider (i.e. by the server S), by or within the database (DB).
[0112] The method includes performing the following operations.
[0113] At step S10, a CL client defines its request, for example the (m,c) request presented previously.
[0114] The client calculates an extraction backdoor Trapdoor(m) = T(m) using the private key skSE, and transmits this extraction backdoor T(m) to the server S.
[0115] It further encrypts condition c, but this time using the PKEHE public key of the identification cipher, and transmits the encrypted condition [c]EHE to the server S.
[0116] At step S20, using the extraction backdoor T(m), the server S extracts a reduced filtering database RDBF from the filtering database. This The reduced filtering database includes all filtering data where the searched filter fields, `city_departure` and `city_arrival`, have values equal to those of the corresponding fields in the search index `m`. It therefore extracts only the filtering data relating to routes from Paris to Marseille. Advantageously, this data is significantly smaller than the full database. This extraction is performed using any suitable searchable public-key encryption method based on the SE cryptosystem.
[0117] At step S30, the server S extracts from the identification database a reduced identification database RDBI, comprising all the identification data that are associated with at least one data item from the reduced filtering database.
[0118] The two databases RDBF and RDBI together constitute a reduced database RDB.
[0119] At step S40, by implementing a confidential FHEevai query method, the server then identifies within the reduced identification database RDBI all the DI identification data that satisfy condition c, based on the value of at least one identification field: these are the identification data that satisfy condition c: "departure_time > 07:00". This data is an example of so-called 'relevant' data, mentioned previously.
[0120] This identification data is encrypted using the identification encryption (FHE).
[0121] At step S50, based on the relevant identified data, the server then determines the encrypted result [res]. This determination may include, in particular, the extraction, from the identified data as indicated above, of the data and / or field(s) to be returned to the client. The result may depend on the filtering data associated with the identified identification data.
[0122] The result [res] can also be determined by calculation from the relevant data, in particular from the identification data satisfying condition c, identified as indicated above. This calculation can be performed by any appropriate function.
[0123] The calculation is carried out in such a way as to obtain an encrypted result. In this result, most often at least a part of the result (which depends on the identification data) is encrypted using identification encryption.
[0124] Once the encrypted result [res] is obtained, the server then sends it back to the CL client.
[0125] In certain embodiments, the numerical result includes the data identified identification data, and for each the filtering data that allowed it to be identified.
[0126] The result can therefore in this case be obtained in an encrypted form that includes two types of encryption, SE and FHE. The result can, for example, be written as a set of mixed data, each mixed data element associating a data element identification data under encryption and filtering data under encryption, i.e.:
[0127] [res]SE+FHE = (([DF]se,i; [DI]FHe,i); ([DF]se,2; [DI]fhe,2); ([DF]se,3; [DI]fhe,3) • • •• ([DF]SE,N; [DI]ehE,n))
[0128] assuming that N identification data satisfying the criterion have been identified.
[0129] At step S60, the client CL1 decrypts the encrypted result [res], using the private keys of the SE and FHE cryptosystems respectively for the parts of the result under filtering encryption and under identification encryption, and obtains the plaintext result res. Second implementation method: with supervisors
[0130] A second method of implementing the methods according to this disclosure will now be presented, following two variants illustrated respectively by [Fig.3] (1st variant) and [Fig.4] (2nd variant).
[0131] In this implementation, in addition to the actors mentioned for the first implementation, the freight transport operations management system uses supervisors, notably to prevent the communication of FHE private keys to all customers. These supervisors are divided into two groups: backdoor service supervisors and decryption service supervisors (these two groups may or may not have the same members). Depending on the implementation, each group may contain a single supervisor or multiple supervisors.
[0132] In the example presented here, a plurality of supervisors is used, in particular to enable the use of threshold encryption. This encryption protocol advantageously prevents a single supervisor from being able to calculate the backdoor used in step S20 on its own, and / or from being able to remove the authentication encryption applied by the server on its own.
[0133] Moreover, this protocol is robust insofar as it is not necessary for all supervisors to be present for the task to be carried out (calculation of the backdoor or decryption of the result).
[0134] To enable the implementation of threshold encryption, before implementing the confidential query method, the supervisors generate the keys necessary for implementing the process. Preferably, each supervisor generates its own partial secret key(s) and partial public key(s). The partial public keys are then transmitted to the server.
[0135] The global public keys pkSE for the SE cryptosystem and PKFHe for the FHE cryptosystem are then generated by the server from the respective partial public keys of these two cryptosystems.
[0136] In the implementation mode presented here, for the implementation of the process, each of the supervisors therefore has the following two pairs of keys: • global public key and partial private key (pkSE; ski>SE) of the SE cryptosystem; and • global public key and partial private key (PKEHE; SKijEHE) of the FHE cryptosystem.
[0137] In this example, threshold encryption is used for each of the two cryptosystems SE and FHE.
[0138] The server transmits the global public keys pkSE and PKEHE to clients, as well as to data providers (the trucks). First variant
[0139] In a first variant of the second implementation mode, illustrated by [Fig. 3], the operations performed by the different actors are schematically represented in five columns. These five columns describe the operations performed respectively by the trucks (C), by the customers (CL), by the service provider (server S), by or within the database (DB), and by the supervisors (SP).
[0140] For simplicity, in the present example illustrated by [Fig.3], the backdoor service supervisors and the decryption service supervisors are the same entities, called 'supervisors' and denoted SP.
[0141] Unless otherwise specified, the steps carried out in this implementation mode are identical to those carried out in the first implementation mode.
[0142] In this implementation mode, the presence of supervisors ensures a higher level of confidentiality.
[0143] It is assumed that the CL client wishes to submit the same request (m,c) as in the first implementation mode.
[0144] At step S10, the CL client defines the request (m,c).
[0145] At step S12, by applying a transfer cipher (|3), for example by For masking, the client calculates a ciphertext ([m][3]) of the index sought (m). It also calculates a ciphertext of condition c, under identification ciphertext, using the EncEHE encryption function.
[0146] Call to supervisors for backdoor calculation
[0147] The customer then has the extraction backdoor T(m) for the desired index m calculated by the supervisors in the following manner:
[0148] At step S14, the client sends to each of the SP backdoor service providers the cipher [m][3 of the index sought (m).
[0149] At step S16, from this ciphertext [m][3], using its partial secret key skijSE, each of the backdoor service providers SP calculates a partial primary backdoor Ti([m][3) of the ciphertext under the filtering cipher of the sought index (m), and sends this partial primary backdoor Ti([m][3) to the server.
[0150] The server then evaluates whether, taking into consideration all the received partial primary backdoors, the threshold required by the threshold transfer encryption is reached.
[0151] For example, in some implementation modes, the primary backdoor can be calculated as soon as M out of N supervisors are present in the supervisor group.
[0152] If this threshold is reached, from the received partial primary backdoors Ti([m][3), the server then calculates the primary backdoor (T([m][3)).
[0153] To do this, the server combines all the partial backdoors received (for example, it multiplies or adds them, in the case where the CS is on an elliptic curve) and thus obtains the primary backdoor (T([m][3)).
[0154] The server then sends this to the CL client.
[0155] Then at step S18, the client removes the transfer cipher (removes the mask) from the primary backdoor (T([m][3)) and thus obtains the extraction backdoor T(m).
[0156] The client then sends the server the extraction backdoor T(m) and the encrypted condition [c]FHe-
[0157] The following steps S20 and S30 are carried out as in the first implementation mode:
[0158] At step S20, by applying the extraction backdoor T(m) to the database DB, the SP server extracts the reduced filtering database RDBF from the database; this extraction is done under SE public-key searchable encryption.
[0159] At step S30, the SP server extracts from the database a reduced identification database RDBI, comprising any identification data associated with at least one data from the reduced filtering database.
[0160] Then at step S40, by implementing a confidential query method, the server identifies within the reduced identification database RDBI any identification data satisfying said condition c.
[0161] Call to decryption supervisors to send the result to the client
[0162] Then at step S50, from the identification data satisfying condition c, the server determines a first result, called 'primary result', which is obtained under identification encryption from the identified identification data (by a calculation function 'Cale').
[0163] Note: In the example presented here, the result to be transmitted to the client does not include any information encrypted under filtering encryption: it only includes encrypted values. under the identification cipher. For this reason the primary encrypted result is noted [res]FHE In other implementation modes, the result may include filtering data associated with identification data and thus be encrypted respectively under filtering cipher and under identification cipher for the filtering data and for the identification data.
[0164] In the implementation presented here, it is not desired to disclose the secret key of the identification encryption to all clients.
[0165] For this, the primary result under identification encryption [res]FHF will be extended with an additional encryption called client encryption; the identification encryption will then be removed from the result under double encryption; the result obtained [res]CL, encrypted under the client encryption only, will then be returned to the client who can then decrypt it.
[0166] The operations indicated above are carried out by using supervisors, as providers of (partial) decryption services.
[0167] Thus, at step S50, the following operations are performed:
[0168] At step S52, the server applies a client-side encryption (CL) to the primary result [res]FHF, which only the client is able to decrypt, and obtains the result under double encryption [res]FHFCL*
[0169] It should be noted that it may be necessary to use a first client cryptosystem for the result values which are under filtering encryption (called 'filtering data'), and a second client cryptosystem for the result values which are under identification encryption (called 'identification data').
[0170] Two client crypto-systems are then used, one to encrypt the filtering data (encrypted in SE), the other to encrypt the identification data (encrypted in FHE).
[0171] In the case where the client receives within the result, one or more filtering data, the crypto-system of the CL encryption must check the following property, for the filtering data: Decs F(EncCL(Enc(m)SF)) = Enc(m)CL, where EncSF, DecSF, are the encryption and decryption functions of the FHE identification crypto-system and EncCL is the encryption function of the client crypto-system.
[0172] In order for super-encryption operations to be followed by partial decryption, the crypto-system of the CL encryption must verify the following property, for the identification data: DecFHF(EnccL(Enc(m)FHF)) = Enc(m)CL, where EncFHF, DecFHF, are the encryption and decryption functions of the FHE identification crypto-system and EncCL is the encryption function of the client crypto-system.
[0173] At step S54, the server transmits the primary result [res]SE+ fhe, cl under double encryption to the SP supervisors (as trans-encryption service providers).
[0174] At step S56, each of the supervisors partially removes the SE filtering and FHE identification ciphers respectively from the filtering and identification data included in the primary result [res]FHE,cL, and thus obtains a partially decrypted result ([res]i>CL), encrypted under client cipher, and partially decrypted with respect to the SE filtering and FHE identification ciphers respectively from the filtering and identification data included in the primary result [res]FHE,cL.
[0175] This encrypted result is then transmitted to the server.
[0176] The server receives the various partially decrypted results ([res]i>CL), each under client encryption.
[0177] The server checks if the threshold required for threshold-based identification encryption has been reached.
[0178] If this threshold is reached, the server combines these results and thus obtains the result under client encryption [res]CL-
[0179] The server then returns this result [res]CL to the client.
[0180] At step S60, the client decrypts the result by removing the client encryption from the received result [res]CL-
[0181] Second variant of the second embodiment
[0182] In the second variant of the second implementation, the steps involving searchable encryption are identical to the corresponding steps in the first variant. Only the steps involving identification encryption differ.
[0183] At step S18, as in the first variant, the client removes the transfer cipher (removes the mask) from the primary backdoor (T([m][3)) and thus obtains the extraction backdoor T(m).
[0184] But in the second variant, at step S18 the client of more than d the encryption applied to the condition to be satisfied, c, already encrypted under FHE encryption, [c]FHF using its public key for client encryption, PKCL, and thus obtains the condition [c]FHFCl-under double encryption: FHE identification encryption, and CL client encryption.
[0185] This data [c]FHe,cl is sent to the server instead of [c]FHF-
[0186] At step S20, the extraction of the reduced filtering database RDBF takes place in the same way as for the first variant.
[0187] Similarly, at step S30, the SP server extracts the reduced identification database RDBI from the database in the same way as for the first variant.
[0188] The server extends the FHE data from the reduced identification database [RDBI]FHF using the client's public key and thus obtains the same data but under double identification and client encryption, therefore denoted [RDBI]FHe,cl
[0189] At step S40, the server performs the evaluation on the extended data (under double FHE and CL encryption). It thus obtains the result directly under double encryption, via the function:
[0190] FHEe val([RDB]FHE>CL, [C]fHE,Cl) — [reS]FHE,CL
[0191] Since the result is already double-encrypted, unlike in the first variant, the server does not need to extend it at this stage (encryption under client-side encryption). At step S54, as in the first variant, it then transmits the result to the supervisors.
[0192] The supervisors then perform the partial decryption of the result: The S56 step as well as the S60 decryption step are identical to those of the first variant.
[0193] The methods and systems described in this disclosure have been presented in the specific case of fleet management. It is understood that these methods and systems can be developed for applications in all technical fields, such as the Internet of Things, the medical field, etc. Indeed, any type of data can be stored in a database in such a way as to implement the methods described in this disclosure. In particular, one or more keywords (or key values) can be attached to any field or set of fields of any data, which will then serve as filtering data as defined in this disclosure.
[0194] These keywords or key values can be calculated from the field(s) under consideration by means of any appropriate classification function.
Claims
1. Demands A method for confidentially querying a database (DB) (DF,DI,DA) hosted by a server (S) by at least one client (CL), the database comprising: - filtering data (DF), each filtering data field having at least one filtering field (departure_city; destination_city) encrypted using a filtering cipher (SE), which is a cryptosystem allowing searchable encryption; and - identification data (ID), each identification data having at least one identification field (departure_time) encrypted under an identification encryption (FHE), the identification encryption allowing a calculation on encrypted data; the database being structured in such a way as to allow, from a filtering data, the identification of zero, one or a plurality of identification data associated with the filtering data; The process includes the following steps: S10) a client defines a query (m,c) including a search index (m) and a condition (c); the index sought (m) being a vector defining a value for at least one filtering field sought (departure_city; destination_city); condition (c) being a condition to be satisfied by one or more identification data and a function of a value of at least one identification field; the client calculates or has calculated an extraction backdoor (T(m)) for the index sought (m), encrypted under said filtering cipher (SE), and transmits or has transmitted to the server (S) said encrypted extraction backdoor (T(m)), as well as said condition ([c]fhe) encrypted under the identification cipher (FHE); S20) by applying the extraction backdoor (T(m)) to the database (DB), the server (S) extracts from the database a reduced filtering database (RDBF), comprising the filtering data whose searched filtering field(s) have values equal to those of the corresponding fields of the searched index (m); S30) The server (SP) extracts a reduced identification database (RDBI) from the database, including all data identification associated with at least one data item in the reduced filtering database; S40) by implementing a confidential query method, the server identifies within the reduced identification database (RDBI) any identification data item ([di]) satisfying said condition (c); S50) the server determines and sends to the client an encrypted result ([res]fhe; [res]cL) obtained from the identified identification data item(s); and S60) the client decrypts the encrypted result ([res]FHE; [res]cE) and obtains the result in plaintext (res).
2. A confidential query method according to claim 1, wherein step S10 comprises: S12) by applying a transfer cipher (|3), for example by masking, the client calculates a ciphertext ([m][3) of the sought index (m); S14) the client sends to at least one backdoor service provider (SP) the ciphertext ([m][3) of the sought index (m); S16) from the ciphertext ([m][3) of the sought index (m), using a secret key (skSE), said at least one backdoor service provider(s) (SP) calculates a backdoor ([T([m][3)]sF) encrypted under the filtering ciphertext of the sought index (m), called the primary backdoor, and sends the primary backdoor (T([m][3)) to the client (CL1); S18) by removing the transfer encryption of the primary backdoor (T([m][3)), the client (CL1) calculates the extraction backdoor (T(m))) and transmits it to the server (S).
3. A confidential query method according to claim 2, wherein in step S14, the ciphertext ([m][3] of the sought index (m) is sent to a set of backdoor service providers (SP); the secret key held by each is a partial filtering secret key (ai) of the backdoor service provider; and in step S16, from the ciphertext ([m][3] of the sought index (m), each service provider among a plurality of said backdoor service providers calculates a partial primary backdoor ([Ti([m]|3)]SE) using its partial secret key (a;) and returns it to the server; from said partial primary backdoors, the server calculates the primary backdoor (T([m][3)).
4. A confidential query method according to claim 3, wherein the transfer cipher is a threshold transfer cipher, and at step S16, the server calculates the primary backdoor (T([m][3)) from said partial primary backdoors only if a threshold required by the threshold transfer cipher is reached.
5. A confidential query method according to any one of claims 1 to 4, wherein step S50 comprises the following operations: S52) the server obtains the result encrypted under double encryption ([res]FHECL), namely under the identification cipher and under an additional cipher, called the client cipher, which the client is able to decrypt; S54) the server transmits the result under double encryption ([res]FHF cl) to at least one decryption service provider (SP); S56) said at least one decryption service provider removes the identification cipher from the result under double encryption ([res]FHE,cL), thereby obtaining said encrypted result ([res]CL), which it transmits to the client (CL).
6. Confidential query method according to claim 5, wherein in order to obtain said result encrypted under double encryption, at step S52 the server determines the result under identification encryption, then applies to this result the client encryption, so as to obtain the result encrypted under double encryption ([res]FHFjCL).
7. A confidential query method according to claim 5, wherein to obtain said result encrypted under double encryption: at step S10, the client transmits or causes to be transmitted to the server (S) said condition ([c]FHF) encrypted under double encryption, namely under the identification cipher (FHE) and under the client cipher; following step S30, the server encrypts the reduced identification database (RDBI) under client cipher; and at step S50, the server determines the result encrypted ([res]FHE,cL) under double encryption.
8. A method for confidential interrogation according to any one of claims 5 to 7, wherein at step S54, the result under double encryption ([res]FHF>CL) is sent to a set of decryption service providers (SPs); the secret key held by each of the service providers is a partial filtering secret key (ai) of the decryption service provider; and at step S56, each service provider among a plurality of said decryption service providers performs a partial decryption of the result under double encryption ([res]FHE,cL ) by removing the identification cipher from it using its partial secret key (¾) and thus obtains a partially decrypted result ([res]ijFH E) which it returns to the server; from said partially decrypted results ([res]i>FHE ), the server calculates the encrypted result ([res]CE)-
9. A confidential query method according to claim 8, wherein the identification cipher is a threshold identification cipher; and at step S50, the server calculates the encrypted result ([res]cF) from the partially decrypted results ([res]i,FHE) only if a threshold required for the threshold identification cipher is reached.
10. A confidential query method according to any one of claims 5 to 9, in the case where the identification cipher is a homomorphic cipher (FHE), in which the client cipher is a symmetric cipher.
11. A confidential query method according to any one of claims 5 to 9, in the case where the identification cipher is a homomorphic cipher (FHE), wherein step S52 includes an extension of the homomorphic cipher using an asymmetric public key (PK^).
12. A confidential query method according to claim 11, wherein the server holds said asymmetric public key (PKCL), and the client holds a corresponding asymmetric secret key (skCL); at step S52, client encryption is applied using said asymmetric public key (PKCL); and at step S60, client encryption is removed using said asymmetric secret key (skCE).
13. A confidential interrogation method according to any one of claims 1 to 12, wherein the identification cipher is a completely homomorphic cipher (FHE).
14. A confidential query method according to any one of claims 1 to 13, wherein the filtering cipher is a public-key searchable cipher, in particular a PEKS-type cipher, or a symmetric cipher.