Secure and Practical Outsourcing of Linear Programming in Cloud Computing

Secure and Practical Outsourcing of Linear

Programming in Cloud Computing

Abstract:

Cloud Computing has great potential of providing robust computational power to the society at reduced cost. It enables customers with limited computational resources to outsource their large computation workloads to the cloud, and economically enjoy the massive computational power, bandwidth, storage, and even appropriate software that can be shared in a pay-per-use manner. Despite the tremendous benefits, security is the primary obstacle that prevents the wide adoption of this promising computing model, especially for customers when their confidential data are consumed and produced during the computation.

On the one hand, the outsourced computation workloads often contain sensitive information, such as the business financial records, proprietary research data, or personally identifiable health information etc. To combat against unauthorized information leakage, sensitive data have to be encrypted before outsourcing so as to provide end to- end data confidentiality assurance in the cloud and beyond. However, ordinary data encryption techniques in essence prevent cloud from performing any meaningful operation of the underlying plaintext data, making the computation over encrypted data a very hard problem. On the other hand, the operational details inside the cloud are not transparent enough to customers. As a result, there do exist various motivations for cloud server to behave unfaithfully and to return incorrect results, i.e., they may behave beyond the classical semi honest model.

Existing System:

Despite the tremendous benefits, outsourcing computation to the commercial public cloud is also depriving customers’ direct control over the systems that consume and produce their data during the computation, which inevitably brings in new security concerns and challenges towards this promising computing model. On the one hand, the outsourced computation workloads often contain sensitive information, such as the business financial records, proprietary research data, or personally identifiable health information etc.

To combat against unauthorized information leakage, sensitive data have to be encrypted before outsourcing. so as to provide end to- end data confidentiality assurance in the cloud and beyond. However, ordinary data encryption techniques in essence prevent cloud from performing any meaningful operation of the underlying plaintext data, making the computation over encrypted data a very hard problem. On the other hand, the operational details inside the cloud are not transparent enough to customers. As a result, there do exist various motivations for cloud server to behave unfaithfully and to return incorrect results, i.e., they may behave beyond the classical semi hones model. For example, for the computations that require a large amount of computing resources, there are huge financial incentives for the cloud to be “lazy” if the customers cannot tell the correctness of the output. Besides, possible software bugs, hardware failures, or even outsider attacks might also affect the quality of the computed results.

Thus, we argue that the cloud is intrinsically not secure from the viewpoint of customers. Without providing a mechanism for secure computation outsourcing, i.e., to protect the sensitive input and output information of the workloads and to validate the integrity of the computation result, it would be hard to expect cloud customers to turn over control of their workloads from local machines to cloud solely based on its economic savings and resource flexibility. For practical consideration, such a design should further ensure that customers perform fewer amounts of operations following the mechanism than completing the computations by themselves directly. Otherwise, there is no point for customers to seek help from cloud. Recent researches in both the cryptography and the theoretical computer science communities have made steady advances in “secure outsourcing expensive computations”

Proposed System:

On the one hand, the outsourced computation workloads often contain sensitive information, such as the business financial records, proprietary research data, or personally identifiable health information etc. To combat against unauthorized information leakage, sensitive data have to be encrypted before outsourcing so as to provide end to- end data confidentiality assurance in the cloud and beyond. However, ordinary data encryption techniques in essence prevent cloud from performing any meaningful operation of the underlying plaintext data, making the computation over encrypted data a very hard problem. On the other hand, the operational details inside the cloud are not transparent enough to customers. As a result, there do exist various motivations for cloud server to behave unfaithfully and to return incorrect results, i.e., they may behave beyond the classical semi honest model.

Fully homomorphic encryption (FHE) scheme, a general result of secure computation outsourcing has been shown viable in theory, where the computation is represented by an encrypted combinational Boolean circuit that allows to be evaluated with encrypted private inputs.

System Architecture:

Algorithm Used:

KeyGen(1k) → {K}.

This is a randomized key generation algorithm which takes a system security parameter k, and returns a secret key K that is used later by customer to encrypt the target LP problem.

 ProbEnc(K,_) → {_K}.

 This algorithm encrypts the input tuple _ into _K with the secret key K. According to problem transformation, the encrypted input _K has the same form as _, and thus defines the problem to be solved in the cloud.

 ProofGen(_K) → {(y, 􀀀)}.

This algorithm augments a generic solver that solves the problem _K to produce

both the output y and a proof 􀀀. The output y later decrypts to x, and 􀀀 is used later by the customer to verify the correctness of y or x.

 ResultDec(K,_, y, 􀀀) → {x,⊥}.

 This algorithm may choose to verify either y or x via the proof 􀀀. In any case, a correct output x is produced by decrypting y using the secret K. The algorithm outputs ⊥ when the validation fails, indicating the cloud server was not performing the computation faithfully.

Modules:

1.   Mechanism Design Framework

2.   Basic Techniques

3.   Enhanced Techniques via Affine Mapping

4.   Result Verification

Modules Description:

Mechanism Design Framework:

We propose to apply problem transformation for mechanism design. The general framework is adopted from a generic approach, while our instantiation is completely different and novel. In this framework, the process on cloud server can be represented by algorithm ProofGen and the process on customer can be organized into three algorithms (KeyGen, ProbEnc, ResultDec). These four algorithms are summarized below and will be instantiated later.

• KeyGen(1k) → {K}. This is a randomized key generation algorithm which takes a system security parameter k, and returns a secret key K that is used later by customer to encrypt the target LP problem.

• ProbEnc(K,_) → {_K}. This algorithm encrypts the input tuple _ into _K with the secret key K. According to problem transformation, the encrypted input _K has the same form as _, and thus defines the problem to be solved in the cloud.

• ProofGen(_K) → {(y, 􀀀)}. This algorithm augments a generic solver that solves the problem _K to produce both the output y and a proof 􀀀. The output y later

decrypts to x, and 􀀀 is used later by the customer to verify the correctness of y or x.

• ResultDec(K,_, y, 􀀀) → {x,⊥}. This algorithm may choose to verify either y or x via the proof 􀀀. In any case, a correct output x is produced by decrypting y using the secret K. The algorithm outputs ⊥ when the validation fails, indicating the cloud server was not performing the computation faithfully.

Basic Techniques

Before presenting the details of our proposed mechanism, we study in this subsection a few basic techniques and show that the input encryption based on these techniques along may result in an unsatisfactory mechanism. However, the analysis will give insights on how a stronger mechanism should be designed. Note that to simplify the presentation, we assume that the cloud server honestly performs the computation, and defer the discussion on soundness to a later section.

1) Hiding equality constraints (A, b): First of all, a randomly generated m × m non-singular matrix Q can be part of the secret key K. The customer can apply the matrix to Eq. (2) for the following constraints transformation, Ax = b ⇒ A′x = b′

where A′ = QA and b′ = Qb.

Enhanced Techniques via Affine Mapping

To enhance the security strength of LP outsourcing, we must be able to change the feasible region of original LP and at the same time hide output vector x during the problem input encryption. We propose to encrypt the feasible region of _ by applying an affine mapping on the decision variables x. This design principle is based on the following observation: ideally, if we can arbitrarily transform the feasible area of problem _ from one vector space to another and keep the mapping

function as the secret key, there is no way for cloud server to learn the original feasible area information. Further, such a linear mapping also serves the important purpose of output hiding.

Result Verification

Till now, we have been assuming the server is honestly performing the computation, while being interested learning information of original LP problem. However, such semihonest model is not strong enough to capture the adversary behaviors in the real world. In many cases, especially when the computation on the cloud requires a huge amount of computing resources, there exists strong financial incentives for the cloud server to be “lazy”. They might either be not willing to commit service-level-agreed computing resources to save cost, or even be malicious just to sabotage any following up computation at the customers. Since the cloud server promises to solve the LP problem _K = (A′,B′, b′, c′), we propose to solve the result verification problem by designing a method to verify the correctness of the solution y of _K. The soundness condition would be a corollary thereafter when we present the whole mechanism in the next section. Note that

in our design, the workload required for customers on the result verification is substantially cheaper than solving the LP problem on their own, which ensures the great computation savings for secure LP outsourcing.

The LP problem does not necessarily have an optimal solution. There are three cases as follows.

• Normal: There is an optimal solution with finite objective value.

• Infeasible: The constraints cannot be all satisfied at the same time.

• Unbounded: For the standard form in Eq. (1), the objective function can be arbitrarily small while the constraints are all satisfied.

System Specification:

Hardware System Requirement:

Processor                                 -    Pentium –III

Speed                                      -    1.1 Ghz

RAM                                       -    256  MB(min)

Hard Disk                                -   20 GB

Floppy Drive                           -    1.44 MB

Key Board                               -    Standard Windows Keyboard

Mouse                                     -    Two or Three Button Mouse

Monitor                                   -    SVGA

S/W System Requirement

v   Operating System          :   Windows 95/98/2000/NT4.0.

v   Application  Server       :   Tomcat6.0

v   Front End                     :   HTML, Java.

v   Scripts                                     :   JavaScript.

v   Server side Script         :   Java Server Pages.

v   Database                                 :   Mysql.

v   Database Connectivity   :   JDBC.

REFERENCE:

Cong Wang, Kui Ren and Jia Wang, “Secure and Practical Outsourcing of Linear Programming in Cloud Computing”, IEEE INFOCOM 2011.