1

AN AUTOMATED TOLL COLLECTION SYSTEM

BASED ON NEAR-FIELD COMMUNICATION

CHAPTER 1

INTRODUCTION

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

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

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

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

7

CHAPTER 2

LITERATURE SURVEY

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

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

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

CHAPTER 3

SYSTEM DESIGN

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

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

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

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

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.

x Data Confidentiality

x Data Integrity

x Unobservability

x Unlinkability

x 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

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

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

CHAPTER 4

MOBILE ANDROID APPLICATION USING NFC

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

Fig 4.1 – Login page of client application.

Fig 4.2 – NFC Beam page of client application.

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

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

CHAPTER 5

TOLLGATE WEB SERVICE

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

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

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

CHAPTER 6

WEB USER INTERFACE

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,

x Core library

x A set of base UI components - standard HTML input elements

x Extension of the base UI components to create additional UI component

libraries or to extend existing components.

x Multiple rendering capabilities that enable JSF UI components to render

themselves differently depending on the client types

30

Fig 6.1 – JSF Architecture

x JavaBeans components as models containing application-specific functionality

and data

x A custom tag library for representing event handlers and validators

x A custom tag library for rendering UI components

x UI components represented as stateful objects on the server

x Server-side helper classes

x Validators, event handlers, and navigation handlers

x 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

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

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

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:

x initialize: Code to initialize the login module, usually by storing the parameters

passed into appropriate fields of the Class.

x 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).

x 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).

x abort: Called if the authentication process itself fails. If this method returns

false, then this Login Module is ignored.

x 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:

x JDBCRealm - Accesses authentication information stored in a relational database, accessed via a JDBC driver.

34

x DataSourceRealm - Accesses authentication information stored in a relational database, accessed via a named JNDI JDBC DataSource.

x JNDIRealm - Accesses authentication information stored in an LDAP based directory server, accessed via a JNDI provider.

x UserDatabaseRealm - Accesses authentication information stored in anUserDatabase JNDI resource, which is typically backed by an XML document (conf/tomcat-users.xml).

x MemoryRealm - Accesses authentication information stored in an in-memory object collection, which is initialized from an XML document (conf/tomcat-users.xml).

x JAASRealm - Accesses authentication information through the Java Authentication & Authorization Service (JAAS) framework.

Fig 6.3 – Screenshot of login page.

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

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

CHAPTER 7

RESULTS AND DISCUSSION

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

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

CHAPTER 8

CONCLUSION AND FUTURE WORK

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

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.