Abstract
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.
1. 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-but-curious [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–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 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 order-preserving 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.
2. 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–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–27]. One of the most important fundamental schemes for processing queries on an encrypted database is proposed by H. Hacigm 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. Hacigm’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. Hacigm et al. and added range queries over the encrypted database. To achieve the various computations over encrypted data, some Paillier-based improvements [8, 30–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: its queries are processed on the lowest-security level of data; 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.
3. 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.
3.1. 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.
Definition 1 (FHOPE). A FHOPE scheme consists of four phases (key generation, encryption, decryption, and computation). The detailed phases are described below.(1)Key generation: . 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: . Enc runs at the CL. The inputs to the CL are and the sensitive data in the SQL queries, and the CL obtains a ciphertext and then sends the SQL queries to a CS.(3)Decryption: . The CL runs Dec on the private key and a ciphertext and obtains a plaintext .(4)Computation: . HAMOE runs at the server, takes as input ciphertext , 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 are encrypted into vectors , where .
Definition 2 (correctness). A FHOPE scheme for plaintext domain Z is correct if, for all security parameters k, for all ,(1)for all and for every C outcome of , ;(2)for all and for every outcome of , ;(3)for all and for every outcome of , ;(4)for all sequences , for all pairs , for all obtained as above, we have ;(5)for all and for every outcome of , we have .
3.2. 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. Order-preserving 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 chosen-plaintext 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 .(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 and sends them to the challenger ;(2)the challenger picks at random and leads the interaction for the Enc algorithm on inputs and with the server CS, with the adversary observing all the ciphertexts at CS.(3)The adversary outputs , its guess for .
We say that the adversary wins the game if its guess is correct () and the sequences and have the same order relations (namely, for all , ,). That is, wins the above game if is nonnegligible, where the adversary’s advantage in the above game is defined aswhere is the random variable indicating the success of the adversary in the above game.
4. Fully Homomorphic Order-Preserving Encryption Scheme (FHOPE)
This section presents a novel fully homomorphic order-preserving 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.
4.1. 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.
KeyGen. The secret key is chosen randomly from real number set .
Encrypt. A message is encrypted into ; the encryption result is a tuple of components, corresponding to sub-ciphertexts.
Decrypt. Take as input the secret key and a ciphertext ; 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.
4.2. Construction of FHOPE Scheme
By using symmetric encryption, a full homomorphic order-preserving encryption is given as follows, which consists of three steps.
KeyGen(KG). Generate the secret key
where is a list of pairs of integers, which are large prime numbers, , , for , and . The number of key components in the key set is equal to the number of sub-ciphertexts.
Encrypt (Enc). Encrypt the plaintext , where is a plaintext; the encryption result is a tuple of components, corresponding to sub-ciphertexts. The encryption algorithm uses the components , , and to define each , as shown below, where is a strictly increasing function over and , in particular linear to . 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 is defined in a finite integer domain. We define the functions and by (5) and (6), respectively.
The noise defined in (6) should satisfy condition (7).
Decrypt (Dec). Decrypt a ciphertext , and get the plaintext .
where is a secret key; is a plaintext.
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
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 is encrypted into with the key , as shown below. Suppose that the first sub-ciphertext () 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 and , then Then Therefore, the correctness of decryption is proved.
To verify the correctness of operations supported by our scheme, suppose that we have a secret key vector and that integers are encrypted into vectors , where .
5. 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.
5.1. Addition (AD)/Subtraction
Assuming two sensitive columns and of a table , their values are integers. We use and to denote the values of and in a row t, respectively. Let and be the encrypted values of and , respectively, where and ; 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 1. The CL receives the SQL query, it uses the encryption algorithm Enc to encrypt the values of and with the private key ; their ciphertexts are and , respectively.
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: , where the homomorphic addition of and is defined as a vector addition.
The FHOPE scheme guarantees homomorphic addition according to the following theorem.
Theorem 4. The FHOPE scheme supports additive homomorphism; i.e., .
Proof.
The correctness of homomorphic addition is proved.
Subtraction operation can be converted to addition operation for processing, so it is omitted.
5.2. Multiplication (MU)
We describe the FHOPE scheme for “”. Given two sensitive columns and of a table , let and denote the values of and in a row t, respectively. Let and be the encrypted values of and , respectively, where and ; 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 1. The CL receives the SQL query, it uses the encryption algorithm Enc to encrypt the values of and with the private key , and their ciphertexts are and , respectively.
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.
Theorem 5. The FHOPE scheme supports multiplicative homomorphism. That means .
Proof. To prove this theorem, we first need to show that Then, we prove The details are given below.
Step 1. Perform the following decryption for i, .
Because we havethen it gives Step 2. We have from Step 1:
Hence, . The correctness of multiplicative homomorphism is proved.
5.3. 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 and denote the values of and in a row t, respectively. Let and be the encrypted values of and , respectively; they share the same secret key vector . For privacy protection, we calculate or , the plaintexts need to be encrypted, and we need to calculate or . 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 order-preserving property.
Suppose that any two integers and are encrypted into and with the key , as shown below.
Definition 6. Let be the set of all input plaintext values. The sensitivity of is the minimum element in the set . That is, the sensitivity is defined as
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 , , if , then .
Proof. We have if , where and are the sub-ciphertext of and , respectively. Suppose that the sub-ciphertexts and have the same random noise . To prove this theorem, we need to show ; that is,In other words, we have to proveBecause the linear expression is strictly increasing for any plaintext , we haveSince , then the minimum is , which is bigger than . Moreover, ; then,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.
5.4. 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 , 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 under the key ; the random noise is , which is stored in the CL. Then the CL computes the range of the sub-ciphertext as follows:and becausewe haveand 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.
5.5. 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: different operators share the same encryption scheme; 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 ). The FHOPE scheme guarantees data interoperability according to the following theorem.
Theorem 8. The FHOPE scheme has the property of the data interoperability; i.e., if , then .
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.
5.6. 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 is encrypted into 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 () of the n sub-ciphertexts 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 is and the plaintext 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.
6. 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.
Insert Queries. To understand how values in a query are encrypted, consider an application that wants to execute the query INSERT INTO student VALUES . The CL encrypts 10 using the FHOPE and issues the query INSERT INTO student VALUES (FHOPE), where FHOPE() is a user-defined function that implements the encryption of the FHOPE scheme.
Select Queries. Consider a query: SELECT FROM T WHERE . and 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 and , 1000 and 6800, share the same private key and random noise . and are encrypted as and , respectively. It delivers the query “SELECT FROM T WHERE ” 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.
7. 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.
7.1. 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 is defined as In the first ciphertext element , is the common divisor to be recovered. We are going to prove that it is difficult to find the secret value from the first element of any number of ciphertexts.
Let . Then, we have . Since is random number generated for each encryption, is a number that the adversary does not know, and it randomly changes for each encryption of the plaintext. Moreover, can be less than . Hence, it is difficult to recover from the first element 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.
7.2. IND-HOCPA Security
We analyze the semantic security of the FHOPE scheme by proving the indistinguishability of ciphertexts under a homomorphic order-preserving chosen-plaintext attack.
Theorem 10. A FHOPE encryption scheme is IND-HOCPA secure.
Proof. In the following game, the PPT adversary is denoted as and the challenger is denoted as . Consider any adversary and any two sequences of values ask for in the security game: and .(1)The key generation algorithm generates the key , where is a list of pairs of integers, which are large prime numbers, , , for , and .(2)The adversary chooses two equal-length sequences of values and and sends them to the challenger .(3)The challenger randomly encrypts and with key and outputs the ciphertext or , where , , and (b ) . The ciphertext (b ) is sent to the adversary .(4)If and , then the expressions of and generate the same value from to with the same probability; since is randomly sampled from the range , and have the same order relation. Hence, the advantage of distinguishing is negligible.In the following, we discuss the case where and . The case where and is similar.
If and , we have or ; depending on whether or is encrypted, and have the same order relation. Then, the advantage is negligible.
The proofs for other sub-ciphertexts and are carried out similarly; the advantage is negligible.
Therefore, the adversary cannot win the above game, and hence a FHOPE is IND-HOCPA secure.
7.3. 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 of is expressed as ; 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 in the cloud server, the following steps need to be executed (if no sub-ciphertexts of are stored, jump to Step 2).
Step 1. Update all the stored sub-ciphertexts () of by .
Step 2. Add random noise in the new sub-ciphertexts by .
Step 3. Update the value of by .
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 FROM T WHERE . The 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 , 100, share the same private key and random noise . And is encrypted as . It delivers the query “SELECT FROM T WHERE ” 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 chosen-plaintext attack, even if the adversary can get the ciphertext of , where 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.
7.4. 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 and as input and then generates ciphertexts of and of . 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.
Theorem 12. The MU can securely perform multiplication operation on ciphertext in the presence of semihonest adversary .
Theorem 13. The OC can securely perform order comparison on ciphertext in the presence of semihonest adversary .
Theorem 14. The EQ can securely perform equality checks on ciphertext in the presence of semihonest adversary .
Theorem 15. The DI can securely perform complex operation on ciphertext in the presence of semihonest adversary .
8. 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 , with selection of a list of pairs of integers [, ,, , , ], [, , , , , ], and , where , for , , , , , , and . 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.
8.1. Performance of Encryption and Decryption
The experiment shows the performance of encryption and decryption by comparing FHOPE scheme with the AES algorithm. In our experiment, we randomly generate 20000 integers, each 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.
8.2. 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 , where is the encryption of a randomly generated integers and has eight digits.
Figure 6 shows the cost of testing from to . 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 take about seconds while and about seconds while . The correctness of homomorphic addition, homomorphic multiplication, and data interoperability is also checked in the experiment.
8.3. Comparison with mOPE [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 ( ) records and insert them into an encrypted database as shown in Figure 7.
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.
8.4. Comparison with CryptDB [35]
For testing, we select 10000 records randomly from table . Our scheme is compared with CryptDB by executing three queries. [Range]: select from where . [Sum]: select from where . [Avg]: select from where .
Let control the queries’ selectivity, which is randomly sampled from the range . Figure 8 shows the time cost of FHOPE and CryptDB for performing the three queries, where the size of the table grows from to rows. The time cost is displayed as bar graph.
(a) Range
(b) Sum
(c) Avg
We can get some observations from the experimental result. 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. 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. 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.
Moreover, CryptDB cannot support some operations, such as “” and homomorphic multiplication. Therefore, CryptDB cannot support some complex SQL queries, for example, query “select from where ”, query “select A from where ”, query “select B from where ”, and query “select B from where ”. The FHOPE can support the above complex SQL queries. Since FHOPE can support addition, multiplication, order comparison, and equality checks and the FHOPE scheme has the property of the data interoperability, with the data interoperability, these operators (+, −, , , , and ) can be combined to formulate complex expressions (e.g., “”) in SQL queries. Then, the FHOPE can support complex SQL queries.
The time cost of FHOPE and CryptDB for the range queries while we change the selectivity of the queries (by adjusting ) from to 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.
9. 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.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the National Natural Science Foundation of China under Grant 61572263, Grant 61502251, Grant 61502243, and Grant 61602263, the Natural Science Foundation of Jiangsu Province under Grant BK20161516 and Grant BK20151511, the Natural Science Foundation of Anhui Province under Grant 1608085MF127, the Natural Science Foundation of Educational Commission of Anhui Province of China under Grant KJ2016B17, Grant KJ2015B19, and Grant KJ2017B15, China Postdoctoral Science Foundation under Grant 2016M601859 and Grant 2015M581794, Qing Lan Project of Jiangsu Province, 1311 Talent Plan Foundation of NUPT, NUPTSF, under Grant NY216001, and the Natural Science Foundation of the Jiangsu Higher Education Institutions of China under Grant 14KJB520031 and Grant 15KJB520027.