A Novel Secure Scheme for Supporting Complex SQL Queries over Encrypted Databases in Cloud Computing

With the advance of database-as-a-service (DaaS) and cloud computing, increasingly more data owners are motivated to outsource their data to cloud database for great convenience and economic savings. Many encryption schemes have been proposed to process SQL queries over encrypted data in the database. In order to obtain the desired data, the SQL queries contain some statements to describe the requirement, e.g., arithmetic and comparison operators (+, −, ×, <, >, and =). However, to support different operators (+, −, ×, <, >, and =) in SQL queries over encrypted data, multiple encryption schemes need to be combined and adjusted to work together. Moreover, repeated encryptions will reduce the efficiency of execution. This paper presents a practical and secure homomorphic order-preserving encryption (FHOPE) scheme, which allows cloud server to perform complex SQL queries that contain different operators (such as addition, multiplication, order comparison, and equality checks) over encrypted data without repeated encryption. These operators are data interoperable, so they can be combined to formulate complex SQL queries. We conduct security analysis and efficiency evaluation of the proposed scheme FHOPE. The experiment results show that, compared with the existing approaches, the FHOPE scheme incurs less overhead on computation and communication. It is suitable for large batch complex SQL queries over encrypted data in cloud environment.


Introduction
With the advance of cloud storage and computing, the business opportunity to offer a database as an outsourced service is gaining momentum.Today numerous enterprises and end users may outsource their data to those cloud service providers for lower cost and better performance [1,2].Outsourced databases can be applied to many scenarios.For example, one outsourced database application scenario is shown in Figure 1, and, in this example, the data owners, such as hospitals, may want to outsource the medical records to the cloud databases.Patients' medical records contain sensitive information (e.g., blood pressure, body mass index).Based on the assumption that service provider is honest-butcurious [3,4], sensitive information needs to be encrypted before being uploaded to the cloud database.The data owners can query their data from cloud database.Then, the cloud database should execute SQL queries over the encrypted data.However, the encrypted data may also bring significant difficulty in executing standard SQL and computing over these data.For example, the encrypted data may lose the original order, without the set of primitive operators, such as equality checks, order comparisons, addition, multiplication, aggregates (sums), and joins.
To date, many fully homomorphic encryption (FHE) and order-preserving encryption (OPE) schemes were proposed [5][6][7][8][9][10].The FHE schemes are not practical for either cloud database providers or users, because of high computational overhead [11,12], and these schemes only support homomorphic addition and homomorphic multiplication over encrypted data.The OPE schemes reveal the order and expose some private information to the cloud service provider, which support SQL range queries.On the contrary, CryptDB uses onions to protect private data and support efficient SQL queries over encrypted data.The onion encryption is a multilayered encryption scheme, and for processing different types of computations multiple onions are needed in practice, because the computations are supported by different encryption schemes.For example, the CryptDB can perform range queries while a column is encrypted with order-preserving encryption, and if it performs aggregate queries, such column is encrypted with homomorphic encryption.Furthermore, the functionalities of CryptDB lack some useful features (e.g., there is no support for queries containing multiplication, and there are also some other limitations).As a result, a query like SELECT * FROM T1 WHERE  = 100 AND  +  ×  >  cannot be executed by CryptDB.How to design a practical encrypted scheme that supports different operators (+,−,×,<,>,=) in complex SQL queries over encrypted data without privacy breaches remains a challenging and open problem.
Motivated by the aforementioned problem, we design a full homomorphic algorithm with the order-preserving feature to support complex SQL queries that contain different operators (such as addition, multiplication, order comparison, and equality checks) over encrypted data.Our proposed FHOPE scheme makes up for FHE's shortcoming, which supports order comparison, enables range queries to be executed in database operations, and reduces computational costs to increase efficiency.Because it has order-preserving function, the order of the plaintext values is inevitably revealed.The ideal security goal for an order-preserving scheme, IND-OCPA [13], is to reveal no additional information about the plaintext values besides their order.Our proposed scheme is an ideal security homomorphic order-preserving encryption scheme where the ciphertexts reveal nothing except for the order of the plaintext values.Regarding efficiency, we can see that security and efficiency are contradictory; the higher security, the lower efficiency.Practicality and efficiency are very important for database applications.The FHOPE is efficient and practical, satisfies the need of database applications, and solves the complex queries problems that need to be solved in the database.FHOPE can resist the homomorphic order-preserving chosen-plaintext attack.Here, we summarize our contributions as follows: (i) In the cloud database environment, data is frequently queried by users.It is critical to determine whether an encryption scheme can provide complex SQL queries like the predicates containing different operators over encrypted data.We combine homomorphism with order-preserving and design a novel FHOPE scheme to support addition, multiplication, order comparison, and equality checks.These operators are data interoperable, so they can be combined to formulate complex SQL queries.Then, the FHOPE scheme enables a wide range of SQL queries over the encrypted data to be expressed.As a result, it does not require downloading the encrypted data to client.Therefore, it can improve the efficiency in dealing with data query and processing.
(ii) Furthermore, we optimize the FHOPE scheme by adding some random noise with a certain probability  and by specifying any sub-ciphertext with orderpreserving property.Besides, we apply the FHOPE scheme to the cloud database application.
(iii) We evaluate the proposed FHOPE scheme in terms of security, efficiency, and complexity.The concrete FHOPE scheme is provably secure according to the formal security proof.The experiment results show that the FHOPE scheme incurs less overhead in computation and communication than the existing approaches.It is suitable for large batch of SQL queries over encrypted data in cloud environment.
The remainder of this paper is organized as follows.Section 2 discusses some related work.In Section 3 we describe the system model and attack model.Section 4 gives the basic idea of FHOPE scheme and its construction.Section 5 presents the correctness of FHOPE scheme.Section 6 describes the FHOPE's application in a cloud database.In Section 7 we give security analysis.Section 8 describes the evaluations.Section 9 concludes the paper.

Related Work
The security of data and processing of the encrypted data in a cloud database environment have caused much research concern recently [14,15].Many schemes have been designed with various techniques: fully homomorphic scheme (FHE) and order-preserving encryption (OPE).Gentry had described a FHE [7,8] in 2009; the FHE supports various computations over ciphertexts.Since Gentry's result of research breakthrough, a great many improvements [12,[16][17][18][19][20][21] have been made; the performance was enhanced.However, since the current FHE schemes have low efficiency, they are not suitable for practical applications.Another encryption scheme is OPE; it is primarily used in databases for supporting order comparison on ciphertexts.OPE [5] solves the encrypted query problems in database systems, which was first proposed in 2004.Although a large number of researchers have made great efforts on the OPE schemes [9,13,22,23], these schemes have failed to achieve ideal security.Until now, Popa et al. proposed the mutable order-preserving encoding (mOPE) scheme [24], which is an ideal security OPE scheme; it builds a balanced search tree, which contains the plaintext values encrypted by the application.mOPE is an ideal security scheme, but it has the low efficiency due to the interaction and tree balancing.Moreover, their works only process order comparison on ciphertexts.Some solutions were proposed for querying data over the encrypted database [25][26][27].One of the most important fundamental schemes for processing queries on an encrypted database is proposed by H. Hacig ü m ü s .et al. in [25].It encrypts the data at a tuple level, and then a predefined set of attributes can be used in queries.Following H. Hacig ü m ü s .'s idea, some improvements were proposed [28,29].The scheme [28] stores redundant data for querying data over the encrypted database, and B. Hore et al. [29] extended the model of H. Hacig ü m ü s .et al. and added range queries over the encrypted database.To achieve the various computations over encrypted data, some Paillier-based improvements [8,[30][31][32][33][34] were presented.The schemes in [30,31] can support homomorphic addition, homomorphic multiplication, and order comparison, but the order comparison is realized by converting to subtraction operation; they have high computation overhead.Yan et al. [33] can only support the addition and cannot support other computation operations.Peter et al. [34] proposed an efficient outsourcing multiparty computation framework under multiple keys, but the scheme only supports addition and multiplication and cannot support other operations.
CryptDB [35] and SDB [36] are well-known systems for processing queries over encrypted database.CryptDB uses onions to support SQL queries over encrypted databases, where range queries and equality condition queries rely on order-preserving encryption [24] and deterministic encryption, respectively.It performs specific operations with homomorphic encryption, to support aggregate queries; it implemented the Paillier cryptosystem [29], but it cannot support homomorphic multiplication.The CryptDB has the following limitations: (1) its queries are processed on the lowest-security level of data; (2) the same data needs to be reencrypted according to different types of computation.For example, it can perform range queries while a column is encrypted with order-preserving encryption, and if it performs aggregate queries, such column is encrypted with homomorphic encryption.SDB [36] can process queries that contain different kinds of operations; nevertheless, it requires massive computation resources and communication cost.
Thus, it is always necessary to establish an efficient scheme to process database queries without involving multiple incompatible encryption schemes.

System Model and Attack Model
In this section, we describe the system model and the attack model and give formal definition of the scheme.The prototype will be built based on the system model.The security of the proposed scheme will be analyzed in Section 7.

System Model.
Figure 2 shows the overall architecture.The client receives queries from users, generates the private key and encrypts the sensitive data, sends the SQL queries to the cloud server, receives queries results, decrypts the results using the corresponding keys, and sends the decrypted result to the users.
A FHOPE scheme in this paper involves two different entities which are described below.
Client (CL).The client is data owner.For protecting data privacy, it uses the private key to encrypt the sensitive data and then outsources the encrypted data to a cloud server.The CL can also send the SQL queries to a CS and decrypt the queries results from the CS.

Cloud Server (CS).
A CS is hosted by the service provider that stores the databases in cloud.It stores and manages the data of users.A CS also stores the encrypted intermediate and final results.Furthermore, a CS is able to perform homomorphic addition, homomorphic multiplication, order comparison, and equality checks over encrypted data and then process complex SQL queries on encrypted data.
To describe our scheme, we give the formal definition of FHOPE.
(1) Key generation:  ← (1  ).KeyGen runs at the CL, takes as input the security , and outputs a private key .The CS cannot get access to the private key.
(2) Encryption:  ← (, V).Enc runs at the CL.The inputs to the CL are  and the sensitive data V in the SQL queries, and the CL obtains a ciphertext  and then sends the SQL queries to a CS.
(3) Decryption: V ← (, ).The CL runs Dec on the private key and a ciphertext  and obtains a plaintext V.
(4) Computation:  ← ( 1 , . . .,   ).HAMOE runs at the server, takes as input ciphertext  1 , . . .,   , and can perform addition, multiplication, order comparison, and equality checks over the ciphertext and then output the result of the computation.
To describe the correctness of our scheme, we define what it means for the scheme to be correct.Intuitively, the scheme should decrypt the correct values and correctly support homomorphic addition, homomorphic multiplication, and order comparison on the ciphertext.Suppose that we have a secret key vector () and that  integers V  ∈  (  (2) for all V  ∈  and for every   outcome of (V  , ()), ((), ∑  =1   ) = ∑  =1 V  ; (3) for all V  ∈  and for every   outcome of (V  , ()), ((),   ×   ) = V  × V  ; (4) for all sequences  = {V 1 , . . ., V  } ∈   , for all pairs V  , V  ∈ , for all   ,   obtained as above, we have (5) for all V  ∈  and for every   outcome of (V  , ()), we have

Attack Model.
In this section, we present the potential threats and the security requirements for database outsourcing in the cloud.In our scheme, we assume the same security model commonly adopted in related literatures in this field (e.g., [35]), where the CL is the data owner.Thus, the CL is trusted; the CS is honest-but-curious; that is, the computation provided by the CS is able to be executed correctly, and it does not change the data or query results, but the CS tries its best to obtain the privacy information of the processed data.Orderpreserving encryption is primarily used in databases for supporting order comparison on ciphertexts, it exposes the order of data, and then the cloud can learn the statistical properties (like order) through repeated query requests.Therefore, we introduce an adversary  in our model, which aims to decrypt the ciphertexts of a challenge sent to applications with the following capabilities: (1)  may try to obtain the private key and guess the plaintext values from ciphertexts outsourced from a CL.
(2)  may compromise the CS by guessing the plaintext values of the computation results received from the CS.
(3)  may compromise the CS to guess the plaintext values of the queries results based on statistical properties (like order).
For satisfying the security requirements of the FHOPE scheme, we formalize the security definition of a FHOPE scheme for IND-HOCPA (indistinguishability under a homomorphic order-preserving chosen-plaintext attack), which intuitively says that the scheme must not leak anything besides order.The homomorphic order-preserving chosenplaintext attack is a restricted chosen-plaintext attack.We remark that the restricted chosen-plaintext attack is used in literature [10].We adapt the security definition of literature [13] to the syntax of our proposed scheme.

Definition 3 (IND-HOCPA security). A FHOPE scheme is IND-HOCPA secure, if any probabilistic polynomial time (PPT) adversary 𝐴 has only a negligible advantage
to win in the following game.The FHOPE game between the adversary  and the challenger  is given below: (1) For the secure parameter k, the challenger  runs the key generation algorithm KeyGen and generates  ← (1  ).
(2) The challenger  and the adversary  engage in a polynomial number of rounds of interaction.For round , (1) the adversary  chooses two equal-length messages V 0  , V 1  ∈  and sends them to the challenger ; (2) the challenger  picks  ∈ {0, 1} at random and leads the interaction for the Enc algorithm on inputs  and V   with the server CS, with the adversary  observing all the ciphertexts at CS.
We say that the adversary  wins the game if (1) its guess is correct ( =   ) and (2) the sequences {V 0  }  and {V 1   }  have the same order relations (namely, for all , , That is,  wins the above game if V − , () is nonnegligible, where the adversary's advantage V − , () in the above game is defined as where  , is the random variable indicating the success of the adversary in the above game.

Fully Homomorphic Order-Preserving Encryption Scheme (FHOPE)
This section presents a novel fully homomorphic orderpreserving encryption (FHOPE) scheme to realize various types of operations over encrypted data, such as addition, multiplication, order comparison, and equality checks.Firstly, we describe the notations employed in the remainder of the paper.Then, we construct the FHOPE scheme and prove the correctness of decryption.For clear description, Table 1 summarizes the notations employed in the paper.

Homomorphic Encryption Scheme.
A practical homomorphic encryption scheme is presented by Liu in 2013 [37], which contains three steps and can be described as follows.
Decrypt.Take as input the secret key () and a ciphertext  = ( 1 , . . .,   ); compute and output a message : Our proposed scheme differs from that of [37] in that we focus on designing an encryption scheme that supports complex expressions containing different operators (+, −, ×, <, >, and =) in SQL queries over encrypted data and data interoperable operators.

Construction of FHOPE Scheme
. By using symmetric encryption, a full homomorphic order-preserving encryption is given as follows, which consists of three steps.
Encrypt (Enc).Encrypt the plaintext (V, ()) = ( 1 , . . .,   ), where V is a plaintext; the encryption result is a tuple of  components, corresponding to  sub-ciphertexts.The encryption algorithm uses the components   ((), V),   ((), ), and   to define each   , as shown below, where   is a strictly increasing function over () and V, in particular linear to V.   is a function over () and , which calculates a random number for randomizing   ,   denote the random noise, which is randomly sampled from the range [−∞, +∞], and a set  of n pairs of numbers {( 1 ,  1 ), . . ., (  ,   )} is defined in a finite integer domain.We define the functions   () and   () by ( 5) and ( 6), respectively.
Decrypt (Dec).Decrypt a ciphertext  = ( 1 , . . .,   ), and get the plaintext V. where Then, the decryption algorithm is defined as where   is an -th decryption function over the key vector, and it has a linear time complexity with respect to .Based on the definition of   in (4), ( 8) is rewritten into (9), which is equal to

Security and Communication Networks
In order to ensure the validity of decryption steps in (9), it has to satisfy the conditions

Proof of Correctness for Decryption
Proof.To prove correctness of decryption, suppose that any V 1 ∈  is encrypted into  1 = ( 11 , . . .,  1 ) with the key (), as shown below.
Suppose that the first sub-ciphertext ( 11 ) has order-preserving property, and random noise  is added to the first and second sub-ciphertext, respectively.Then, we have to prove That is, where We have Because  2 = − 1 and  ̸ = 0, then Then Therefore, the correctness of decryption is proved.

Correctness of the FHOPE
A query operation can request arbitrary data with a statement to describe the desired data.In order to obtain the desired data, the query contains some statements to describe the requirement, e.g., arithmetic and comparison operators (×, +, −, =, >, and <).These operators are data interoperable, so they can be combined to formulate complex queries, and we are concerned with executing queries that contain multiple different operations, such as WHERE  +  ×  < .Our data model is column-based in a table.In this section, we prove the correctness of additive homomorphism, multiplicative homomorphism, order-preserving, and data interoperability and describe how these operators are implemented in our scheme.

Addition (AD)/Subtraction.
Assuming two sensitive columns   and   of a table , their values are integers.We use V  and V  to denote the values of   and   in a row t, respectively.Let   and   be the encrypted values of V  and V  , respectively, where   = ( 1 , . . .,   ) and   = ( 1 , . . .,   ); they share the same secret key vector ().
Given two sensitive columns   and  , if the application issues the query SELECT * FROM Table 1 WHERE   =   +  , the SQL query processing is as follows.
Step 2. The CS executes the SQL query on the encrypted data just like on plaintext.Due to additive homomorphism, the CS can directly add encrypted data one by one as follows:   +   = ( 1 + 1 , . . .,   +  ), where the homomorphic addition of   and   is defined as a vector addition.

𝐷𝑒𝑐 ((
Security and Communication Networks 7 The correctness of homomorphic addition is proved.Subtraction operation can be converted to addition operation for processing, so it is omitted.

Multiplication (MU).
We describe the FHOPE scheme for "×".Given two sensitive columns   and   of a table , let V 1 and V 2 denote the values of   and   in a row t, respectively.Let  1 and  2 be the encrypted values of V 1 and V 2 , respectively, where  1 = ( 11 , . . .,  1 ) and  2 = ( 21 , . . .,  2 ); they share the same secret key vector ().
If the application issues the query SELECT * FROM Table 1 WHERE   =   ×  , the SQL query processing is as follows.
Step 2. The CS executes the SQL query on the encrypted data just like on plaintext.Due to multiplicative homomorphism, the CS can directly multiply encrypted data one by one as follows: where the multiplication of two ciphertexts can be defined as an outer product.
Our objective is to perform multiplication operations on the encrypted data just like on plaintext.The FHOPE scheme guarantees homomorphic multiplication according to the following theorem.
Because we have then it gives Step 2. We have from Step 1: Hence, ((), The correctness of multiplicative homomorphism is proved.

Order Comparison (OC).
We consider two comparison operators, namely, operator ">" and operator "<".They are mostly used in select queries.Given two sensitive columns   and   of table .Let V 1 and V 2 denote the values of   and   in a row t, respectively.Let  1 and  2 be the encrypted values of V 1 and V 2 , respectively; they share the same secret key vector ().For privacy protection, we calculate the plaintexts need to be encrypted, and we need to calculate  1 >  2 or  1 <  2 .That is, the goal of FHOPE scheme is that the sort order of ciphertexts matches the sort order of the corresponding plaintexts.Here we prove that our scheme has orderpreserving property.
Definition 6.Let  = {V 1 , V 2 , . . ., V  } be the set of all input plaintext values.The sensitivity of  is the minimum element in the set In fact, the sensitivity is the least gap, which was evaluated in different privacy protection [38].And by its definition the sensitivity is always bigger than 0.

Theorem 7. Given the sensitivity 𝑆 of input value 𝑉, for all
Proof.We have  1 >  2 if  1 >  2 , where  1 and  2 (1 ≤  ≤ ) are the sub-ciphertext of  1 and  2 , respectively.Suppose that the sub-ciphertexts  1 and  2 have the same random noise .To prove this theorem, we need to show  1 −  2 > 0; that is, In other words, we have to prove Because the linear expression   ((), V) is strictly increasing for any plaintext V, we have Since Hence, the theorem holds if Because the noise for each sub-ciphertext satisfies condition (7), the theorem is proved.
Therefore, the correctness of order-preserving property is proved.

Equality (EQ).
Equality operator (=) is a common operator in SQL query, for example; a SQL operation is "SELECT name FROM table WHERE score = 90", which requires equality checks on ciphertext.The existing solution is to support equality checks by using deterministic encryption.The FHOPE scheme can also support equality checks even though some noise has been added, and it does not need to use deterministic encryption.We can employ two methods to implement the equality checks.A simple solution is to remove the random noise of existing ciphertexts in database.But the problem is that this solution needs to modify the ciphertexts in the database to increase the cost of computation; moreover, it makes the ciphertexts in an unsafe state.Hence, we take the second solution.Given a search keyword  = 100, to search a ciphertext whose plaintext value is 100 in encrypted database, the following steps need to be executed.
Step 1.The CL uses FHOPE to encrypt the search keyword  into a ciphertext  = ( 1 , . . .,   ) under the key (); the random noise is , which is stored in the CL.Then the CL computes the range of the sub-ciphertext   (1 ≤  ≤ ) as follows: and because we have and the range (  ((), ) + ,   ((),  + ) + ) of the sub-ciphertext   to the CS is sent.
Step 2. The CS compares the range of the sub-ciphertext   with the existing i-th sub-ciphertexts of ciphertexts in encrypted database, if an existing i-th sub-ciphertext falls within the range of the sub-ciphertext   , it has the same plaintext value 100 as the search keyword , and so they are equal.The CS sends the search result to the CL.
Therefore, the second solution implements equality checks while ensuring the security.Because the equality check is based on the order comparison, the order comparison is correct; then the equality check is correct.

Data Interoperability (DI).
As that shown below, the proposed scheme can also provide efficient operators with data interoperability.The data interoperability has the following two characteristics: (1) different operators share the same encryption scheme; (2) the output of an operator can be taken as input of another.With the data interoperability, these operators (×, +, −, =, >, and <) can be combined to formulate complex expressions in SQL queries (e.g., SELECT * FROM Table 1 WHERE  + ×  < 10000).The FHOPE scheme guarantees data interoperability according to the following theorem.

Theorem 8. The FHOPE scheme has the property of the data interoperability
Security and Communication Networks Proof.To prove this theorem, we need to show According to Theorems 4, 5, and 7, we have The correctness of data interoperability is proved.

Improving Efficiency.
In encryption algorithm Enc, some random noise   has been added in each sub-ciphertext to augment the security of FHOPE scheme.However, this process reduces the efficiency of the scheme.Here, we use two measures to improve efficiency.One approach is that two sub-ciphertexts in a ciphertext have order-preserving function.For example, the plaintext V 1 is encrypted into  1 = ( 1  1 , . . .,  1  ) under the key (), each sub-ciphertext is a ciphertext of the plaintext, and the sub-ciphertexts are independent of each other, so any sub-ciphertext of the n sub-ciphertexts has order-preserving property; it means that the ciphertext has order-preserving property.Then, we can specify that the first sub-ciphertext ( 1  ) of the n subciphertexts has order-preserving property.Another approach is to add random noise   with a certain probability . Figure 3 shows that, with the growth of probability , the time cost increases while the length of the plaintext is fixed.We will analyze the relationship between probability  and the time cost of inserting a ciphertext.
The cost of inserting a ciphertext includes encrypting the plaintext to be inserted, inserting the ciphertext, and updating random noise.Assume that the length of plaintext V is  and the plaintext V is encrypted into .Let   ,   , and   denote the time of encrypting, the time of inserting operation, and the time of updating random noise, respectively.For  ciphertexts of  stored in the database, the probability of adding random noise in the ciphertext is .Then, the time for inserting a ciphertext  is : where  ×   ×  is generated by inserting the new random noise; it is the time of updating the existing random noise.When we insert  encrypted values into the database, we have Then, According to (44), we can infer the approximate linear relationship between total time () and probability  when  is fixed, and it is consistent with Figure 3. Figure 4 shows that the total time () is exponentially related to  when probability  is fixed.For efficiency, we can conclude that security and efficiency are contradictory; the higher the security, the lower the efficiency.

Using FHOPE in a Database Application
The FHOPE is mainly used in the database; in this section, we describe how to use FHOPE in a database.As mentioned in Section 5, FHOPE allows efficient addition, multiplication, order comparison, and equality checks computations on an encrypted database in the same way as on unencrypted database, and the database server software does not need to be modified.
Setup.Using FHOPE in a database requires the following setup: (i) A CL uses the FHOPE to encrypt the sensitive data, and the encrypted data is outsourced to be stored in a cloud database.The CL stores the private keys.
(ii) User-defined functions (UDFs) in the database server implement FHOPE's computation function.

Security Analysis
The security analysis of the FHOPE scheme focuses on the security of the key (), IND-HOCPA (indistinguishability under a homomorphic order-preserving chosen-plaintext attack) security and the security of FHOPE scheme.Assume that a CL sends the SQL query to a CS via a secure channel.First, we will prove that it is difficult to recover the secret component  →   in a key () from ciphertexts.Then, based on the difficulty of the key () recovery problem, we prove the IND-HOCPA security of the scheme.We present the privacy protection in queries.Finally, we demonstrate that the security of FHOPE's properties is guaranteed by the security of key () and IND-HOCPA security of FHOPE.

Security of the Key 𝐾(𝑛).
The hardness of the key search problem is based on the approximate greatest common divisors (AGCD) problem.The AGCD problem was proposed by Howgrave-Graham [39].Given any number of the approximate multiples   = ℎ *   +  of ℎ, where ℎ,   , and   are integers, the problem is to find the hidden common divisor ℎ.Note that   and   change in each   .In particular, if   can be as large as ℎ, it is impossible to reconstruct ℎ from any number of approximate multiples   [40].

As we know, 𝐾(𝑛
where  →   = (  ,   ) is a secret vector.In the following, we prove that it is hard to recover the secret component  →   in a key () from any number of ciphertexts.Theorem 9. Given any number of ciphertexts from the FHOPE encryption with (), it is difficult to recover  →   in a key ().
Proof.As shown in the FHOPE encryption, a ciphertext  = ( 1 , . . .,   ) is defined as In the first ciphertext element  1 ,  1 is the common divisor to be recovered.We are going to prove that it is difficult to find the secret value  1 from the first element  1 of any number of ciphertexts.
Let  1 =  1 ((),  1 ) +  1 .Then, we have Since  1 * V is random number generated for each encryption,  1 is a number that the adversary does not know, and it randomly changes for each encryption of the plaintext.Moreover,  1 can be less than  1 .Hence, it is difficult to recover  1 from the first element  1 of any number of ciphertexts according to the hardness of the AGCD problem.The proofs for other secret values   and   in () are carried out similarly.

IND-HOCPA Security.
We analyze the semantic security of the FHOPE scheme by proving the indistinguishability of ciphertexts under a homomorphic order-preserving chosenplaintext attack.Theorem 10.A FHOPE encryption scheme is IND-HOCPA secure.
(2) The adversary  chooses two equal-length sequences of values V 0 and V 1 and sends them to the challenger .
In the following, we discuss the case where Therefore, the adversary  cannot win the above game, and hence a FHOPE is IND-HOCPA secure.

Privacy Protection in Queries.
The adversary can collect some useful statistical information after receiving query requests; it tries to guess the plaintext corresponding to the ciphertext based on statistical information.However, we will describe that the FHOPE scheme can reduce the privacy leakage greatly in this scenario.
To solve the mentioned problem, we add some random noise in each sub-ciphertext.Let   denote the random noise, which is randomly sampled from the range [−∞, +∞], and  denote the column attribute of the database table.Then, the sub-ciphertext  1  (1 ≤  ≤ ) of V 1 is expressed as   ((), V 1 ) +   ((),  1  ) +  1 ; the range of noise is different for different input values.Suppose  (default value is 0 if there are no sub-ciphertexts of  stored on cloud server) denotes the latest noise.To store  1   in the cloud server, the following steps need to be executed (if no sub-ciphertexts of  are stored, jump to Step 2).
Step 3. Update the value of  by  =  1 .
Therefore, due to adding random noise, the ciphertext value is random.The same plaintexts are mapped to different ciphertexts.The random noise of the same attribute is continuously updated with the insertion of new data in the cloud database, and the adversary cannot guess the random noise.
Consider a query SELECT  1 FROM T WHERE  1 > 100.The  1 denotes the sensitive column in a table ; their values are encrypted and stored in a cloud database.The CL encrypts 100 using the FHOPE, and the values of  1 , 100, share the same private key and random noise .And  1 is encrypted as 1.It delivers the query "SELECT 1 FROM T WHERE 1 > (100)" to a CS.Since the data is in the encrypted form and the random noise of each ciphertext is different, the adversary cannot get any knowledge of the order information.The random noise of the same attribute is continuously updated with the insertion of new data in the cloud database (that is, the random noise of the same attribute is the same), and then the order of plaintexts remains in the ciphertexts in the cloud database.Then, the CS executes the query on encrypted data as if the data were not encrypted, and the adversary obtains the query results.Since the random noise is dynamically updated, the order of query results loses freshness.In other words, the repeated query is issued again, and the returned ciphertexts are different.Moreover, we used the restrictions of literature [10] for chosenplaintext attack, even if the adversary can get the ciphertext of {V 1 , V 2 , . . ., V  }, where {V 1 , V 2 , . . ., V  } is a dense one, but the ciphertexts are disordered because they are obtained at different time.Therefore, previous query requests will not help the adversary to learn the privacy information, and the adversary cannot gradually find out the order information and get some useful statistical information after many query requests.

The Security of FHOPE Properties.
Our security model securely realizes ideal properties in the presence of noncolluding semihonest adversary.For the sake of simplicity, we do it for the specific scenario of our properties, which involves CL and CS.We need to construct simulator   against adversary   that corrupts CS.
Theorem 11.The AD can securely perform addition operation on ciphertext in the presence of semihonest adversary   .
Proof.CL receives plaintexts V and V  as input and then generates ciphertexts  of V and   of V  .Finally,  and   are returned to   .
simulates   as follows: it receives  and   as input and generates the sum of  and   by performing addition operation.  sends the sum of  and   to   .
The   's view contains encrypted data.In the real and ideal executions, the views of   are indistinguishable, because CL is trusted and the FHOPE is IND-HOCPA secure.
The security proofs of MU, OC, EQ, and DI are similar to that of AD under the semihonest adversary   .We give only the theorems here.

Evaluations
The section focuses on the testing of the FHOPE's performance.We design four experiments to test its performance.Simultaneously, the correctness of FHOPE's properties (such as additive homomorphism, multiplicative homomorphism, order-preserving, and data interoperability) is also checked in these experiments.
The experiments configuration is under CentOS Linux with an Intel Xeon CPU E3-1226 Processor (3.3GHz) and the 16.0GB RAM, which has 4 processor cores.The prototype is built based on the architecture shown in Figure 2. We implement the proposed prototype using Java language and MySQL 5.6.In our experiment, the secret key () is configured to have  = 6, with selection of a list of pairs of integers [( 1 ,  1 ), ( 2 ,  2 ),( 3 ,  3 ), ( 4 ,  4 ), ( 5 ,  5 ), ( 6 ,  6 )], [( 1 ,  1 ), ( 2 ,  2 ), ( 3 ,  3 ), ( 4 ,  4 ), ( 5 ,  5 ), ( 6 ,  6 )], and   , where   *   > 0,   ̸ = 0 for 1 ≤  ≤ 6,   of which has 6 digits.Then, we compare our scheme with the AES algorithm by testing the time cost of encryption and decryption.According to Figure 5, the time cost of AES's encryption and decryption exhibits exponential growth with respect to the number of integers; it costs 230 milliseconds to encrypt 20000 integers.And the FHOPE scheme costs 4 milliseconds to encrypt 20000 integers, which is about 57 times faster than AES algorithm for encryption.We can see that FHOPE scheme is also faster than AES for decryption.Thus our scheme is practically efficient and suitable for large batch of data encryption and decryption.

Performance of Homomorphic Operations.
The FHOPE scheme has additive homomorphism, multiplicative homomorphism, and data interoperability.The polynomial evaluation can demonstrate these properties of the FHOPE scheme.Then, we test the performance of addition and multiplication with high-degree polynomials over ciphertexts.The polynomial is ∑  =1   , where  is the encryption of a randomly generated integers and has eight digits.
Figure 6 shows the cost of testing ∑  =1   from  = 1000 to  = 9000.The experiment result shows the efficiency of FHOPE scheme for performing many addition and multiplication operations.For instance, the addition and multiplication operations for calculating ∑  =1   take about 0.2 seconds while  = 1000 and about 18.7 seconds while  = 9000.The correctness of homomorphic addition, homomorphic multiplication, and data interoperability is also checked in the experiment.[24].For evaluating the performance of the FHOPE's order-preserving, we compare the FHOPE scheme with mOPE scheme using a simple synthetic dataset on which data insertion is executed.In order to test the performance of data insertion, we generate  ( ∈ [500, 6000]) records and insert them into an encrypted database as shown in Figure 7.

Comparison with mOPE
From Figure 7, we can see that the mOPE scheme has the lowest performance.The FHOPE scheme is more efficient  than the mOPE scheme.In mOPE scheme, the client and the server side need to interact with each other when encrypting a message, and the server needs to adjust the encoding tree to achieve balance when adding new nodes.Our scheme is constructed by some linear mathematical functions without any interaction, and it has a higher efficiency.[35].For testing, we select 10000 records randomly from table .Our scheme is compared with CryptDB by executing three queries.
Let  control the queries' selectivity, which is randomly sampled from the range [100, 10000].Figure 8 shows the time cost of FHOPE and CryptDB for performing the three queries, where the size of the table grows from 1 to 8 rows.The time cost is displayed as bar graph.
We can get some observations from the experimental result.(1) CryptDB takes more time to execute the range queries than FHOPE, because the CryptDB uses mOPE to implement the comparison operations.The efficiency of mOPE is lower than FHOPE as shown in Figure 7. (2) For the sum and avg queries, the execution time of FHOPE is lower than CryptDB, because CryptDB employs Paillier's homomorphic encryption scheme and UDFs (user-defined functions) to compute sum aggregates and averages.The low efficiency of Paillier's homomorphic encryption scheme leads to the low efficiency of CryptDB.(3) To perform range, sum, and avg queries, CryptDB employs various encryption schemes.FHOPE makes up for CryptDB's shortcoming, which can support homomorphic addition, homomorphic multiplication, order comparison, and equality checks.
The time cost of FHOPE and CryptDB for the range queries while we change the selectivity of the queries (by adjusting ) from 10% to 90% is shown in Figure 9.The queries time of FHOPE is less than that of CryptDB.From Figure 9, we can see that the queries overhead of FHOPE is approximate linear growth as the selectivity of the queries increases; it indicates that the FHOPE scheme has a good stability.

Conclusion
In this paper, we have presented a novel FHOPE scheme that can support direct homomorphic addition, homomorphic multiplication, order comparison, and equality checks on the ciphertext.The FHOPE scheme can be applied in a cloud database environment, which still uses standard SQL statements and allows the cloud server to perform complex SQL queries over the encrypted data without repeated encryption.We have proved the security of our FHOPE scheme from four aspects: the security of the key (), IND-HOCPA security, the privacy protection in queries, and the security of FHOPE properties.The security of the key () is based on the AGCD problem.Moreover, we have implemented a prototype in Java and evaluated the performance of our scheme in terms of encryption, decryption, and homomorphic operations, and our scheme is compared with mOPE scheme and CryptDB.Through experiment, we prove that the FHOPE scheme incurs less overhead on computation.It is suitable for large batch of data encryption and decryption in cloud database systems.

Figure 1 :
Figure 1: Data owners outsource their data (e.g., credit card details and patient's medical records) to the cloud database.The sensitive data need to be encrypted.The cloud server provides storage and query service.

Figure 2 :
Figure 2: System model for outsourced databases.

Figure 3 :
Figure 3: The relationship between time cost and probability.

Figure 4 :
Figure 4: The relationship between time cost and numbers.
(10)nderstand how values in a query are encrypted, consider an application that wants to execute the query INSERT INTO student VALUES(10).The CL encrypts 10 using the FHOPE and issues the query INSERT INTO student VALUES (FHOPE(10)), where FHOPE() is a user-defined function that implements the encryption of the FHOPE scheme.Select Queries.Consider a query: SELECT * FROM T WHERE  1 ×  2 + 1000 > 6800. 1 and  2 denote the sensitive columns in a table ; their values are encrypted and stored in a cloud database.The CL encrypts 1000 and 6800 using the FHOPE, and the values of  1 and  2 , 1000 and 6800, share the same private key and random noise . 1 and  2 are encrypted as  1  and  2 , respectively.It delivers the query "SELECT * FROM T WHERE  1  ×  2  + (1000) > (6800)" to a CS.The CS executes the query on encrypted data as if the data were not encrypted and returns the query results to CL.The CL decrypts the query results and returns them to the applications.
1 ,  1 ) +  1 generate the same value from −∞ to +∞ with the same probability; since   is randomly sampled from the range [−∞, +∞], V 0 and V 1 have the same order relation.Hence, the advantage the same order relation.Then, the advantage V − , () is negligible.The proofs for other sub-ciphertexts  0 and  1 (2 ≤  ≤ ) are carried out similarly; the advantage V −

Theorem 12 .
The MU can securely perform multiplication operation on ciphertext in the presence of semihonest adversary   .The OC can securely perform order comparison on ciphertext in the presence of semihonest adversary   .
1 * , and  6 <  6 *  1 * .And a simple synthetic dataset is a table  with three sensitive columns , , and , which has 1 million records.The values in each column are randomly generated integers.