Module
§ Overview
§ User Authentication
§ Illegal
search detection
§ Encryption
and Decryption
§ Trapdoor
Generation
§ Architecture
Module
§ Privacy
Preserving Function
Overview:
Now we
give an example to illustrate the main idea of the user authentication protocol
the detailed protocol is elaborated in the following subsections . Assume Alice wants to be authenticated by the
administration server, so she starts a conversation with the server. The server
then authenticates the contents of the conversation. If the contents are authenticated, both Alice
and the server will generate the initial secret key according to the
conversation contents. After the initialization, to be authenticated
successfully, Alice has to provide the
historical data of their conversations. If the authentication is successful. both
Alice and the Administration server will change their secret keys according the
contents of the conversation. In this way, the secret keys keep changing
dynamically.
User Authentication:
Request
counter field records the number of search requests that the data user has
submitted. The last request time field asks the data user to provide the
historical data of his previous request time. The personally identifiable data
(e.g., passport number, telephone number) field is used to identify a specific
data user, while
the random number and CRC field are further used to check whether the
authentication data has been tampered with. The key point of a successful
authentication is to provide both the dynamically changing secret keys and the
historical data of the corresponding data user. Let
denotes the secret key shared between administration server and the data
user after instances of search requests, and denotes the authentication data
for the request.
Illegal Search Detection:
In our scheme, the authentication process is
protected by the dynamic secret key and the historical information. We assume
that an attacker has successfully eavesdropped the secret key of. Then he has
to construct the authentication data; if the attacker has not Successfully eavesdropped the historical
data, e.g., the request counter, The last
request time, he cannot construct the correct authentication data Therefore this illegal action will soon be
detected by the administration server. Further, if the attacker has successfully
eavesdropped all data The attacker can correctly construct the
authentication data and pretend himself to be without being detected by the
administration server. However, once the legal data user performs his search, since the secret key on the administration
server side has changed, there will be contradictory secret keys between the
administration server and the legal data user. Therefore, the data user and
administration server will soon detect this illegal action.
Encryption and Decryption:
Numerous
data owners are often involved in practical cloud applications. For privacy
concerns, they would be reluctant to share secret keys with others. Instead, they
prefer to use their own secret keys to encrypt their sensitive data (keywords,
files). When keywords of different data owners are encrypted with different secret
keys, the coming question is how to locate different-key encrypted keywords
among multiple data owners. In this section, to enable secure, efficient and
convenient searches over encrypted cloud data owned by multiple data owners, we
systematically design schemes to achieve the following three requirements
First, different data owners use different secret keys to encrypt their keywords.
Second, authenticated encrypted. data users can generate their trapdoors
without knowing these
secret keys. Third, upon receiving trapdoors, the cloud server can find the
corresponding keywords from different data owners’ encrypted keywords without knowing the actual value of keywords or
trapdoors.
Trapdoor Generation:
To make
the data users generate trapdoors securely, conveniently and efficiently, our
proposed scheme should satisfy two main conditions. First, the data user does
not need to ask a large amount of data owners for secret keys to generate
trapdoors. Second, for the same keyword, the trapdoor
generated each time should be different. To meet this condition, the trapdoor
generation is conducted in two steps
First, the data user generates trapdoors based
on his search keyword and a random number. Second, the administration server
re-encrypts the trapdoors for the authenticated
data user.
Architecture Module:
Privacy Preserving Function:
To rank
the relevance score while preserving its privacy, the proposed function should
satisfy the following conditions. This
function should preserve the order of data, as this helps the cloud server determine which
file is more relevant to a certain keyword, according to the encoded relevance
scores. This function should not be
revealed by the cloud server so that
cloud server can make comparisons on encoded relevance scores without knowing
their actual values. Different data owners should have different functions such
that revealing the encoded value of a data owner would not lead to the leakage
of encoded values of other data owners. In order
to satisfy condition we introduce a data processing part which preserves the
order of x. To satisfy condition we introduce a disturbing part which
helps prevent the cloud server from revealing this function. To satisfy
condition we use to process the ID of data owners. So this function belongs to
the following function family.
SYSTEM ANALYSIS
EXISTING SYSTEM
We observe that, PRMSM
spends more time for searching. The fundamental reason is that, the pairing
operation used in PRMSM needs more time. As we can see from Fig and Fig. the
more keywords existing in the cloud server, the more time is required for
pairing operation. Confirms that when the number of keywords
stored on the cloud server remains a constant, PRMSM will not increase even if
the number of files increases. Though PRMSM spends relatively more time, this
observation also confirms that the searching operation should be outsourced to
the cloud server.
PROPOSED SYSTEM
The earliest attempt of searchable encryption
was made by Song et al. In they propose to encrypt each word in a file
independently and allow the server to find whether a single queried keyword is
contained in the file without knowing the exact word. This proposal is more of theoretic interests
because of high computational costs. propose
building a keyword index for each file and using Bloom filter to accelerate the
search Curtmola et al. propose building
indices for each keyword, and use hash tables as an alternative approach
to searchable encryption. The first public key scheme for keyword search
over encrypted data is presented in and further enrich the search
functionalities of searchable encryption by proposing schemes for conjunctive
keyword search. The searchable encryption cares mostly about single keyword
search or boolean keyword search. Extending these techniques for ranked
multi-keyword search will incur heavy computation and storage costs.
Advantage:
Multi-keyword searching with ranking function. Execution Time consumption is very less. File length (size) and Execution time can be
seen. Multi-keyword
Ranking can be seen by using chart
ALGORITHMS
The state-of-art text feature extraction
technique TFIDF. Index Tree-based Search Algorithm Chart represents the ranking of the Multi-keyword searched by the user Algorithms. Secure
keyword search in cloud computing, and order preserving encryption
SYSTEM SPECIFICATION
Hardware Requirements
•
System : Pentium IV 2.4 GHz.
•
Hard Disk
: 40 GB.
•
Floppy Drive :
1.44 Mb.
•
Monitor
: 14’ Colour Monitor.
•
Mouse : Optical Mouse.
•
Ram :
512 Mb.
Software Requirements
•
Operating
system : Windows 7 Ultimate.
•
Coding
Language : ASP.Net with C#
•
Front-End : Visual Studio 2010 Professional.
•
Data Base : SQL Server 2008.
Comments
Post a Comment