Aim:

          The main aim of this project secures the query accessing and reduces the server load.

Synopsys:

        Clients of outsourced databases need Query Authentication (QA) guaranteeing the integrity and authenticity of query results returned by potentially compromised providers. Prior work provides QA assurances for a limited class of queries by deploying several software based cryptographic constructs. The constructs are often designed assuming read-only or infrequently updated databases. For dynamic datasets, the data owner is required to perform all updates on behalf of clients. Hence, for concurrent updates by multiple clients, such as for OLTP workloads, existing QA solutions are inefficient. We present ConcurDB, a concurrent QA scheme that enables simultaneous updates by multiple clients. To realize concurrent QA, we have designed several new mechanisms. Firstly, we identify and use an important relationship between QA and memory checking to decouple query execution and verification. We allow clients to execute transactions concurrently and perform verifications in parallel using an offline memory checking based protocol. Then, to extend QA to a multi-client scenario, we design new protocols that enable clients to securely exchange a small set of authentication data even when using the untrusted provider as a communication hub. Finally, we overcome provider-side replay attacks. Using ConcurDB, we provide and evaluate concurrent QA for the full TPC-C benchmark. For updates, ConcurDB shows a 4x performance increase over existing solutions.

Proposed System:

        Concurrent Query Authentication for outsourced databases consists of one user namely client, and two servers namely oAuth server and Resource server. The client will register and the registration details of the client will be maintained by the oAuth server. While login, the oAuth will generate the dynamic token which will be valid only for 10 minutes. After 10 minutes, the token will get changed when the client logins. It allows limited access to the user's data and allows accessing when authorization token expires. It has ability to share data for users without having to release personal information. The client will send a query to the resource server. Then, the resource will send the client's token to the oAuth server to verify whether the token is validated and whether it was from the validated user. If the token is validated by the oAuth server, the resource server will send the query response to the client server.

Algorithm:

• MD5