The document discusses developing an automated toll collection system using near-field communication (NFC) technology to allow drivers to pay tolls using their NFC-enabled smartphones. It describes the existing manual toll collection system and proposes a new system where drivers can pay tolls automatically by waving their phone at the toll booth. The system would also log all transactions and track vehicles that do not pay their tolls.

1. 1
AN AUTOMATED TOLL COLLECTION SYSTEM
BASED ON NEAR-FIELD COMMUNICATION
CHAPTER 1
INTRODUCTION

2. 2
CHAPTER 1
INTRODUCTION
1.1 OVERVIEW
Tollgates are commonplace in today’s bustling and increasingly congested highway
networks. Once they stood barely queued, but today, rarely empty. This has spurred a
need to make these necessities faster in their process and more efficient due to the huge
number of vehicles moving through them.
A novel solution would be to use something that we have with us all the time, the
ubiquitous mobile phone, which is becoming smarter with each passing year. One of
the new and exciting features of smartphones is Near Field Communication, NFC for
short, which a short-range wireless technology that is used for transfer of small
amounts of data. NFC can be used for quick and easy payment of toll at a tollgate and
this is the subject matter of this project.
1.1 NEAR FIELD COMMUNICATION
Near Field Communication (NFC) is a form of contactless communication between
devices like smartphones or tablets devices over a distance of less than 10 cm. The
NFC standard is defined in ISO/IEC 1809. Contactless communication allows a user
to wave the smartphone over a NFC compatible device to send information without
needing to touch the devices together or go through multiple steps setting up a
connection.
NFC is a short-range radio technology that operates on the 13.56 MHz frequency,
with data transfers of up to 424 kilobits per second. NFC communication is triggered
when two NFC-compatible devices are brought within close proximity, around four
centimeters. Because the transmission range is so short, NFC-based transactions are
inherently secure.
NFC builds upon Radio-frequency identification (RFID) systems by allowing two-
way communication between endpoints this technology behind NFC allows a device,

3. 3
known as a reader, interrogator, or active device, to create a radio frequency current
that communicates with another NFC compatible device or a small NFC tag holding
the information the reader wants. Passive devices, such as the NFC tag in smart
posters, store information and communicate with the reader but do not actively read
other devices. Peer-to-peer communication through two active devices is also a
possibility with NFC. This allows both devices to send and receive information.
NFC and Bluetooth are both short-range communication technologies that are
integrated into mobile phones. NFC operates at slower speeds than Bluetooth, but
consumes far less power and doesn't require pairing. NFC sets up more quickly than
standard Bluetooth, but has a lower transfer rate than Bluetooth low energy. With
NFC, instead of performing manual configurations to identify devices, the connection
between two NFC devices is automatically established quickly: in less than a tenth of
a second. The maximum data transfer rate of NFC (424 kbit/s) is slower than that of
Bluetooth V2.1 (2.1 Mbit/s).
NFC has a shorter range with a maximum working distance of less than 20 cm, which
reduces the likelihood of unwanted interception. That makes NFC particularly suitable
for crowded areas where correlating a signal with its transmitting physical device (and
by extension, its user) becomes difficult.
Fig 1.1 – Types of NFC communication.

4. 4
At the time of writing the NFC standard has three modes of operation: the peer-to-peer
mode that lets two smartphones swap data, a read/write mode in which one active
device picks up info from a passive one, and card emulation, in which an NFC device
such as a smartphone can be used like a contactless credit card.
1.3 EXISTING SYSTEM
The current toll plaza is a multi-booth complex, which can service a single user per
booth at a given time. The actual collection of fee and delivery of receipt is not
automated and requires human effort. This has the obvious limitation of being slow
and error prone due to human intervention. Also the current system does not
implement any tracking or follow-up procedure in case of failure to pay the toll fee.
1.4 PROPOSED SYSTEM
We propose a fully automated and secure system, which uses NFC-enabled
smartphone interacting with a payment terminal to quickly and securely process the
transaction involving toll collection and receipt delivery. The new system also
maintains a database that logs all transactions. In case of failure to pay toll, the system
tracks the vehicle and delivers and email to the defaulter with outstanding charges.
1.5 SYSTEM SPECIFICATION
1.5.1 HARDWARE REQUIREMENTS
Server Mobile
Processor Intel Core 2 Duo, 2 GHz ARM v7
RAM 2 GB 512MB
Connectivity Internet Internet, NFC

5. 5
Table 1.1 – Hardware requirements
1.5.2 SOFTWARE REQUIREMENTS
Server Mobile
Operating System Windows Android
User Interface JSF 2.0 Native Android UI
Development Platform JavaEE 6 Android 4.0
Database MySQL
Web Server Tomcat Web Server
Technologies JAAS, Primefaces
Near Field
Communication
Table 1.2 – Software requirements
1.6 SUMMARY
This chapter gives an overview of the tollgate system and the need for the
automated toll collection system using Near Field Communication (NFC).

6. 6

7. 7
CHAPTER 2
LITERATURE SURVEY

8. 8
CHAPTER 2
LITERATURE SURVEY
2.1 INTRODUCTION
This chapter gives the overall description of those reference papers that depicts
use of Near Field Communication (NFC).
2.2 LITERATURE SURVEY
In [1] Widmann, R.; Grunbeger, S.; Stadlmann, B.; Langer , J.,(2012) proposed Near
Field Communication (NFC) in the field of Electronic Fare Management to radically
change the existing systems of isolated applications in public transport. The
integration of an electronic ticketing system into an existing public transport system
based on NFC is introduced. This system operates with the VDV core application to
provide a seamless way to travel using just an NFC enabled smartphone as the ticket
handler. Some future prospects are discussed which are out of our scope. This paper
presents a similar use case to our project and speaks of its feasibility.
In [2] E. Haselsteiner and K. Breitfuß, gives a comprehensive analysis of security with
respect to NFC. It is not limited to a certain application of NFC, but it uses a
systematic approach to analyze the various aspects of security whenever an NFC
interface is used. The authors want to clear up many misconceptions about security
and NFC in various applications. The paper lists the threats, which are applicable to
NFC, and describes solutions to protect against these threats. All of this is given in the
context of currently available NFC hardware, NFC applications and possible future
developments of NFC.
In [3] Madlmayr, G.; Langer, J.; Scharinger, J. speak generally about the environment
around the Near Field Communication (NFC) . Madlmayr says that several NFC trials
are already established around the world but currently there are no mass rolls out yet.
This is due to several technical as well as administrative issues that have to be dealt
with before rolling out such a system. In this paper the authors present an approach for
managing the B2B relations in a near field communication (NFC) ecosystem offering
services based on card emulation like loyalty, payment and ticketing. Out of

9. 9
experiences made from trials we show which services are needed in order to manage
such an ecosystem and to provide convenience to the user. Furthermore we discuss
functional aspects of such an ecosystem, the parties involved as well as their benefit
for participating. Although the technology already given allows a smooth interaction
for the consumer, the infrastructure behind the scene is complex and requires the
cooperation on different levels to ensure interoperability and a thriving contactless
scheme to be deployed.
In [4], various mobile terminals equipped with NFC (Near Field Communication)
have been released. The combination of NFC with smart devices has led to widening
the utilization range of NFC. It is expected to replace credit cards in electronic
payment, especially. In this regard, security issues need to be addressed to vitalize
NFC electronic payment. The NFC security standards currently being applied require
the use of user's public key at a fixed value in the process of key agreement. The
relevance of the message occurs in the fixed elements such as the public key of NFC.
An attacker can create a profile based on user's public key by collecting the associated
messages. Through the created profile, users can be exposed and their privacy can be
compromised. In this paper, the authors propose conditional privacy protection
methods based on pseudonyms to solve these problems. In addition, PDU (Protocol
Data Unit) for conditional privacy is defined. Users can inform the other party that
they will communicate according to the protocol proposed in this paper by sending the
conditional privacy preserved PDU through NFC terminals. The proposed method
succeeds in minimizing the update cost and computation overhead by taking
advantage of the physical characteristics of NFC.
In [5] Nosowitz, Dan (1 March 2011) explains about the basics of mobile NFC and its
implications in day-to-day life, focusing on mobile payments using NFC. The need for
infrastructure when integrating NFC into any existing system, is undeniable, but also
is not impossible to achieve. As NFC is a global standard, with more and more
manufacturers integrating NFC hardware into mobile devices, it is only a matter of
time before NFC becomes a natural way to perform quick and easy transactions. As
regards to security in NFC based transactions the author is quick to point out that, due
to the very small distance between the two interacting devices, the window for
compromising security is very small. The point of sale security protocol is fairly

10. 10
robust and implements basic security, leaving higher-level security to be provided by
the specific vendors.
2.3 SUMMARY
With extensive literature survey it is evident that several ideas were proposed to use
secure and reliable applications using Near Field Communication (NFC). NFC based
fee collection system can be developed with sufficient security. Mobile to NFC
terminal communication through NFC is also possible to establish.

11. 11
CHAPTER 3
SYSTEM DESIGN

12. 12
CHAPTER 3
SYSTEM DESIGN
3.1 INTRODUCTION
This chapter gives the overall description of the NFC Based Automated
Tollgate System. A high level description of the system is first given, followed by an
in-depth explanation of each of the modules in the system.
3.2 OVERVIEW OF THE WORKING OF NFC:
In this section, NFC environment and features currently being applied are
introduced.
i. TSM: Trusted Service Manager - It is an institution that transfers mobile
financial data of customers to financial institutions safely. The GSMA (Global
System for Mobile Communications Association) proposed TSM to facilitate
the provision of NFC services in 2007. TSM serves as CA (Certification
Authority) and RA (Registration Authority) at the market of certification
services. In this paper, the TSM is considered as TTP for mobile payment
services, and the public key used in NFC devices is assumed to be issued from
TSM.
ii. SE: Secure Element - It is a security area that can safely store important data
such as financial information, authentication information, and service
applications as a secure smart chip. In SE, the range of functions varies
depending on the type of implementation, but the storagefeatures and secure
domain is certainly included. The secure domain is a unique area separated to
safety store important information such as service applications and access key,
etc. Since each secure domain exists independently, it cannot have access to
the secure domain in which other services are installed. Users can be provided
with payment services from various financial companies through a NFC
device.

13. 13
iii. NFC Features - NFC provides TRH (Tamper Resistant Hardware) called SE,
along with TSM, the trusted third party, which is similar to the VANET
environment. However, NFC is somehow different from VANET in
communication environment. In the NFC, attacker's actions are further limited
compared to VANET. Accordingly, the pseudonyms used in VANET are
improved to meet the NFC features and the protection of user's privacy can be
achieved at low cost.
The NFC features noted are as follows.
i. One-to-One communication: In VANET, all vehicles within the range of RSU
(Road-Side Unit) perform communication with one RSU. On the other hand,
since only one- to-one communication is possible in case of NFC, it is easy to
identify with whom you communicate.
ii. Near Field Communication: NFC is a near field communication, and
communication is conducted with the target in front of our eyes. Two users can
identify whether the communication is properly progressed through each
other's device.
iii. Sporadic Communication: Since NFC performs sporadic communication for
payment, it is advantageous to use one-time ID such as pseudonym. In
addition, it is not necessary to store a large amount of pseudonyms in advance
due to plenty of time before next-payment.

14. 14
Fig 3.1 – NFC Architecture.
SECURITY THREATS IN NFC
NFC is a short-range wireless communication technology. Due to its distance
limitations, the short-range wireless communication technology seems to be safer than
wired communication technology, which really is not. In case communication is
performed through RF field, along with NFC, data can be obtained even when users
stay near the transmitter. In this section, the security requirements met by methods
that analyze security threats of NFC are deduced.
A. MITM attack: Man-In-The-Middle attack
MITM attack means an attacker's obtaining data between two users by
spoofing. Suppose that Alice and Bob try toexchange their keys, and Carol is an
attacker. Carol obtains key KAC by performing key agreement after disguising her as
Bob, and key KBC after disguising her as Alice. When user Alice sends data
encrypted with KAC to Carol disguised as Bob, Carol can obtain data m. Carol transfer

15. 15
m encrypted with KBC to Bob. Attacker can modify data of the two users through
MITM attack.
However, it is known that the MITM attack is generally impossible in NFC
due to physical characteristics that protocols performs in close proximity as well as
SDD and RFCA described in section II-A. To identify the impossibility of MITM
attacks in NFC, let us suppose an environment in which NFC-SEC is not applied
(attackers can perform eavesdropping).
In case Alice is in active communication mode, and Bob is in passive
communication mode: Alice generates RF field and transfers data to Bob. Carol, an
attacker, can prevent Bob from receiving data, while watching the data of Alice. In
this case, Alice can detect an attack and stop key agreement. Though Alice cannot
detect the attack, Carol needs to generate her own RF field to transfer data to Bob.
However, since Alice and Bob are in communication with active-passive mode, Alice
does not reap the RF field until NFC of Bob becomes disabled or removed. Since two
RF fields cannot exist simultaneously according to RFCA, it is impossible for Carol to
transfer data to Bob. Accordingly, a MITM attack is impossible.
In case both Alice and Bob are in active communication modes: If Alice's data
is blocked, Alice can detect attacks as in case of active-passive mode. If not, Alice
comes to reap her own RF field to receive data from Bob, when Carol can generate
her own RF field successfully and transfer data to Bob. However, Alice waiting for
Bob's data can detect attacks after receiving Carol's data. Alice discontinues protocols
after detecting attacks, and Carol's MITM attack fails to get meaningful data. The
SCH service of NFC-SEC performs an integrity check by calculating MacTag through
hierarchy keys. Therefore, a user can be aware of data modulation. The user can
respond to data modulation attacks by asking for retransmission or discontinuing
protocols.
B. Eavesdropping and Data modulation
Eavesdropping on wireless communication is a major threat,which is true in the
NFC. It is generally considered that eavesdropping is difficult in the NFC since the
recognition distance of NFC is within 4 inches. However, there are many factors that

16. 16
can affect recognition distance in the NFC unlike RFID with mere relationship of a tag
and a reader. In particular, eavesdropping is possible up to 10m in active
communication mode and up to 1m in passive communication mode depending on the
performance of attacker's receiver, antenna, and RF signal decoder. An attacker can
modulate data arbitrarily using a jammer in the same situation as in eavesdropping.
The modulated data can be arbitrary data or regular data depending on the purpose of
attackers.
Fortunately, the data that is being transmitted can be easily protected from
eavesdropping by using secure channel. In NFC-SEC, key agreement is performed
through SSE and SCH is generated using the key obtained from results. The user's
data is encrypted when it is transmitted through secure channel, when an attacker only
obtains the encrypted data, and he failsto get meaningful data. The SCH service of
NFC-SEC performs an integrity check by calculating MacTag through hierarchy keys.
Therefore, a user can be aware of data modulation. The user can respond to data
modulation attacks by asking for retransmission or discontinuing protocols.
C. Security Requirement
In response to the security threats covered in this section, NFC security
protocols should satisfy the following properties.
Data Confidentiality
Data Integrity
Unobservability
Unlinkability
Traceability
3.3 TOLLGATE SYSTEM ARCHITECTURE
The proposed architecture of the system consists of three main modules;
i. Mobile Android Application that uses NFC: The NFC enabled smartphone,
which interacts through NFC with the payment terminal, which is also NFC
enabled.

17. 17
ii. Web Service Module: Contains business logic. The Web Service is invoked
from the NFC terminal to process the fee collection from the client when the
smartphone with the application active is tapped.
iii. User Interface Module: This module is used by a new customer to sign up for
the Automated Tollgate Service uses this module. Existing customers use it to
view their history and also recharge their account.
Fig 3.2 – Tollgate System Architecture Diagram.

18. 18
3.4 SUMMARY
This chapter summarizes the operation of Near Field Communication and the
system as a whole. Short descriptions of the different modules of the system were also
included in this chapter.

19. 19
CHAPTER 4
MOBILE ANDROID APPLICATION USING NFC

20. 20
CHAPTER 4
MOBILE ANDROID APPLICATION USING NFC
4.1 INTRODUCTION
The android application that the customer interacts with is a simple application written
in java for the android platform. There are two applications that are needed in order
for the system to function as intended.
i. Client application, which sends the information over NFC to the terminal.
ii. Terminal application, which receives the credentials from the client and calls
the web service to perform its operations.
4.2 Client application
The android application that the customer interacts with has two activities. The first
being a page where they can input the username and password i.e. the credentials used
to login to the system, and the second screen where the NFC Android API is invoked
to initiate transfer to the terminal.
Android allows you to transfer large files between devices using the Android Beam
file transfer feature. This feature has a simple API and allows users to start the transfer
process by simply touching devices. In response, Android Beam file transfer
automatically copies files from one device to the other and notifies the user when it's
finished.
While the Android Beam file transfer API handles large amounts of data, the Android
Beam NDEF transfer API introduced in Android 4.0 (API level 14) handles small
amounts of data such as URIs or other small messages. In addition, Android Beam is
only one of the features available in the Android NFC framework, which allows you
to read NDEF messages from NFC tags. To learn more about Android Beam, see the
topic Beaming NDEF Messages to Other Devices.

21. 21
Fig 4.1 – Login page of client application.
Fig 4.2 – NFC Beam page of client application.

22. 22
4.3 Terminal Application
The terminal application is written similar to the client application. On start, the
terminal application displays an activity, which has NFC Listening ON. This means
that any NFC message that is beamed will be received and processed by the
application.
Android Beam file transfer is used to transfer the credentials from the client
application and the terminal receives the file as an NDEF Message. This NDEF
Message is parsed and the credentials, i.e. the username and password (encrypted) are
stored as Strings. From here the username and password are used as arguments to the
web service, which is invoked as a background service in the terminal application.
This web service is described in greater detail in the forthcoming chapter. The web
service performs processing using this username and password and it returns the
phone number and a message to the customer. These details are received in the
terminal application and are used to send an SMS to the customer with the details of
the transaction carried out, i.e. whether it is a success or not.
Fig 4.3 – NDEF Message structure.

23. 23
Fig 4.4 – Receive NFC message page of terminal application.
4.4 SUMMARY
This chapter in detail has provided the insight for developing an android application
using Near Field Communication (NFC) and explains in detail the steps involved in
sending and receiving the data.

24. 24
CHAPTER 5
TOLLGATE WEB SERVICE

25. 25
CHAPTER 5
TOLLGATE WEB SERVICE
5.1 INTRODUCTION
This chapter is intended to provide a description of the web service that handles the
processing of the customer payment. The following are the
5.2 JAX-WS
JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for
building web services and clients that communicate using XML. JAX-WS allows
developers to write message-oriented as well as RPC-oriented web services.
In JAX-WS, a web service operation invocation is represented by an XML-based
protocol such as SOAP. The SOAP specification defines the envelope structure,
encoding rules, and conventions for representing web service invocations and
responses. These calls and responses are transmitted as SOAP messages (XML files)
over HTTP.
Although SOAP messages are complex, the JAX-WS API hides this complexity from
the application developer. On the server side, the developer specifies the web service
operations by defining methods in an interface written in the Java programming
language. The developer also codes one or more classes that implement those
methods. Client programs are also easy to code. A client creates a proxy (a local
object representing the service) and then simply invokes methods on the proxy. With
JAX-WS, the developer does not generate or parse SOAP messages. It is the JAX-WS
runtime system that converts the API calls and responses to and from SOAP
messages.
With JAX-WS, clients and web services have a big advantage: the platform
independence of the Java programming language. In addition, JAX-WS is not
restrictive: a JAX-WS client can access a web service that is not running on the Java
platform, and vice versa. This flexibility is possible because JAX-WS uses

26. 26
technologies defined by the World Wide Web Consortium (W3C): HTTP, SOAP, and
the Web Service Description Language (WSDL). WSDL specifies an XML format for
describing a service as a set of endpoints operating on messages.
Fig 5.1 - Communication between a JAX-WS Web Service and a Client
Fig 5.2 – JAX-WS Architecture

27. 27
5.3 TOLLGATE SYSTEM WEB SERVICE
The tollgate system web service is called by the terminal on receiving the credentials
from the customer over NFC. These are the arguments to the web method. The
functions of the web method are as follows.
i. The web method receives the username and password from the terminal and
authenticates the user.
ii. Once the user is authenticated, the web method proceeds to check if the
balance in the user account is sufficient to pay the toll fee.
iii. If the balance is sufficient, the service proceeds to deduct the toll fee amount
from the user account and then returns a message indicating the success of the
action.
The web service is implemented using the JAX-WS standard as explained above. The
web service uses JDBC to interact with the MySQL database.
5.4 SUMMARY
This chapter has described the working of the web service, which processes the toll
payment. The next chapter will describe the web interface that will enable a user to
manage their account.

28. 28
CHAPTER 6
WEB USER INTERFACE

29. 29
CHAPTER 6
WEB USER INTERFACE
6.1 INTRODUCTION
The user interface, in the industrial design field of human–machine interaction, is the
space where interaction between humans and machines occurs. The goal of this
interaction is effective operation and control of the machine on the user's end, and
feedback from the machine, which aids the operator in making operational decisions.
6.2 JAVA SERVER FACES (JSF)
Java Server Faces technology simplifies building user interfaces for JavaServer
applications. Developers can build web applications by assembling reuseable UI
components in a page; connecting these components to an application data source; and
wiring client-generated events to server-side event handlers.
Based on a component-driven UI design-model, JavaServer Faces uses XML files
called view templates or Facelets views. The FacesServlet processes requests, loads
the appropriate view template, builds a component tree, processes events, and renders
the response (typically in the HTML language) to the client. The state of UI
components and other objects of scope interest is saved at the end of each request in a
process called stateSaving, and restored upon next creation of that view. Either the
client or the server side can save objects and states.
JSF provides,
Core library
A set of base UI components - standard HTML input elements
Extension of the base UI components to create additional UI component
libraries or to extend existing components.
Multiple rendering capabilities that enable JSF UI components to render
themselves differently depending on the client types

30. 30
Fig 6.1 – JSF Architecture
JavaBeans components as models containing application-specific functionality
and data
A custom tag library for representing event handlers and validators
A custom tag library for rendering UI components
UI components represented as stateful objects on the server
Server-side helper classes
Validators, event handlers, and navigation handlers
Application configuration resource file for configuring application resources
The six phases show the order in which JSF processes a form. The list shows the
phases in their likely order of execution with event processing at each phase.

31. 31
Phase 1: Restore view
JSF begins the restore view phase as soon as a link or a button is clicked and JSF
receives a request. During this phase, the JSF builds the view, wires event handlers
and validators to UI components and saves the view in the FacesContext instance.
Phase 2: Apply request values
After the component tree is created/restored, each component in component tree uses
decode method to extract its new value from the request parameters. Component
stores this value. If the conversion fails, an error message is generated and queued on
FacesContext. This message will be displayed during the render response phase, along
with any validation errors. If any decode methods / event listeners called
renderResponse on the current FacesContext instance, the JSF moves to the render
response phase.
Phase 3: Process validation
During this phase, the JSF processes all validators registered on component tree. It
examines the component attribute rules for the validation and compares these rules to
the local value stored for the component. If the local value is invalid, the JSF adds an
error message to the FacesContext instance, and the life cycle advances to the render
response phase and display the same page again with the error message.
Phase 4: Update model values
After the JSF checks that the data is valid, it walks over the component tree and set the
corresponding server-side object properties to the components' local values. The JSF
will update the bean properties corresponding to input component's value attribute. If
any updateModels methods called renderResponse on the current FacesContext
instance, the JSF moves to the render response phase.
Phase 5: Invoke application

32. 32
During this phase, the JSF handles any application-level events, such as submitting a
form / linking to another page.
Phase 6: Render response
During this phase, the JSF asks container/application server to render the page if the
application is using JSP pages. For initial request, the components represented on the
page will be added to the component tree as the JSP container executes the page. If
this is not an initial request, the component tree is already built so components need
not to be added again. In either case, the components will render themselves as the
JSP container/Application server traverses the tags in the page. After the content of
the view is rendered, the response state is saved so that subsequent requests can access
it and it is available to the restore view phase.
Fig 6.2 – Working of JSF
6.3 JAVA AUTHENTICATION AND AUTHORIZATION SERVICE
The main goal of JAAS is to separate the concerns of user authentication so that they
may be managed independently. While the former authentication mechanism
contained information about where the code originated from and who signed that

33. 33
code, JAAS adds a marker about who runs the code. By extending the verification
vectors JAAS extends the security architecture for Java applications that require
authentication and authorization modules.
Login module:
Login modules are primarily concerned with authentication rather than authorization
and form a widely used component of JAAS. A login module is required to implement
the javax.security.auth.spi.LoginModule interface, which specifies the following
methods:
initialize: Code to initialize the login module, usually by storing the parameters
passed into appropriate fields of the Class.
login: Actually check the credentials provided via an Object that implements
the javax.security.auth.Callback interface (e.g. check against a database). This
method could prompt the user for their login and password or it could use
details previously obtained. It is important to note here that, if invalid
credentials are supplied then a javax.security.auth.login.FailedLoginException
should be thrown (rather than returning false, which indicates that this login
module should be ignored, which potentially allows authentication to succeed).
commit: The identity of the subject has been verified, so code in this method
sets up the Principal and Groups (roles) for the successfully authenticated
subject. This method has to be written carefully in enterprise applications as
Java EE application servers often expect the relationships between the
Principal and Group objects to be set up in a certain way. This method should
throw a javax.security.auth.login.FailedLoginException if authentication fails
(e.g. a user has specified an incorrect login or password).
abort: Called if the authentication process itself fails. If this method returns
false, then this Login Module is ignored.
logout: Code that should be executed upon logout (e.g. could remove the
Principal from the Subject or could invalidate a web session).
Realm Type in tomcat:
JDBCRealm - Accesses authentication information stored in a relational
database, accessed via a JDBC driver.

34. 34
DataSourceRealm - Accesses authentication information stored in a relational
database, accessed via a named JNDI JDBC DataSource.
JNDIRealm - Accesses authentication information stored in an LDAP based
directory server, accessed via a JNDI provider.
UserDatabaseRealm - Accesses authentication information stored in
anUserDatabase JNDI resource, which is typically backed by an XML
document (conf/tomcat-users.xml).
MemoryRealm - Accesses authentication information stored in an in-memory
object collection, which is initialized from an XML document (conf/tomcat-
users.xml).
JAASRealm - Accesses authentication information through the Java
Authentication & Authorization Service (JAAS) framework.
Fig 6.3 – Screenshot of login page.

35. 35
Fig 6.3 – Screenshot of user account managing page.
6.4 PRIMEFACES
Prime Technology is not a software vendor but a software development house along
with the consulting & training activities. A framework that's not even used by its own
creators can easily miss vital points regarding usability and simplicity, a major
difference compared to vendor products is that we use PrimeFaces in all of our clients'
projects as the front end framework. This helps us to view the project from an
application developer's point of view so that we can easily realize the missing features
and quickly fix the bugs. This significantly differs PrimeFaces from other libraries.
PrimeFaces is a lightweight library, all decisions made are based on keeping
PrimeFaces as lightweight as possible. Usually adding a third-party solution could
bring a overhead however this is not the case with PrimeFaces. It is just one single jar
with no dependencies and nothing to configure. Components in PrimeFaces are
developed with a design principle which states that "A good UI component should
hide complexity but keep the flexibility" while doing so.

36. 36
6.5 USER INTERFACE
The user interface facilitates the user in the following ways:
i. It provides a page where the customer may view his/her account balance, and
recharge an amount if needed.
ii. The customer can also view his usage history which shows time, tollgate and
the location.
iii. In an administrator role log in, the admin is able to view history reports, by
tollgate usage or by user. The admin can also lookup a user's history by
searching for the user by his username.
The user interface is a web application and is accessible from any computer. Hence
the user can manage and control his account from anywhere. JAAS has been used to
provide a standard method of login and hence security is also effected. The payment
scheme is left open ended and is out of the scope of this project.
6.5 SUMMARY
This chapter described in detail the web user interface and its building blocks.

37. 37
CHAPTER 7
RESULTS AND DISCUSSION

38. 38
CHAPTER 7
RESULTS AND DISCUSSION
7.1 INTRODUCTION
This chapter shows the results and analysis of the NFC Tollgate System. The
performance can be computed as the time taken in order to complete a transaction at a
terminal and also the startup time of the application server and deploying the actual
application.
7.2 EXPERIMENTAL SETUP
Launching of Apache Tomcat Server 6.0.39:
The web application WAR file was placed in the Apache Tomcat server’s webapp
directory and the server was started multiple times in order to determine the average
startup time.
Cold startup average startup time: 3598.29ms
Warm startup average time: 3023.7ms
(Average of 20 tests for Cold and Warm time each)
Thus it is seen that there is a small delay involved in cold starts of the application
server and subsequent starts are relatively quick.
The testing was done on a MacBook Pro and web pages were tested with Google
Chrome version 33.0.1750.152 in a laboratory environment under normal working
conditions. The application was found to be relatively lightweight and stable under
multiple testing scenarios.
The average load time for the Web User Interface was 250ms.

39. 39
7.3 RESULTS
Activity Duration (in ms)
Android Application Loading < 200 *
NFC transfer < 500 *
Calling Web Service 50 – 2000 **
Return from Web Service 300
Total processing time < 3000
Table 7.1 – Performance results
*The times recorded were on a test device and test computer in a normal usage
scenario. Hence actual results may vary.
7.4 SUMMARY
The performance of the system was summarized in this chapter. Various numerical
data corresponding to the performance were listed and tabulated. These will serve as
benchmarks for future versions of the system and improvements must be made in
these key mentioned areas in order to improve overall system performance.

40. 40
CHAPTER 8
CONCLUSION AND FUTURE WORK

41. 41
CHAPTER 8
CONCLUSION AND FUTURE WORK
8.1 CONCLUSION
We have proposed a new system that enables the collection of user fee at a tollgate
using the emerging NFC technology. The system and all its components are built on
standards such as JAAS for authorization and authentication and AES for encryption.
Furthermore the entire system is built using java and open frameworks, meaning that
it can be easily improved as technologies improve. The framework used to send and
receive messages over NFC for Android are open source and can be adapted to any
existing system and other applications as well. And lastly, with minimal effort the
proposed system can be made compatible with existing NFC Card systems so that new
infrastructure costs may be greatly reduced.
8.2 FUTURE WORK
The Android application is the first area of improvement. Features from the web
interface such as viewing history and ability to recharge can be integrated into the
Android application. A mining system for information stored in the tollgate usage
database may be constructed, which will enable analysis of data regarding usage of the
various tolls. This will give an idea of the traffic patterns and provide useful
information to the highway authorities that will enable better decisions in improving
transport infrastructure.

42. 42
REFERENCES
[1]Widmann, R.; Grunbeger , S.; Stadlmann, B.; Langer , J., “System Integration of
NFC Ticketing into an Existing Public Transport Infrastructure,” NEAR FIELD
COMMUNICATION (NFC) 2012.
[2]E. Haselsteiner and K. Breitfuß, “Security in Near Field Communication (NFC) –
Strengths and Weaknesses”, RFIDSec 2006, Jul. 2006
[3]Madlmayr, G.; Langer, J.; Scharinger, J. “Managing an NFC Ecosystem,” 7th
International Conference on NFC Mobile Business (ICMB), 2008.
[4] Eun, Hasoo; Lee, Hoonjung; Oh, Heekuck. “Conditional Privacy Preserving
Security Protocol for NFC Applications,” IEEE Transactions on Consumer
Electronics, Vol. 59, No. 1, February 2013
[5]Nosowitz, Dan (1 March 2011). "Everything You Need to Know About Near Field
Communication". Popular Science Magazine. Popular Science.