Major Project Sample Documentation

A Major Project Report on
“Privacy-Preserving Electronic Ticket Scheme with Attribute-Based Credentials”

Submitted to the
JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD
In partial fulfillment of the requirement for the award of the degree of
BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
BY
BODIGE BHARATHWAJ GOUD (18WJ1A0557)

AMANAGANTI HEMANTH BABU (18WJ1A0516)
BORRA BHARATH KUMAR (18WJ1A0560)
Under the Esteemed Guidance Of

Dr. J. Rajeshwar
Professor & HOD-CSE
GURU NANAK INSTITUTIONS TECHNICAL CAMPUS (AUTONOMOUS)

School of Engineering & Technology
Ibrahimpatnam, R.R District- 501506
2021-2022
Date : 20-06-2022
Department of Computer Science and Engineering
CERTIFICATE
This is to certify that this project report entitled “PRIVACY-PRESERVING

ELECTRONIC TICKET SCHEME WITH ATTIBUTE-BASED CREDENTIALS”
by BODIGE BHARATHWAJ GOUD (18WJ1A0557), AMANAGANTI HEMANTH
BABU (18WJ1A0516), BORRA BHARATH KUMAR (18WJ1A0560) was submitted
in partial fulfillment of the requirements for the degree of Bachelor of Technology in
Computer Science and Engineering of the Jawaharlal Nehru Technological
University Hyderabad during the academic year 2021-2022, is a bonafide record of
work carried out under our guidance and supervision.
_________________ _________________________ _________________
INTERNAL GUIDE PROJECT CO-ORDINATOR HOD CSE
Dr. J. Rajeshwar Mr. B. Samirana Acharya Dr. J. Rajeshwar
_________________
EXTERNAL EXAMINER
Computer Science and Engineering
BODIGE BHARATHWAJ GOUD 18WJ1A0557
AMANAGANTI HEMANTH BABU 18WJ1A0516
BORRA BHARATH KUMAR 18WJ1A0560
JAVA
“PRIVACY-PRESERVING ELECTRONIC
TICKET SCHEME WITH ATTRIBUTE-BASED CREDENTIALS”
RAM INNOVATIVE INFOTECH

ACKNOWLEDGEMENT
We wish to express our sincere thanks to Dr. RishiSayal, Associate Director, GNITC
for providing us with the conducive environment for carrying through our academic
schedules and Project with ease.
We would like to say our sincere thanks to Dr. J. Rajeshwar, Professor & Head,
Department of CSE, GNITC for providing seamless support and right suggestions are
given in the development of the project.
We would like to say our sincere thanks to Mr. B. Samirana Acharya, Asst. Professor,
Department of CSE, Project Coordinator, for providing seamless support and right
suggestions are given in the development of the project.
We have been truly blessed to have a wonderful internal guide Dr. J. Rajeshwar,
Professor & Head, Department of CSE, GNITC for guiding us to explore the
ramification of our work and we express our sincere gratitude towards him for leading me
through the completion of Project.
Finally, we would like to thank our family members for their moral support and
encouragement to achieve goals.
BODIGE BHARATHWAJ GOUD (18WJ1A0557)
AMANAGANTI HEMANTH BABU (18WJ1A0516)
BORRA BHARATH KUMAR (18WJ1A0560)

Privacy-Preserving Electronic Ticket Scheme with
Attribute-Based Credentials
ABSTRACT
Users accessing services are often required to provide personal information, for
example, age, profession and location, in order to satisfy access polices. This personal
information is evident in the application of e-ticketing where discounted access is granted to
visitor attractions or transport services if users satisfy policies related to their age or disability or
other defined over attributes. We propose a privacy-preserving electronic ticket scheme using
attribute-based credentials to protect users’ privacy. The benefit of our scheme is that the
attributes of a user are certified by a trusted third party so that the scheme can provide assurances
to a seller that a user’s attributes are valid. The scheme makes the following contributions: (1)
users can buy different tickets from ticket sellers without releasing their exact attributes; (2) two
tickets of the same user cannot be linked; (3) a ticket cannot be transferred to another user; (4) a
ticket cannot be double spent. The novelty of our scheme is to enable users to convince ticket
sellers that their attributes satisfy the ticket policies and buy discounted tickets anonymously.
This is a step towards identifying an e-ticketing scheme that captures user privacy requirements
in transport services. The security of our scheme is proved and reduced to a well-known
complexity assumption. The scheme is also implemented and its performance is empirically
evaluated.
I
TABLE OF CONTENTS
CHAPTER NO. TITLE PAGE NO.

ABSTRACT I
LIST OF FIGURES V
LIST OF NOTATIONS VII
LIST OF ABBREVIATION X
CHAPTER 1: INTRODUCTION
1.1 GENERAL 1
1.2 SCOPE OF THE PROJECT 3
1.3 OBJECTIVE 3
1.4 PROBLEM STATEMENT 4

1.
1.5 EXISTING SYSTEM 5
1.5.1 EXISTING SYSTEM DISADVANTAGES 5
1.5.2 LITERATURE SURVEY 6
1.6 PROPOSED SYSTEM 12
1.6.1 PROPOSED SYSTEM ADVANTAGES 13
CHAPTER 2: PROJECT DESCRIPTION
2.1 GENERAL 14
2.2 METHODOLOGIES 14
2. 14
2.2.1 MODULES NAME
2.2.2 MODULES EXPLANATION 15
2.2.3 GIVEN INPUT AND EXPECTED OUTPUT 20
2.3 TECHNIQUE OR ALGORITHM 21
CHAPTER 3: REQUIREMENTS
3.1 GENERAL 22
3. 22
3.2 HARDWARE REQUIREMENTS
3.3 SOFTWARE REQUIREMENTS 23
3.4 FUNCTIONAL SPECIFICATION 24
II
3.5 NON-FUNCTIONAL SPECIFICATION 25
CHAPTER 4: SYSTEM DESIGN
4.1 GENERAL 26
4.1.1 USE CASE DIAGRAM 27
4.1.2 CLASS DIAGRAM 28
4.1.3 OBJECT DIAGRAM 29
4.1.4 STATE DIAGRAM 30
4.1.5 SEQUENCED DIAGRAM 31

4.
4.1.6 COLLABORATION DIAGRAM 32
4.1.7 ACTIVITY DIAGRAM 33
4.1.8 COMPONENT DIAGRAM 34
4.1.9 E-R DIAGRAM 35
4.1.01 DATA FLOW DIAGRAM 36
4.1.11 DEPLOYMENT DIAGRAM 38
4.2 SYSTEM ARCHITECTURE 39
CHAPTER 5: SOFTWARE SPECIFICATION
5.1 GENERAL 40
5.2 FEATURES OF JAVA 40
5.2.1 THE JAVA FRAMEWORK 40

5. 41
5.2.2 OBJECTIVE OF JAVA
5.2.3 JAVA SWING OVERVIEW 42
5.2.4 EVOLUTION OF COLLECTION 43
FRAMEWORK 46
5.3 CONCLUSION
CHAPTER 6: IMPLEMENTATION
6.1 GENERAL 47
6.
6.2 IMPLEMENTATION 47
III
CHAPTER 7: SNAPSHOTS
7. 56
7.1 GENERAL
56
7.2 VARIOUS SNAPSHOTS
CHAPTER 8: SOFTWARE TESTING
8.1 GENERAL 63
63
8.2 DEVELOPING METHODOLOGIES
63
8.3 TYPES OF TESTING
8.3.1 UNIT TESTING 63

8.
8.3.2 FUNCTIONAL TEST 64
8.3.3 SYSTEM TEST 64
8.3.4 PERFORMANCE TEST 64
8.3.5 INTEGRATION TESTING 64
8.3.6 ACCEPTANCE TESTING 65
8.3.7 BUILD THE TEST PLAN 65
CHAPTER 9: APPLICATIONS AND FUTURE

ENHANCEMENT
9.
9.1 GENERAL 67
9.2 FUTURE ENHANCEMENTS 67
CHAPTER 10: CONCLUSION & REFERENCES

10. 10.1 CONCLUSION 68
69
10.2 REFERENCES
IV
LIST OF FIGURES
FIGURE NO NAME OF THE FIGURE PAGE NO.
2.2.2 Module Diagram 17
4.1.1 Use case Diagram 27
4.1.2 Class Diagram 28
4.1.3 Object Diagram 29
4.1.4 State Diagram 30
4.1.5 Sequence Diagram 31
4.1.6 Collaboration Diagram 32
4.1.7 Activity Diagram 33
4.1.8 Component Diagram 34
4.1.9 Data flow Diagram 35
4.1.10 E-R Diagram 36
4.1.11 Deployment Diagram 38
4.2 System Architecture 39
7.2.1 Registration Page 56
7.2.2 Creator Login Page 57
7.2.3 Creator Home Page 57
7.2.4 Creator Token Request 58
7.2.5 Trustee Login Page 58
7.2.6 Trustee Home Page 59
7.2.7 Cloud Server Login Page 59
V
7.2.8 Cloud Server Home Page 60
7.2.9 File Upload Page 60
7.2.10 File Viewing Page 61
7.2.11 Reader Actions 61
7.2.12 Writer Actions 62
VI
LIST OF NOTATIONS
S.NO NAME NOTATION DESCRIPTION
Class Name
+ public Represents a collection of
-attribute- similar entities grouped
1. Class -private attribute
together.
+operation
Class A NAME Class B Associations represents
2. Association static relationships between

classes. Roles represents
the way the two classes see
each other.
3. Actor It aggregates several

classes into a single classes
4. ClassAB
Class Class B
A Interaction between the
Aggregation system and external
environment
5. Used for additional process

Relation
(uses) Uses communication.
VII
Extends relationship is
used when one use case is
Relation extends
6. similar to another use case
(extends) but does a bit more.
Communication between
7. Communication
various use cases.
State
8. State State of the process.
9. Initial State Initial state of the object
Final state of the object

10. Final state
Represents various control

11. Control flow
flow between the states.
Represents decision
making process from a
12. Decision box constraint
Interact ion between the

13. Use Case Use Case system and external
environment.
VIII
Represents physical
modules which is a
14. Component collection of components.
Represents physical
modules which are a
15. Node collection of components.
A circle in DFD represents

Data a state or process which has
16.
Process/State been triggered due to some
event or action.
Represents external entities

such as keyboard, sensors,
17. External entity etc.
Represents communication
that occurs between
18. Transition processes.
Represents the vertical

dimensions that the object
19. Object Lifeline communications.
Represents the message

20. Message Message
exchanged.
IX
LIST OF ABBREVATION
S.NO ABBREVATION EXPANSION
1. DB DataBase
2. JVM Java Virtual Machine
3. JSP Java Server Page
4. CB Collective Behavior
5. RSSS Ramp secret sharing scheme
6. JRE Java Runtime Environment
X
CHAPTER 1
INTRODUCTION
1.1 GENERAL
Due to their flexibility and portability, electronic ticket (eticket) systems have been
extensively investigated by both industry , and the academic research communities. E-tickets are
attractive to transport operators as well as customers because they can reduce paper costs (tickets
can be stored on a hand-held device) and improve customer experience (tickets can be purchased
and delivered any time and anywhere). However, the use of e-tickets also raises many questions
regarding the privacy of its users due to the possibility of linking different e-ticket transactions to
a particular user –in contrast to anonymous paper-based tickets– and thus potentially revealing
private information, e.g. working patterns, likely places of work, etc.
Customers are increasingly aware of privacy issues especially in light of the newly
introduced general data protection regulations (GDPR). One way to address this is through
anonymous authentication which enables users to authenticate without revealing their identities
and this approach has been used to protect a user’s privacy in many privacy-preserving e-ticket
schemes. However, many of these schemes were not formally proven to be secure. Notable
exceptions are those proposed by Arfaoui et al. and Rupp et al.. Arfaoui et al. formally defined
their security models for e-ticket schemes, including unforgeability, unlinkability and non-
repudiation, but the authors only provided a very high-level proof. Rupp et al. formalised their
security models of privacy preserving pre-payments with refunds schemes including
transportation authority security and user privacy but the security proof of their scheme was
again at a high level. Another requirement of a realistic e-ticket systems is the support for
different tickets based on a user’s attributes (e.g. age, location, disability, profession, etc.), i.e. to
offer discounts for, say, students or disabled passengers. However, if not implemented carefully,
there is a risk that such a ticket system reveals more information about a user than necessary
when purchasing or validating tickets. For example, a student buying a discounted student ticket
may end up revealing the university at which she is enrolled and, depending on the student card,
even her birthday neither of which is relevant to obtaining the student discount. The minimum
1
proof required is that she can demonstrate that sheis a legitimate student. Similarly, a disabled
passenger might need to reveal more details about his disability to the ticket seller or verifier
than necessary for purchasing or verifying a ticket. Gudymenko and Kerschbaum et al. addressed
this issue, but their schemes were not proven formally.
Transport operators are naturally concerned about fraudulent use of e-tickets due to the
ease with which they can be copied. Double spend or more generally overspend detection, i.e.
the process of determining whether a ticket has been used too many times, is therefore also an
important feature that an e-ticket scheme should support.
2
1.2 SCOPE OF THE PROJECT
The novelty of our scheme is to enable users to convince ticket sellers that their attributes
satisfy the ticket policies and buy discounted tickets anonymously. This is a step towards
identifying an e-ticketing scheme that captures user privacy requirements in transport services.
The security of our scheme is proved and reduced to a well-known complexity assumption. The
scheme is also implemented and its performance is empirically evaluated.
1.3 OBJECTIVE
To address the above requirements, this paper proposes a new privacy-preserving e-ticket
scheme using attribute-based credentials which supports issuing different tickets depending on a
user’s attributes. Our scheme protects an honest user’s privacy while allowing for the
deanonymization of users who try to use their tickets more than once (double spend detection). It
is also a general e-ticket system and can be used in various application scenarios including:
 Mobility as a service transport tickets (e.g. rail, bus, etc.) where age, disability, profession,
affiliation, etc. might determine the prices of tickets;
 One-off token for Internet services (e.g. print service, download service for multimedia,
etc.) where age, affiliation, membership might determine the service/access level;
 E-Voting where age, nationality, voting district, etc. might determine the voting ballot
that should be issued;Event Tickets (e.g. concert, tourist attractions, conferences, etc.)
where age, affiliation, disability, etc. might determine the ticket price/access rights.
3
1.4 PROBLEM STATEMENT
This personal information is evident in the application of e-ticketing where discounted access
is granted to visitor attractions or transport services if users satisfy policies related to their age or
disability or other defined over attributes. In this paper, we propose a new attribute-based e-ticket
scheme.
The main contributions of our scheme are:
1) Attribute-based Ticketing: users can buy different tickets depending on their certified
attributes without releasing their exact details;
2) Unlinkability: two tickets of the same user cannot been linked;
3) Untransferability: a ticket can only be used by the ticket holder and cannot be
transferred to another user;
4) Double Spend Detection: a ticket cannot be double spent and the identities of users who
try to double spend tickets can be revealed.
The novelty of our scheme is to enable users to convince ticket sellers that their attributes
satisfy the ticket policies and buy discounted tickets anonymously. Our scheme thus offers a
natural as well as flexible way of representing user attributes, e.g. to obtain an age based
discount, a user would expect to prove that her age is in a certain range, while for a disability
discount, she would want to demonstrate her impairment is contained within the set of
recognised disabilities. Furthermore, a user’s attributes are additionally certified by a trusted
third party thereby allowing a user’s claimed attributes to also be verified. The theoretical
contribution is that the security of the proposed scheme is formally proven and reduced to a
wellknown complexity assumption. The scheme is also implemented and performance timings
are given.
4
1.5 EXISTING SYSTEM
 We now compare our scheme with a number of other schemes. In these schemes, blind
signatures , group signatures , anonymous credentials and pseudonyms were used to
protect user privacy.
 A group signature enables a user to sign a message on behalf of the group without
exposing his identity, while the group manager can release the identity of the real signer.
 In an anonymous credential scheme, a user can prove to a verifier that she has obtained a
credential without releasing any other information.
1.5.1 EXISTING SYSTEM DISADVANTAGES
 It cannot have a security.

 A user has a directly login without authentication.
 The existing system unable to avoid the server.
 Itis not used to protect user privacy.
5
1.5.2 LITERATURE SURVEY
Title:Privacy-preserving electronic ticket scheme with attribute-based Credentials
Year: 2018
Author: J. Han, L. Chen, S. Schneider, H. Treharne, and S. Wesemeyer
Description:Users accessing services are often required to provide personal information, for
example, age, profession and location, in order to satisfy access polices. This personal
information is evident in the application of e-ticketing where discounted access is granted to
visitor attractions or transport services if users satisfy policies related to their age or disability or
other defined over attributes. We propose a privacy-preserving electronic ticket scheme using
attribute-based credentials to protect users' privacy. The benefit of our scheme is that the
attributes of a user are certified by a trusted third party so that the scheme can provide assurances
to a seller that a user's attributes are valid. The scheme makes the following contributions: (1)
users can buy different tickets from ticket sellers without releasing their exact attributes; (2) two
tickets of the same user cannot be linked; (3) a ticket cannot be transferred to another user; (4) a
ticket cannot be double spent. The novelty of our scheme is to enable users to convince ticket
sellers that their attributes satisfy the ticket policies and buy discounted tickets anonymously.
This is a step towards identifying an e-ticketing scheme that captures user privacy requirements
in transport services. The security of our scheme is proved and reduced to a well-known
complexity assumption. The scheme is also implemented and its performance is empirically
evaluated.
6
Title:On the power of rewinding simulators in functional encryption
Year:2017
Author:A. D. Caro and V. Iovino
Description:In a seminal work, Boneh, Sahai and Waters (BSW) [TCC'11] showed that for
functional encryption the indistinguishability notion of security (IND-Security) is weaker than
simulation-based security (SIM-Security), and that SIM-Security is in general impossible to
achieve. This has opened up the door to a plethora of papers showing feasibility and new
impossibility results. Nevertheless, the quest for better definitions that (1) overcome the
limitations of IND-Security and (2) the known impossibility results, is still open. In this work,
we explore the benefits and the limits of using efficient rewinding black-box simulators to argue
security. To do so, we introduce a new simulation-based security definition, that we call
rewinding simulation-based security (RSIM-Security), that is weaker than the previous ones but
it is still sufficiently strong to not meet pathological schemes as it is the case for IND-Security
(that is implied by the RSIM). This is achieved by retaining a strong simulation-based flavour
but adding more rewinding power to the simulator having care to guarantee that it can not learn
more than what the adversary would learn in any run of the experiment. What we found is that
for RSIM the BSW impossibility result does not hold and that IND-Security is equivalent to
RSIM-Security for attribute-based encryption in the standard model. Nevertheless, we prove that
there is a setting where rewinding simulators are of no help. The adversary can put in place a
strategy that forces the simulator to rewind continuously.
7
Title:Verifiable computation over large database with incremental updates
Year:2016
Author: X. Chen, J. Li, J. Weng, J. Ma, and W. Lou.
Description:The notion of verifiable database (VDB) enables a resource-constrained client to

securely outsource a very large database to an untrusted server so that it could later retrieve a
database record and update a record by assigning a new value. Also, any attempt by the server to
tamper with the data will be detected by the client. When the database undergoes frequent while
small modifications, the client must re-compute and update the encrypted version (ciphertext) on
the server at all times. For very large data, it is extremely expensive for the resources-constrained
client to perform both operations from scratch. In this paper, we formalize the notion of
verifiable database with incremental updates (Inc-VDB). Besides, we propose a general Inc-
VDB framework by incorporating the primitive of vector commitment and the encrypt-then-
incremental MAC mode of encryption. We also present a concrete Inc-VDB scheme based on
the computational Diffie-Hellman (CDH) assumption. Furthermore, we prove that our
construction can achieve the desired security properties.
8
Title:Privacy-preserving public transport ticketing system
Year: 2015
Author: M. Milutinovic, K. Decroix, V. Naessens, and B. D. Decker.
Description:The public transport ticketing systems are undergoing significant changes in recent
years. The tickets can now be issued and presented in digital form, significantly improving the
user experience. The digital data is also used to improve the services’ efficiency. Travelling
patterns and route occupancy can be analysed to adjust the frequency and coverage of the service.
However, data recorded by the providers extends the information that is needed for simple
analysis. The travel passes that are issued usually contain unique identifiers, allowing to trace the
movement of users, which can even be linked to their identities. In order to tackle these privacy
issues, we propose a novel, privacy-preserving ticketing system, based on a scheme for issuing
and redemption of unlinkable certified tokens. The design also allows offering advanced services,
such as reduction plans or monthly passes, without introducing privacy concerns. Even though
the travellers’ actions cannot be linked, the service providers are given assurances against
possible misuse, and are able to control the usage of the issued products. Additionally,
experimental evaluation shows that the system performance is adequate for practical applications.
9
Title:A practical set-membership proof for privacy-preserving NFC mobile ticketing
Year: 2015
Author: G. Arfaoui, J.-F. Lalande, J. Traore, N. Desmoulins, P. Berthome, and S. Gharout,
Description:
To ensure the privacy of users in transport systems, researchers are working on new protocols
providing the best security guarantees while respecting functional requirements of transport
operators. In this paper, we design a secure NFC m-ticketing protocol for public transport that
preserves users' anonymity and prevents transport operators from tracing their customers' trips.
To this end, we introduce a new practical set-membership proof that does not require provers nor
verifiers (but in a specific scenario for verifiers) to perform pairing computations. It is therefore
particularly suitable for our (ticketing) setting where provers hold SIM/UICC cards that do not
support such costly computations. We also propose several optimizations of Boneh-Boyen type
signature schemes, which are of independent interest, increasing their performance and
efficiency during NFC transactions. Our m-ticketing protocol offers greater flexibility compared
to previous solutions as it enables the post-payment and the off-line validation of m-tickets. By
implementing a prototype using a standard NFC SIM card, we show that it fulfils the stringent
functional requirement imposed by transport operators whilst using strong security parameters.
In particular, a validation can be completed in 184.25 ms when the mobile is switched on, and in
266.52 ms when the mobile is switched off or its battery is flat.
10
Title:Cryptographic theory meets practice: Efficient and privacy-preserving payments for public
transport
Year: 2015
Author: A. Rupp, F. Baldimtsi, G. Hinterwalder, and C. Paar
Description:We propose a new lightweight cryptographic payment scheme for transit systems,
called P4R (Privacy- Preserving Pre-Payments with Refunds), which is suitable for low-cost user
devices with limited capabilities. Using P4R, users deposit money to obtain one-show credentials,
where each credential allows the user to make an arbitrary ride on the system. The trip fare is
determined on-the-fly at the end of the trip. If the deposit for the credential exceeds this fare, the
user obtains a refund. Refund values collected over several trips are aggregated in a single token,
thereby saving memory and increasing privacy. Our solution builds on Brands's e-cash scheme to
realize the prepayment system and on Boneh-Lynn-Shacham (BLS) signatures to implement the
refund capabilities. Compared to a Brands-only solution for transportation payment systems,
P4R allows us to minimize the number of coins a user needs to pay for his rides and thus
minimizes the number of expensive withdrawal transactions, as well as storage requirements for
the fairly large coins. Moreover, P4R enables flexible pricing because it allows for exact
payments of arbitrary amounts (within a certain range) using a single fast paying (and refund)
transaction. Fortunately, the mechanisms enabling these features require very little computational
overhead. Choosing contemporary security parameters, we implemented P4R on a prototyping
payment device and show its suitability for future transit payment systems. Estimation results
demonstrate that the data required for 20 rides consume less than 10KB of memory, and the
payment and refund transactions during a ride take less than half a second. We show that
malicious users are not able to cheat the system by receiving a refund that exceeds the overall
deposit minus the overall fare and can be identified during double-spending checks. At the same
time, the system protects the privacy of honest users in that transactions are anonymous (except
for deposits) and trips are unlinkable.
11
Title:New publicly verifiable databases with efficient updates
Year: 2015
Author: X. Chen, J. Li, X. Huang, J. Ma, and W. Lou
Description:The notion of verifiable database (VDB) enables a resource-constrained client to

securely outsource a very large database to an untrusted server so that it could later retrieve a
database record and update it by assigning a new value. Also, any attempt by the server to
tamper with the data will be detected by the client. Very recently, Catalano and Fiore [17]
proposed an elegant framework to build efficient VDB that supports public verifiability from a
new primitive named vector commitment. In this paper, we point out Catalano-Fiore's VDB
framework from vector commitment is vulnerable to the so-called forward automatic update
(FAU) attack. Besides, we propose a new VDB framework from vector commitment based on
the idea of commitment binding. The construction is not only public verifiable but also secure
under the FAU attack. Furthermore, we prove that our construction can achieve the desired
security properties.
1.6 PROPOSED SYSTEM

 To address the above requirements, this paper proposes a new privacy-preserving e-ticket
scheme using attribute-based credentials which supports issuing different tickets
depending on a user’s attributes.
 Our scheme protects an honest user’s privacy while allowing for the deanonymisation of
users who try to use their tickets more than once (double spend detection).
 It is also a general e-ticket system and can be used in various application.
 The novelty of our scheme is to enable users to convince ticket sellers that their attributes
satisfy the ticket policies and buy discounted tickets anonymously.
 This is a step towards identifying an e-ticketing scheme that captures user privacy
requirements in transport services.
 The security of our scheme is proved and reduced to a well-known complexity

assumption.
 The scheme is also implemented and its performance is empirically evaluated.
12
1.6.1 PROPOSED SYSTEM ADVANTAGES
 It can be a used to securely protect personal data.

 A user can only authenticate to an online verifier.
 It is protecting an honest user’s privacy.
 It can be used in various application.
13
CHAPTER 2
PROJECT DESCRIPTION
2.1 GENERAL
Our scheme consists of the following four entities: central authority CA, user U, ticket seller S
and ticket verifier V. CA authenticates U and S, and issues anonymous credentials to them; S
registers to the CA, obtains anonymous credentials from the CA, and sells tickets to U in
accordance with the ticket policies; U registers to the CA, obtains anonymous credentials from
the CA, purchases tickets from S, and proves the possession of tickets to V; V validates the
tickets provided by U and detects whether a ticket is double spent.
2.2 METHODOLOGIES
2.2.1 MODULES NAME:

This project having the following 4modules:
1) User Interface
2) Owner Module
3) Cloud Server
4) Encryption & Decryption Phase
5) Admin
14
2.2.2 MODULE EXPLANATION
 User Interface Design
In this module we design the windows for the project. These windows are used for secure login
for all users. To connect with server user must give their username and password then only they
can able to connect the server. If the user already exits directly can login into the server else user
must register their details such as username, password and Email id, into the server. Server will
create the account for the entire user to maintain upload and download rate. Name will be set as
user id. Logging in is usually used to enter a specific page.
 Owner Module
This is the second module of our project after successful registration is done Owner will
try to access his account which should be activated by the Cloud Server i.e., after the activation
is done by the Cloud Server then only he will be getting a key and his access rights to his
registered mail, through which he can login. After entering to the home page Owner will have
options like File upload, File download, File update ,File Encryption and File Decryption basing
on his access rights he can chose his actions.
 Cloud Server
This is the third module of our project which plays a crucial role in the entire project after
login in to this module the Cloud Server will have two options like (i) Users where he can see
the no of users in the cloud and he can activate them by providing necessary access rights. (ii)
User’s Request where he can give them access for the user requests.
15
 Encryption & Decryption Phase
This is the final module of our project there are three operations done by users 1)Data Upload
2)Re-write the data and 3)Reading the data. if a user tries to upload the file First he will get the
activation from Trustee and then cloud server then only he will upload his data to the cloud. And
data updating also done by writer. More over we are providing strict security constraints to the
data upload, data reading and update data by the user, the data will be stored in the cloud
database in an encrypted format, and when the user down loaded in decryption format so that it
can prevent from malicious cloud owners.
 Admin
In this fourth module of our project after successful login attempt admin will be redirected to his
page where he will be finding the three options like UPLOADS, DOWNLOADS & UPDATES.
On clicking on each hyperlink he will be able to see what operations cloud users are doing in the
cloud.
16
MODULE DIAGRAM:
 User Interface Design
User Database
 Cloud Owner
Owner Login Verify

Upload,
EncryptionAll
Download
And
17
 Cloud Server
Cloud Server Login

Cloud Server Display
Give rights
all all
Checking file
Trustee Login
 Encryption And Decryption Phase
User Login Get Key

Key From
Verify Downlod file
Encrypt And
18
 Admin
Login File upload

Update Result
Admin
19
2.2.3 GIVEN INPUT EXPECTED OUTPUT:
 User Interface
Input: Enter login name and password.
Output: If valid user means directly open the home page otherwise show the error message and
redirect to the registration page.
 Data Owner Module
Input: Data Owner name and Password.
Output: Data Owner Login after that upload files then encrypted data and store into cloud.
 Cloud Server
Input: Cloud server provider name and Password.
Output: Cloud server provider give rights to activated Data Owner and Users.
 Encryption & Decryption Phase
Input: Encryption, Key Generation & Decrypting data

Output: Data Owner when uploaded file data encrypting and key generating also. With help
of key user download & decrypt data.
 Admin
Input: Admin login, verify encryption data key and verify data.
Output: On clicking on each hyperlink he will be able to see what operations cloud users are
doing in the cloud.
20
2.3 TECHNIQUE USED OR ALGORITHM USED
 The Improved NTRU Decryption
NTRU is a patented and open source public-key cryptosystem that uses lattice-based
cryptography to encrypt and decrypt data. It consists of two algorithms: NTRU Decrypt, which is
used for Decryption, and NTRU Sign, which is used for digital signatures.
21
CHAPTER 3
REQUIREMENTS ENGINEERING
3.1 GENERAL
To our knowledge, hardly any previous works investigate multiple users′ profit
optimizations, let alone optimizing the profits of a cloud provider and its users at the same time.
In this work, we first try to optimize multiple users′ profits. Since multiple cloud users compete
for using the resources of a cloud provider, and the utility of each user is affected by the
decisions (service request strategies) of other users, it is natural to analyze the behaviors of such
systems as strategic games.
3.2 HARDWARE REQUIREMENTS
The hardware requirements may serve as the basis for a contract for the implementation of the
system and should therefore be a complete and consistent specification of the whole system.
They are used by software engineers as the starting point for the system design. It shoulds what
the system do and not how it should be implemented.
HARDWARE
 PROCESSOR : PENTIUM IV 2.6 GHz,Intel Core 2 Duo.

 RAM : 4 GB RAM
 MONITOR : 15” COLOR
 HARD DISK : 1TB
22
3.3 SOFTWARE REQUIREMENTS
The software requirements document is the specification of the system. It should include both a
definition and a specification of requirements. It is a set of what the system should do rather than
how it should do it. The software requirements provide a basis for creating the software
requirements specification. It is useful in estimating cost, planning team activities, performing
tasks and tracking the teams and tracking the team’s progress throughout the development
activity.
 Front End : J2EE (JSP, SERVLET)

 Back End : MY SQL 5.5
 Operating System : Windows 7 or above
 IDE : Eclipse
23
3.4 FUNCTIONAL REQUIREMENTS
A functional requirement defines a function of a software-system or its component. A function is

described as a set of inputs, the behaviour, and outputs. The outsourced computation is data is
more secured.
24
3.5 NON-FUNCTIONAL REQUIREMENTS
The major non-functional Requirements of the system are as follows
 Usability
The system is designed with completely automated process hence there is no or less user
intervention.
 Reliability
The system is more reliable because of the qualities that are inherited from the chosen platform
java. The code built by using java is more reliable.
 Performance
This system is developing in the high-level languages and using the advanced front-end and
back-end technologies it will give response to the end user on client system with in very less
time.
 Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide
range of hardware and any software platform, which is having JVM, built into the system.
 Implementation
The system is implemented in web environment using struts framework. The apache tomcat is
used as the web server and windows xp professional is used as the platform. Interface the user
interface is based on Struts provides HTML Tag
25
CHAPTER 4
DESIGN ENGINEERING
4.1 GENERAL
Design Engineering deals with the various UML [Unified Modelling language] diagrams
for the implementation of project. Design is a meaningful engineering representation of a thing
that is to be built. Software design is a process through which the requirements are translated into
representation of the software. Design is the place where quality is rendered in software
engineering. Design is the means to accurately translate customer requirements into finished
product.
26
4.1.1 Use Case Diagram
register
Login
Cloud
give permission
Cloud Data Base

CloudDtaBase
upload file
User
encryptiondata
key for decryption
Trustee verify key and data
download data
update data
Fig 4.1.1 : Use Case Diagram
EXPLANATION:
Use cases are used during requirements elicitation and analysis to represent the functionality of
the system. Use case focus on the behaviour of the system from an external point of view. The
identification of actors and use cases results in the definition of the boundary of the system,
which is, in differentiating the tasks accomplished by the system and the tasks accomplished by
its environment. The actors are outside the boundary of the system, where as the use cases are
inside the boundary of the system.
27
4.1.2 Class Diagram
Fig 4.1.2 : Class Diagram
EXPLANATION
In this class diagram represents how the classes with attributes and methods are linked
together to perform the verification.
28
4.1.3 Object Diagram
Trustee
datauser Clouddatabase
Admin
CloudServer
Fig 4.1.3 : Object Diagram
EXPLANATION:
In the above digram tells about the flow of objects between the classes. It is a diagram that shows
a complete or partial view of the structure of a modeled system. In this object diagram represents
how the classes with attributes and methods are linked together to perform the verification with
security.
29
4.1.4 State Chart Diagram
Register&Login
Trustee CloudUser
CloudServer
SendRequest
Admin
verify key
CheckActivation
upload data
Give permission download file
cloud database Update data
Fig 4.1.4 : State Chart Diagram
EXPLANATION:
State diagram are a loosely defined diagram to show workflows of stepwise activities and
actions, with support for choice, iteration and concurrency. State diagrams require that the
system described is composed of a finite number of states; sometimes, this is indeed the case,
while at other times this is a reasonable abstraction. Many forms of state diagrams exist, which
differ slightly and have different semantics.
30
4.1.5 Sequence Diagram
Trustee CloudServer CloudUser Admin Cloud

Database
Registe
Registration success
Register
Register Success
Send Request
Give permission
Login
Login Success
Send Request
give Activation
Get key
upload data
Download Data
update data
login
login Success
Check all details
Fig 4.1.5 : Sequence Diagram
EXPLANATION:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is a construct of
a Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality of the scenario.
31
4.1.6 Collaboration Diagram
10:
6: Give
givepermission
Activation
Cloud Cloud
Server User
5: Send Request
9:
3: Register
11: Get key
7: Login 12: upload data
4: Register Success
14: update data
13: Download Data
8: Login Success
1: Registe
Trustee Cloud
Database
15: loginsuccess
2: Registration
16: login Success

Admin 17: Check all details
Fig 4.1.6 : Collaboration Diagram
EXPLANATION:
A collaboration diagram, also called a communication diagram or interaction diagram, is

an illustration of the relationships and interactions among software objects in the Unified
Modeling Language (UML). The concept is more than a decade old although it has been refined
as modeling paradigms have evolved.
32
4.1.7 Activity Diagram
Register/Login
Trustee
Send request
Cloud Server
Verify key
Give Rights To Activate

upload file
Admin
download file
Cloud Database update file
Fig 4.1.7 : Activity Diagram
EXPLANATION:
Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency. In the Unified Modeling Language,
activity diagrams can be used to describe the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control.
33
4.1.8 Component Diagram
Register
CloudUser
Cloud
Login Database
Cloud
Server
Trustee Admin
Fig 4.1.8 : Component Diagram
EXPLANATION:
In the Unified Modeling Language, a component diagram depicts how components are wired
together to form larger components and or software systems. They are used to illustrate the
structure of arbitrarily complex systems. User gives main query and it converted into sub queries
and sends through data dissemination to data aggregators. Results are to be showed to user by
data aggregators. All boxes are components and arrow indicates dependencies.
34
4.1.9 E-R Diagram:
Cloud
Enter Server
key & Key Password
NameAuthentication Data Verify Name
base
Verify
password
Owner Admin Password
UsernameVerify
Fig 4.1.9 : E-R Diagram
EXPLANATION:
Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-

relationship modeling is a database modeling method, used to produce a type of conceptual
schema or semantic data model of a system, often a relational database.
35
4.1.10 Data Flow Diagram:
Level 0:
Verify Error
Fig 4.1.10 : Data Flow Diagram
36
Level 1:
Data owner
Admin Cloud
EXPLANATION:
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a preliminary step used to create an
overview of the system which can later be elaborated. DFDs can also be used for the visualization of data
processing (structured design).
A DFD shows what kinds of data will be input to and output from the system, where the data will
come from and go to, and where the data will be stored. It does not show information about the timing of
processes, or information about whether processes will operate in sequence or in parallel.
37
4.1.11 Deployment Diagram:
Trustee Register
cloduser Login clouddat

abase
Admin
cloudser
ver
Fig 4.1.11 : Deployment Diagram
EXPLANATION:
In the Unified Modeling Language, a component diagram depicts how components are wired
together to form larger deployment and or software systems. They are used to illustrate the
structure of arbitrarily complex systems. User gives main query and it converted into sub queries
and sends through data dissemination. Results are to be showed to user by data aggregators. All
boxes are arrow indicates dependencies.
38
4.2 System Architecture
Fig 4.2 : System Architecture
39
CHAPTER 5
DEVELOPMENT TOOLS
5.1 GENERAL
This chapter is about the software language and the tools used in the development of the project. The
platform used here is JAVA. The Primary languages are JAVA, J2EE and J2ME. In this project J2EE is
chosen for implementation.
5.2 FEATURES OF JAVA
5.2.1 THE JAVA FRAMEWORK
Java is a programming language originally developed by James Gosling at Microsystems and

released in 1995 as a core component of Sun Microsystems' Java platform. The language derives
much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities.
Java applications are typically compiled to byte code that can run on any Java Virtual Machine
(JVM) regardless of computer architecture. Java is general-purpose, concurrent, class-based, and
object-oriented, and is specifically designed to have as few implementation dependencies as
possible. It is intended to let application developers "write once, run anywhere".
Java is considered by many as one of the most influential programming languages of the
20th century, and is widely used from application software to web applications the java
framework is a new platform independent that simplifies application development internet. Java
technology's versatility, efficiency, platform portability, and security make it the ideal
technology for network computing. From laptops to datacenters, game consoles to scientific
supercomputers, cell phones to the Internet, Java is everywhere!
40
5.2.2 OBJECTIVES OF JAVA
To see places of Java in Action in our daily life, explore java.com.
Why Software Developers Choose Java
Java has been tested, refined, extended, and proven by a dedicated community. And numbering
more than 6.5 million developers, it's the largest and most active on the planet. With its
versatility, efficiency, and portability, Java has become invaluable to developers by enabling
them to:
 Write software on one platform and run it on virtually any other platform
 Create programs to run within a Web browser and Web services
 Develop server-side applications for online forums, stores, polls, HTML forms
processing, and more
 Combine applications or services using the Java language to create highly customized
applications or services
 Write powerful and efficient applications for mobile phones, remote processors, low-cost
consumer products, and practically any other device with a digital heartbeat
Some Ways Software Developers Learn Java
Today, many colleges and universities offer courses in programming for the Java platform. In
addition, developers can also enhance their Java programming skills by reading Sun's
java.sun.com Web site, subscribing to Java technology-focused newsletters, using the Java
Tutorial and the New to Java Programming Center, and signing up for Web, virtual, or
instructor-led courses.
ObjectOriented
To be an Object Oriented language, any language must follow at least the four characteristics.
1. Inheritance:It is the process of creating the new classes and using the behavior of the
existing classes by extending them just to reuse the existing code and adding addition a
feature as needed.
41
2. Encapsulation: It is the mechanism of combining the information and providing the
abstraction.
3. Polymorphism: As the name suggest one name multiple form, Polymorphism is the
way of providing the different functionality by the functions having the same name based
on the signatures of the methods.
4. Dynamic binding: Sometimes we don't have the knowledge of objects about their
specific types while writing our code. It is the way of providing the maximum
functionality to a program about the specific type at runtime.
5.2.3 JAVA SWING OVERVIEW
Abstract Window Toolkit (AWT) is cross-platform
Swingprovides many controls and widgets to build user interfaces with. Swing class names
typically begin with a J such as JButton, JList, JFrame. This is mainly to differentiate them
from their AWT counterparts and in general is one-to-one replacements. Swing is built on the
concept of Lightweight components vs AWT and SWT's concept of Heavyweight
components. The difference between the two is that the Lightweight components are
rendered (drawn) using purely Java code, such as drawLine and drawImage, whereas
Heavyweight components use the native operating system to render the components.
Some components in Swing are actually heavyweight components. The top-level classes and
any derived from them are heavyweight as they extend the AWT versions. This is needed
because at the root of the UI, the parent windows need to be provided by the OS. These top-
level classes include JWindow, JFrame, JDialog and JApplet. All Swing components to be
rendered to the screen must be able to trace their way to a root window of one of those
classes.
42
Note: It generally it is not a good idea to mix heavyweight components with lightweight
components (other than as previously mentioned) as you will encounter layering issues, e.g.,
a lightweight component that should appear "on top" ends up being obscured by a
heavyweight component. The few exceptions to this include using heavyweight components
as the root pane and for popup windows. Generally speaking, heavyweight components will
render on top of lightweight components and will not be consistent with the look and feel
being used in Swing. There are exceptions, but that is an advanced topic. The truly
adventurous may want to consider reading this article from Sun on mixing heavyweight and
lightweight components.
5.2.4 EVOLUTION OF COLLECTION FRAMEWORK:
Almost all collections in Java are derived from the java.util.Collection interface. Collection
defines the basic parts of all collections. The interface states the add() and remove() methods for
adding to and removing from a collection respectively. Also required is the toArray() method,
which converts the collection into a simple array of all the elements in the collection. Finally, the
contains() method checks if a specified element is in the collection. The Collection interface is a
sub interface of java.util.Iterable, so the iterator() method is also provided. All collections have
an iterator that goes through all of the elements in the collection. Additionally, Collection is a
generic. Any collection can be written to store any class. For example, Collection<String> can
hold strings, and the elements from the collection can be used as strings without any casting
required.
There are three main types of collections:
 Lists: always ordered, may contain duplicates and can be handled the same way as usual
arrays
 Sets: cannot contain duplicates and provide random access to their elements
 Maps: connect unique keys with values, provide random access to its keys and may host
duplicate values
43
LIST:
Lists are implemented in the JCF via the java.util.List interface. It defines a list as essentially a
more flexible version of an array. Elements have a specific order, and duplicate elements are
allowed. Elements can be placed in a specific position. They can also be searched for within the
list. Two concrete classes implement List. The first is java.util.ArrayList, which implements the
list as an array. Whenever functions specific to a list are required, the class moves the elements
around within the array in order to do it. The other implementation is java.util.LinkedList. This
class stores the elements in nodes that each have a pointer to the previous and next nodes in the
list. The list can be traversed by following the pointers, and elements can be added or removed
simply by changing the pointers around to place the node in its proper place.
SET:
Java's java.util.Set interface defines the set. A set can't have any duplicate elements in it.
Additionally, the set has no set order. As such, elements can't be found by index. Set is
implemented by java.util.HashSet,java.util.LinkedHashSet, and java.util.TreeSet. HashSet uses a
hash table. More specifically, it uses a java.util.HashMap to store the hashes and elements and to
prevent duplicates. Java.util.LinkedHashSet extends this by creating a doubly linked list that
links all of the elements by their insertion order. This ensures that the iteration order over the set
is predictable. java.util.TreeSet uses a red-black tree implemented by a java.util.TreeMap. The
red-black tree makes sure that there are no duplicates. Additionally, it allows Tree Set to
implement java.util.SortedSet.
The java.util.Set interface is extended by the java.util.SortedSet interface. Unlike a regular set,
the elements in a sorted set are sorted, either by the element's compareTo() method, or a method
provided to the constructor of the sorted set. The first and last elements of the sorted set can be
retrieved, and subsets can be created via minimum and maximum values, as well as beginning or
ending at the beginning or ending of the sorted set. The SortedSet interface is implemented
by java.util.TreeSet
44
java.util.SortedSet is extended further via the java.util.NavigableSet interface. It's similar to
SortedSet, but there are a few additional methods. The floor(), ceiling(), lower(), and higher()
methods find an element in the set that's close to the parameter. Additionally, a descending
iterator over the items in the set is provided. As with SortedSet, java.util.TreeSet implements
NavigableSet.
MAP:
Maps are defined by the java.util.Map interface in Java. Maps are simple data structures that
associate a key with a value. The element is the value. This lets the map be very flexible. If the
key is the hash code of the element, the map is essentially a set. If it's just an increasing number,
it becomes a list. Maps are implemented by java.util.HashMap, java.util.LinkedHashMap,
and java.util.TreeMap. HashMap uses a hash table. The hashes of the keys are used to find the
values in various buckets. LinkedHashMap extends this by creating a doubly linked list between
the elements. This allows the elements to be accessed in the order in which they were inserted
into the map. TreeMap, in contrast to HashMap and LinkedHashMap, uses a red-black tree. The
keys are used as the values for the nodes in the tree, and the nodes point to the values in the map
THREAD:
Simply put, a thread is a program's path of execution. Most programs written today run as a
single thread, causing problems when multiple events or actions need to occur at the same time.
Let's say, for example, a program is not capable of drawing pictures while reading keystrokes.
The program must give its full attention to the keyboard input lacking the ability to handle more
than one event at a time. The ideal solution to this problem is the seamless execution of two or
more sections of a program at the same time.
45
CREATING THREADS:
Java's creators have graciously designed two ways of creating threads: implementing an interface
and extending a class. Extending a class is the way Java inherits methods and variables from a
parent class. In this case, one can only extend or inherit from a single parent class. This
limitation within Java can be overcome by implementing interfaces, which is the most common
way to create threads. (Note that the act of inheriting merely allows the class to be run as a thread.
It is up to the class to start() execution, etc.)
Interfaces provide a way for programmers to lay the groundwork of a class. They are used to
design the requirements for a set of classes to implement. The interface sets everything up, and
the class or classes that implement the interface do all the work. The different set of classes that
implement the interface have to follow the same rules.
5.3 CONCLUSION
Swing's high level of flexibility is reflected in its inherent ability to override the native
host operating system (OS)'s GUI controls for displaying itself. Swing "paints" its controls using
the Java 2D APIs, rather than calling a native user interface toolkit. The Java thread scheduler is
very simple. All threads have a priority value which can be changed dynamically by calls to the
threads setPriority() method . Implementing the above concepts in our project to do the efficient
work among the Server.
46
CHAPTER 6
IMPLEMENTATION
6.1 GENERAL
The Implementation is nothing but sores code of project.
6.2 IMPLEMENTATION
Coding:
login.jsp
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0

Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml">
<head>
<metahttp-equiv="Content-Type"content="text/html; charset=utf-8"/>
<metaname="keywords"content="free web template, sport center, CSS, HTML, 2 columns"/>

<metaname="description"content="Free Website Template - Sport Center"/>

</head>
<bodybackground="images/p.jpg">
<br/><br/><br/><br/><br/><br/>
<h3>            &n
bsp;            &nb
sp;            &nbs
p;
<ahref="index.jsp"class="current">Home</a>      &nbs
p;

<ahref="login.jsp">Login</a>

47
<ahref="trustee.jsp">Trustee</a>        &nb
sp;            &nbs
p;
<ahref="kdc.jsp">Cloud
Server</a>           &nb
sp;
<ahref="admin.jsp">Admin</a>        &nbs
p;
<ahref="signup.jsp"class="last">SignUp</a>
</h3><br/>
<center><h1><marqueescrollamount="5"width="40"><<<</marquee>Login
Page<marqueescrollamount="5"direction="right"width="40">>>></marquee></h1>
<formstyle="margin-top: 10px;width:
500px;height:200px"action="loginaction.jsp"method="get">
Username  <inputtype="text"placeholder="Enter
Username"name="user"/><br/><br/>
Password   <inputtype="password"placeholder="Enter
Password"name="pass"/><br/><br/>
<inputtype="submit"class="myButton"value="Sign In"/>
  <inputtype="reset"class="myButton"/>
</form>
</center>
<br/><br/><br/><br/><br/><br/><br/><br/>
<pstyle="color: blue">Copyright ©<ahref="http://www.vertilinktech.com/">Vertilink.</a>
All Rights Reserved. Design idea by <ahref="#">Kishan</a></p>
</body>
</html>
Loginaction.jsp
<%@pageimport="java.sql.Statement"%>
<%@pageimport="pack.Db"%>
<%@pageimport="java.sql.Connection"%>
<%@pageimport="java.sql.ResultSet"%>
<%
String user = request.getParameter("user");
String pass = request.getParameter("pass");
try{
48
String role=null;
String name=null;
String password=null;
Connection con = Db.getConnection();
Statement st = con.createStatement();
ResultSet rs = st.executeQuery("select * from data where pass='"+pass+"'");
while(rs.next())
{
name = rs.getString("Name");
password = rs.getString("Pass");
role = rs.getString("Role");
}
if(user.equals(name)&&pass.equals(password)&&role.equals("Creator"))
{
response.sendRedirect("creatorview.jsp?Login Successfully");
session.setAttribute("c", user);
}
elseif(user.equals(name)&&pass.equals(password)&&role.equals("Reader"))
{
response.sendRedirect("readerhome.jsp?Login Successfully");
session.setAttribute("d", user);
}
elseif(user.equals(name)&&pass.equals(password)&&role.equals("Writer"))
{
response.sendRedirect("writerview.jsp?Login Successfully");
session.setAttribute("e", user);
}
else {
response.sendRedirect("login.jsp?Login Failed");
}
}
catch(Exception e)
{
System.out.println("Error in loginaction"+e.getMessage());
}
%>
Db.java
package pack;
49
import java.sql.Connection;
import java.sql.DriverManager;
import java.util.concurrent.ExecutionException;
import javax.swing.JOptionPane;
public class Db {
public static Connection getConnection(){
Connection con =null;
try{ String url="jdbc:mysql://localhost:3306/vtjcc09-2017";
String driver="com.mysql.jdbc.Driver";
Class.forName(driver).newInstance();
con = DriverManager.getConnection(url, "root", "root");
System.out.println("Database Connected");
} catch(Exception e)
} return con;
public static void main(String[] args)
{ }}
trustee.jsp

<head>
</head>
50
<h3>            &n
bsp;            &nb
sp;            &nbs
p;
<ahref="index.jsp"class="current">Home</a>      &nbs
p;

<ahref="login.jsp">Login</a>

<ahref="trustee.jsp">Trustee</a>        &nb
sp;            &nbs
p;
<ahref="kdc.jsp">Cloud
Server</a>           &nb
sp;
<ahref="admin.jsp">Admin</a>        &nbs
p;
<ahref="signup.jsp"class="last">SignUp</a>
</h3><br/><br/>
<center><h1><marqueescrollamount="5"width="40"><<<</marquee>Trustee Login
Page<marqueescrollamount="5"direction="right"width="40">>>></marquee></h1>
<formstyle="margin-top: 10px;width:
500px;height:200px"action="trusteeaction.jsp"method="get">
<labelstyle="font-size: 20px;margin-left:
70px">Username</label>  <inputtype="text"class="textbox"placeholder="Enter
Username"name="user"/><br/><br/>
<labelstyle="font-size: 20px;margin-left:
70px">Password</label>    <inputtype="password"class="textbox"pla
ceholder="Enter Password"name="pass"/><br/><br/>
<inputtype="submit"value="Sign In"class="myButton"style="margin-left: 100px"/>
  <inputtype="reset"class="myButton"/>
</form></center>
</body>
</html>
trusteeaction.jsp
51
<%try{
String user = request.getParameter("user");
String pass = request.getParameter("pass");
if(user.equalsIgnoreCase("Trustee")&&pass.equalsIgnoreCase("Trustee"))
{
response.sendRedirect("trusteeview.jsp?msg=Login Successfully");
System.out.println("Success");
} else{
response.sendRedirect("trustee.jsp?msg=Login Failed");
System.out.println("Failed");
}
}
catch(Exception e)
{
System.out.println("Exception Error"+e.getMessage());
}
%>
trusteeview.jsp

<head>
</head>
<br/><br/><br/><br/><br/><h3>        &nb
sp;            &nbs
p;





52
<ahref="trusteeview.jsp"class="current">Home</a>


<ahref="trusteedetails.jsp">Request
Details</a>           &nb
sp;            &nbs
p;
<ahref="index.jsp"class="last">Logout</a>
</h3><br/><br/><br/>
<center><h1style="margin-top: -35px">Welcome to Trustee</h1>
<imgsrc="images/trust.jpg"align="middle"/></center>
<br/>
</body>
</html>
Kdcdetails.jsp
<%@pageimport="java.sql.ResultSet"%>
<%@pageimport="java.sql.Statement"%>
<%@pageimport="pack.Db"%>
<%@pageimport="java.sql.Connection"%>
<%@pageimport="java.sql.Date"%>
<head>
</head>
<br/><br/><br/><br/><br/><h3>






53



<ahref="kdcview.jsp"class="current">Home</a>      &n
bsp;            &nb
sp;
<ahref="kdcdetails.jsp">Request
Details</a>           &nb
sp;            &nbs
p;
<ahref="index.jsp"class="last">Logout</a>
<h2><center> Request Pending for Keys</center><br/></h2>

<tableborder="1"align="center"cellpadding="1"width="700">
<tr>
<th>User Id</th>
<th>Pkey</th>
<th>Skey</th>
<th>Response</th>
</tr>
<%try { String fn = null;
String fs = null;
String ft = null;
Connection con = Db.getConnection();
Statement st = con.createStatement();
ResultSet rs = st.executeQuery("select * from kdc ");
while (rs.next()) {
fn = rs.getString("uid");
fs = rs.getString("pkey");
ft = rs.getString("skey");%>
<tr>
<td><%=fn%></td>
<td><%=fs%></td>
<td><%=ft%></td>
<td><ahref="kresponse.jsp?<%=fn%>"style="text-decoration: none">Response</a></td>
</tr>
<% } } catch (Exception e) {
System.out.println("Error in File details" + e.getMessage());
54
}
%>
</table>
<br/><br/><br/><br/><br/><br/><br/><br/><br/>
</body>
</html>
55
CHAPTER 7
SNAPSHOTS
7.1 GENERAL
This project is implements like web application using COREJAVA and the Server process is
maintained using the SOCKET & SERVERSOCKET and the Design part is played by
Cascading Style Sheet.
7.2 VARIOUS SNAPSHOTS
7.2.1 Registration Page
Fig 7.2.1 : Registration Page
56
7.2.2 Creator Login Page
Fig 7.2.2 : Creator Login Page
7.2.3 Creator Home Page
Fig 7.2.3 : Creator Home Page
57
7.2.4 Creator Token Request
Fig 7.2.4 : Creator Token Request
7.2.5 Trustee Login for Token Approval
Fig 7.2.5 : Trustee Login Page
58
7.2.6 Trustee Token Approval
Fig 7.2.6 : Trustee Home Page
7.2.7 Cloud Server Login for Cloud Approval
Fig 7.2.7 : Cloud Server Login Page
59
7.2.8 Cloud Server Approval
Fig 7.2.8 : Cloud Server Home Page
7.2.9 Upload file to Cloud by creator
Fig 7.2.9 : File Upload Page
60
7.2.10 Viewing File
Fig 7.2.10 : File Viewing Page
7.2.11 Reader Actions
Fig 7.2.11 : Reader Actions
61
7.2.12 Writer Actions
Fig 7.2.12 : Writer Actions
62
CHAPTER 8
SOFTWARE TESTING
8.1 GENERAL
The purpose of testing is to discover errors. Testing is the process of trying to discover
every conceivable fault or weakness in a work product. It provides a way to check the
functionality of components, subassemblies, assemblies and/or a finished product It is the
process of exercising software with the intent of ensuring that the Software system meets its
requirements and user expectations and does not fail in an unacceptable manner. There are
various types of test. Each test type addresses a specific testing requirement.
8.2 DEVELOPING METHODOLOGIES

The test process is initiated by developing a comprehensive plan to test the general
functionality and special features on a variety of platform combinations. Strict quality control
procedures are used.The process verifies that the application meets the requirements specified in
the system requirements document and is bug free. The following are the considerations used to
develop the framework from developing the testing methodologies.
8.3 Types of Tests
8.3.1 Unit testing

Unit testing involves the design of test cases that validate that the internal program logic is
functioning properly, and that program input produce valid outputs. All decision branches and
internal code flow should be validated. It is the testing of individual software units of the
application .it is done after the completion of an individual unit before integration. This is a
structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform
basic tests at component level and test a specific business process, application, and/or system
configuration. Unit tests ensure that each unique path of a business process performs accurately
to the documented specifications and contains clearly defined inputs and expected results.
63
8.3.2 Functional test
Functional tests provide systematic demonstrations that functions tested are available as
specified by the business and technical requirements, system documentation, and user manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures : interfacing systems or procedures must be invoked.
8.3.3 System Test

System testing ensures that the entire integrated software system meets requirements. It tests a
configuration to ensure known and predictable results. An example of system testing is the
configuration oriented system integration test. System testing is based on process descriptions
and flows, emphasizing pre-driven process links and integration points.
8.3.4 Performance Test

The Performance test ensures that the output be produced within the time limits,and the time
taken by the system for compiling, giving response to the users and request being send to the
system for to retrieve the results.
8.3.5 Integration Testing

Software integration testing is the incremental integration testing of two or more integrated
software components on a single platform to produce failures caused by interface defects.
The task of the integration test is to check that components or software applications, e.g.
components in a software system or – one step up – software applications at the company level –
interact without error.
64
8.3.6 Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires significant participation
by the end user. It also ensures that the system meets the functional requirements.
Acceptance testing for Data Synchronization:

 The Acknowledgements will be received by the Sender Node after the Packets are received
by the Destination Node
 The Route add operation is done only when there is a Route request in need
 The Status of Nodes information is done automatically in the Cache Updation process
8.3.7 Build the test plan
Any project can be divided into units that can be further performed for detailed processing. Then
a testing strategy for each of this unit is carried out. Unit testing helps to identity the possible
bugs in the individual component, so the component that has bugs can be identified and can be
rectified from errors.
65
TEST CASES:
Test cases can be divided in to two types. First one is Positive test cases and second one is
negative test cases. In positive test cases are conducted by the developer intention is to get the
output. In negative test cases are conducted by the developer intention is to don’t get the output.
TEST CASE – 1 : Positive Test Case
On successfull Ticket Appoval, appropriate file is accessible
TEST CASE – 2 : Negative Test Case
On UnSuccessfull Ticket Appoval, appropriate file is not accessible
66
CHAPTER 9
APPLICATION AND FUTURE ENHANCEMENT

9.1 GENERAL
We compare our scheme with related schemes in terms of unlinkability, untransferability, double
spend detection, de-anonymisation, attribute-based ticketing and security proof, where indicates
that security was not considered by the authors of the respective schemes. The European
Telecommunications Standards Institute (ETSI) released two specifications on attribute-based
encryption (ABE) which can be used to securely protect personal data and implement fine-
grained access control. In an ABE scheme, a message is encrypted by using a set of attributes so
that only the users whose attributes match those in the ciphertext can decrypt it and see the
message. As specified in ABE supports offline access control. However, in our scheme, a user
can only authenticate to an online verifier. Furthermore, an issued credential enables a user to
prove that she holds required attributes without revealing them.
9.2 FUTURE ENHANCEMENT
Our future work will be looking at the impact on the security model and proof when
dynamic policy updates are allowed as well as changes to scheme’s implementation to improve
its performance, e.g. by pre-computing static values where possible and using the C-based PBC
library, outsourcing computation, verifiable outsourcing computation, etc. Another open problem
and an interesting area for our future work is to construct a privacy-preserving e-ticket scheme
with attribute-based credentials using the most efficient type of pairing, the Type- III pairing.
67
CHAPTER 10
CONCLUSION & REFERENCE
10.1 CONCLUSION
To protect user privacy in e-ticket schemes, various schemeshave been proposed but they do not
address attribute-basedticketing. Similarly, privacy-preserving attribute-based credentialschemes
are proposed where attributes can either beelements of a set or within a range but this paper
proposesa scheme to support both the use of sets and ranges withinthe same scheme. The paper
has defined such a schemetogether with its security model and security proof. Thebenefit of this
scheme is to provide a policy maker withthe flexibility to decide which kind of policies should
beused. Set policies are computationally more efficient thanrange policies but the latter could
potentially accommodatefuture policy changes. Currently, our scheme is not suitablefor portable
devices, e.g. smart phone, tablet, etc., due to itshigh computation cost and communication
overhead.
68
10.2 REFERENCE
[1] UnitedAirlines. (2017) Customer data privacy policy.[Online].Available:

https://www.united.com/web/en-US/content/privacy.aspx
[2] Rail Delivery Group. (2017) Rail technicalstrategy capability delivery plan. [Online].Available:
https://www.rssb.co.uk/rts/Documents/2017-01-27-rail-technical-strategy-capability-delivery-
planbrochure.pdf
[3] M. Milutinovic, K. Decroix, V. Naessens, and B. D. Decker,“Privacy-preserving public transport

ticketing system,” in DBSec’15. Springer, 2015, pp. 135–150.
[4] M. Mut-Puigserver, M. M. Payeras-Capella, J.-L. Ferrer-Gomila,A. Vives-Guasch, and J. Castella-

Roca, “A survey of electronicticketing applied to transport,” Computers & Security, vol. 31, no. 8,pp.
925–939, 2012.
[5] A. Vives-Guasch, M. M. Payeras-Capella, M. Mut-Puigserver,J. Castella-Roca-Roca, and J.-L. Ferrer-

Gomilas, “Anonymous andtransferable electronic ticketing scheme,” in DPM’13 and SETOP’13.
Springer, 2013, pp. 100–113.
[6] (2016) General Data Protection Regulation. [Online]. Available:https://eugdpr.org/
[7] T. S. Heydt-Benjamin, H.-J. Chae, B. Defend, and K. Fu, “Privacyfor public transportation,” in
PET’06. ACM, 2006, pp. 1–19.
[8] G. Arfaoui, J.-F. Lalande, J. Traore, N. Desmoulins, P. Berthome,and S. Gharout, “A practical set-
membership proof for privacy preserving NFC mobile ticketing,” in PoPETs’15. DE GRUYTER,2015,
pp. 25–45.
[9] R. Song and L. Korba, “Pay-TV system with strong privacy andnon-repudiation protection,” IEEE
Transactions on Consumer Electronics,vol. 49, no. 2, pp. 408–413, 2003.
[10] I. Gudymenko, “A privacy-preserving e-ticketing system for publictransportation supporting fine-

granular billing and local validation,”in SIN’14. ACM, 2014, pp. 101–107.
[11] F. Kerschbaum, H. W. Lim, and I. Gudymenko, “Privacy Preserving billing for e-ticketing systems
in public transportation,”in WPES’13. ACM, 2013, pp. 143–154.
69
[12] A. Rupp, G. Hinterwalder, F. Baldimtsi, and C. Paar, “P4r: Privacy preserving pre-payments with
refunds for transportation systems,”in FC’13. Springer, 2013, pp. 205–212.
[13] IATA. (2012) Transferability of tickets. [Online].

Available:https://www.iata.org/policy/Documents/Transferability.pdf
[14] B. Patel and J. Crowcroft, “Ticket based service access for themobile user,” in MobiCom’97. ACM,
1997, pp. 223–233.
[15] D. Chaum, “Blind signatures for untraceable payments,” inCrypto’82. Springer, 1982, pp. 199–203.
[16] D. Chaum and E. van Heyst, “Group signatures,” in EUROCRYPT’91. Springer, 1991, pp. 257–265.
[17] D. Chaum, “Security without identification: transaction systems tomake big brother obsolete,”
Communications of the ACM, vol. E28,no. 10, pp. 1030–1044, 1985.
[18] A. Lysyanskaya, R. L. Rivest, A. Sahai, and S. Wolf, “Pseudonymsystems,” in SAC’99. Springer,

1999, pp. 184–199.
[19] C.-I. Fan and C.-L. Lei, “Multi-recastable ticket schemes for electronicvoting,” IEICE Transactions
on Fundamentals of Electronics,Communications and Computer Sciences, vol. E81-A, no. 5, pp. 940–949,
1998.
[20] D. Quercia and S. Hailes, “Motet: Mobile transactions using electronicticket,” in SecureComm’05.
IEEE, 2005, pp. 1–10.
[21] A. Rupp, F. Baldimtsi, G. Hinterwalder, and C. Paar, “Cryptographictheory meets practice: Efficient
and privacy-preservingpayments for public transport,” ACM Transactions on Informationand System
Security, vol. 17, no. 3, pp. 10:01–10:31, 2015.
[22] S. Brands, “Untraceable off-line cash in wallets with observers(extended abstract),” in CRYPTO’93.
Springer, 1993, pp. 302–318.
[23] D. Boneh, B. Lynn, and H. Shacham: “Short signatures from theweil pairing,” Journal of Cryptology,
vol. 17, no. 4, pp. 297–319, 2004.
[24] M. Abe and T. Okamoto, “Provably secure partially blind signatures,”in CRYPTO’00. Springer,
2000, pp. 271–286.
70
[25] T. P. Pedersen, “Non-interactive and information-theoretic secureverifiable secret sharing,” in
CRYPTO’91. Springer, 1991, pp. 129–140.
[26] J. Camenisch and A. Lysyanskaya, “An efficient system for non-transferable anonymous credentials
with optional anonymity revocation,”in EUROCRYPT’01. Springer, 2001, pp. 93–118.
[27] T. Nakanishi, N. Haruna, and Y. Sugiyama, “Unlinkable electroniccoupon protocol with anonymity
control,” in ISW’99. Springer,1999, pp. 37–46.
[28] J. Camenisch and M. Stadler, “Efficient group signature schemesfor large groups,” in CRYPTO’97.
Springer, 1997, pp. 410–424.
[29] A. Vives-Guasch, J. Castella-Roca, M. M. Payeras-Capella, andM. Mut-Puigserver, “An electronic

and secure automatic fare collectionsystem with revocable anonymity for users,” in MoMM’10.ACM,
2010, pp. 387–392.
[30] D. Boneh and H. Shacham, “Group signatures with verifier-localrevocation,” in ACM CCS’04, pp.
168–177.
[31] D. Boneh and X. Boyen, “Short signatures without random oracles,”in EUROCRYPT’04. Springer,
2004, pp. 56–73.
[32] J. Camenisch and A. Lysyanskaya, “Signature schemes and anonymouscredentials from bilinear
maps,” in CRYPTO’04. Springer,2004, pp. 56–72.
[33] K. Fujimura and Y. Nakajima, “General-purpose digital ticketframework,” in USENIX Workshop on

Electronic Commerce 1998.USENIX Association, 1998, pp. 177–186.
[34] G. Davida, Y. Frankel, Y. Tsiounis, and M. Yung, “Anonymitycontrol in e-cash systems,” in FC’97.
Springer, 1997, pp. 1–16.
[35] E. Gabber, P. B. Gibbons, Y. Matias, and A. Mayer, “How to makepersonalized web browsing
simple, secure, and anonymous,” inFC’97. Springer, 1997, pp. 17–31.
[36] O. Jorns, O. Jung, and G. Quirchmayr, “A privacy enhancing servicearchitecture for ticket-based
mobile applications,” in ARES’07.IEE, 2007, pp. 139–146.
[37] N. Kuntze and A. U. Schmidt, “Trusted ticket systems and application,”in SEC’07. IFIP Advances in
Information and CommunicationTechnology, 2007, pp. 49–60.
71
[38] A. Vives-Guasch, M. M. Payeras-Capella, M. Mut-Puigserver,and J. L. Ferrer-Gomila, “A secure e-
ticketing scheme for mobiledevices with near field communication (NFC) that includes exculpabilityand
reusability,” IEICE Transactions on Information andSystems, vol. E95.D, no. 1, pp. 78–93, 2012.
[39] Y.-Y. Chen, C.-L. Chen, and J.-K. Jan, “A mobile ticket systembased on personal trusted device,”
Wireless Personal Communications,vol. 40, no. 4, pp. 569–578, 2007.
[40] G.-R. Liu, P. Lin, and Y.-B. Lin, “Modeling mobile ticket dispensersystem with impatient clerk,”
IEEE Transactions on Vehicular Technology,vol. 65, no. 12, pp. 9931–9941, 2016.
[41] ETSI TS 103 458. (2018) Cyber; application of attribute-based encryption (abe) for pii and personal
data protection on iotdevices, wlan, cloud and mobile services - high level requirements.[Online].
Available: https://www.etsi.org/deliver/etsits/103400 103499/103458/01.01.01 60/ts
103458v010101p.pdf
[42] ETSI TS 103 532. (2018) Cyber; attribute-based encryptionfor attribute-based access control.
[Online].Available: https://www.etsi.org/deliver/etsi ts/103500 103599/103532/01.01.01 60/ts
103532v010101p.pdf
[43] D. Boneh and M. Franklin, “Identity-based encryption from theweil pairing,” in CRYPTO’01.
Springer, 2001, pp. 213–22.
[44] S. D. Galbraith, K. G. Paterson, and N. P. Smart, “Pairings forcryptographers,” Discrete Applied

Mathematics, vol. 156, no. 16, pp.3113–3121, 2008.
[45] M. Bellare and O. Goldreich, “On defining proofs of knowledge,”in CRYPTO’92. Springer, 1992,
pp. 390–420.
[46] J. Camenisch, A. Kiayias, and M. Yung, “On the portability ofgeneralized schnorr proofs,” in
EUROCRYPT’09. Springer, 2009,pp. 425–442.
[47] J. Camenisch, R. Chaabouni, and abhi shelat, “Efficient protocolsfor set membership and range
proofs,” in ASIACRYPT’08.Springer, 2008, pp. 234–252.
[48] M. H. Au, W. Susilo, and Y. Mu, “Constant-size dynamic k-TAA,”in SCN’06. Springer, 2006, pp.
111–125.
[49] R. Canetti, “Universally composable security: A new paradigm forcryptographic protocols,” in

FOCS’01). IEEE, 2001, pp. 136–145.
72
[50] J. Camenisch, G. Neven, and A. Shelat, “Simulatable adaptiveoblivious transfer,” in
EUROCRYPT’07. Springer, 2007, pp. 573–590.
[51] M. Green and S. Hohenberger, “Blind identity-based encryptionand simulatable oblivious transfer,”
in ASIACRYPT’07. Springer,2007, pp. 265–282.
[52] J. Camenisch, M. Dubovitskaya, and G. Neven, “Oblivious transferwith access control,” in ACM
CCS’09. ACM, 2009, pp. 131–140.
[53] A. D. Caro and V. Iovino, “On the power of rewinding simulatorsin functional encryption,” Designs,
Codes and Cryptography, vol. 84,no. 3, pp. 373–399, 2017.
[54] M. H. Au, W. Susilo, and Y. Mu, “Practical anonymous divisiblee-cash from bounded
accumulators,” in FC’08. Springer, 2008,pp. 287–301.
[55] J. Han, L. Chen, S. Schneider, H. Treharne, and S. Wesemeyer.(2018) Privacy-preserving electronic

ticket scheme with attribute based credentials. [Online]. Available: https://arxiv.org/abs/1706.03016
[56] DICE Project. (2017) Benchmark e-ticket systems (bets).[accessed 18-March-2018]. [Online].
Available: https://github.com/swesemeyer/BenchmarkingETicketingSystems
[57] A. De Caro and V. Iovino, “JPBC: Java pairing basedcryptography,” in Proceedings of the 16th
IEEE Symposium onComputers and Communications, ISCC 2011. Kerkyra, Corfu,Greece, June 28 - July
1: IEEE, 2011, pp. 850–855. [Online].Available: http://gas.dia.unisa.it/projects/jpbc/
[58] Legion of the Bouncy Castle Inc. Bouncy Castle CryptoAPIs. [accessed 19-September-2017].
[Online]. Available: https://www.bouncycastle.org/
[59] B. Lynn, “On the implementation of pairing-based cryptosystems,”Ph.D. dissertation, Stanford

University Stanford, California,2007.
[60] D. Freeman, M. Scott, and E. Teske, “A taxonomy of pairing friendly elliptic curves,” Journal of
cryptology, vol. 23, no. 2, pp.224–280, 2010.
[61] B. Lynn. (2006) The pairing-based cryptography PBC library.[Online]. Available:

https://crypto.stanford.edu/pbc/
[62] S. Hohenberger and A. Lysyanskaya, “How to securely outsourcecryptographic computations,” in

TCC’05. Springer, 2005, pp. 264–282.
73
[63] X. Chen, J. Li, J. Ma, Q. Tang, and W. Lou, “New algorithms forsecure outsourcing of modular
exponentiations,” IEEE Transactionson Parallel and Distributed Systems, vol. 25, no. 9, pp. 2386 –
2396,2014.
[64] R. Gennaro, C. Gentry, and B. Parno, “Non-interactive verifiablecomputing: Outsourcing

computation to untrusted workers,” inCRYPTO’10. Springer, 2010, pp. 465–482.
[65] X. Chen, J. Li, J. Weng, J. Ma, and W. Lou, “Verifiable computationover large database with
incremental updates,” IEEE Transactionson Computers, vol. 65, no. 10, pp. 3184–3195, 2016.
[66] X. Chen, J. Li, X. Huang, J. Ma, and W. Lou, “New publiclyverifiable databases with efficient
updates,” IEEE Transactions onDependable and Secure Computing, vol. 12, no. 5, pp. 546–556, 2015.
74

Major Project Sample Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Major Project Sample Documentation

Uploaded by

Copyright:

Available Formats

A Major Project Report on

“Privacy-Preserving Electronic Ticket Scheme with Attribute-Based Credentials”

JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD

In partial fulfillment of the requirement for the award of the degree of

COMPUTER SCIENCE AND ENGINEERING

BODIGE BHARATHWAJ GOUD (18WJ1A0557)

Under the Esteemed Guidance Of

Professor & HOD-CSE

GURU NANAK INSTITUTIONS TECHNICAL CAMPUS (AUTONOMOUS)

Department of Computer Science and Engineering

This is to certify that this project report entitled “PRIVACY-PRESERVING

_________________ _________________________ _________________

INTERNAL GUIDE PROJECT CO-ORDINATOR HOD CSE

Dr. J. Rajeshwar Mr. B. Samirana Acharya Dr. J. Rajeshwar

BODIGE BHARATHWAJ GOUD 18WJ1A0557

AMANAGANTI HEMANTH BABU 18WJ1A0516

BORRA BHARATH KUMAR 18WJ1A0560

TICKET SCHEME WITH ATTRIBUTE-BASED CREDENTIALS”

RAM INNOVATIVE INFOTECH

BODIGE BHARATHWAJ GOUD (18WJ1A0557)

AMANAGANTI HEMANTH BABU (18WJ1A0516)

BORRA BHARATH KUMAR (18WJ1A0560)

CHAPTER NO. TITLE PAGE NO.

LIST OF NOTATIONS VII

1.2 SCOPE OF THE PROJECT 3

1.4 PROBLEM STATEMENT 4

1.5.1 EXISTING SYSTEM DISADVANTAGES 5

1.5.2 LITERATURE SURVEY 6

1.6 PROPOSED SYSTEM 12

1.6.1 PROPOSED SYSTEM ADVANTAGES 13

CHAPTER 2: PROJECT DESCRIPTION

2.2.3 GIVEN INPUT AND EXPECTED OUTPUT 20

2.3 TECHNIQUE OR ALGORITHM 21

3.4 FUNCTIONAL SPECIFICATION 24

CHAPTER 4: SYSTEM DESIGN

4.1.1 USE CASE DIAGRAM 27

4.1.2 CLASS DIAGRAM 28

4.1.3 OBJECT DIAGRAM 29

4.1.4 STATE DIAGRAM 30

4.1.5 SEQUENCED DIAGRAM 31

4.1.7 ACTIVITY DIAGRAM 33

4.1.8 COMPONENT DIAGRAM 34

4.1.9 E-R DIAGRAM 35

4.1.01 DATA FLOW DIAGRAM 36

4.1.11 DEPLOYMENT DIAGRAM 38

4.2 SYSTEM ARCHITECTURE 39

CHAPTER 5: SOFTWARE SPECIFICATION

5.2 FEATURES OF JAVA 40

5.2.1 THE JAVA FRAMEWORK 40

5.2.4 EVOLUTION OF COLLECTION 43

8.3.1 UNIT TESTING 63

8.3.3 SYSTEM TEST 64

8.3.4 PERFORMANCE TEST 64

8.3.5 INTEGRATION TESTING 64

8.3.6 ACCEPTANCE TESTING 65

8.3.7 BUILD THE TEST PLAN 65

CHAPTER 9: APPLICATIONS AND FUTURE

9.2 FUTURE ENHANCEMENTS 67

CHAPTER 10: CONCLUSION & REFERENCES

FIGURE NO NAME OF THE FIGURE PAGE NO.

2.2.2 Module Diagram 17

4.1.1 Use case Diagram 27

4.1.2 Class Diagram 28

4.1.3 Object Diagram 29

_____ _ _____

Author: A. Rupp, F. Baldimtsi, G. Hinterwalder, and C. Paar