Secure Display and Secure Transactions Using a Handset

Sandeep Singh Ghotra, Baldev Kumar Mandhan,

Sam Shang Chun Wei, Yi Song, Chris Steketee

School of Computer and Information Science,

University of South Australia

sandeep.ghotra@yahoo.com, mandhank@yahoo.com,

ShangChun.Wei@postgrads.unisa.edu.au, songirene@yahoo.com, Chris.Steketee@cs.unisa.edu.au

Abstract

The security risks of using standard personal

computers and operating systems for confidential

transactions such as Internet banking are well-known.

This is one reason for the interest in the mobile phone/

handset as a Personal Trusted Device (PTD). However,

mobile phones have other shortcomings, for example the

constraints of working with a small screen. This paper

explores the use of a dedicated device – a Secure Display

Device (SDD) – which, when used together with a mobile

phone, combines the security of the phone as PTD with

the characteristics, such as large display size, that can be

offered by non-portable hardware.

We describe three prototype SDD systems which we

built in order to test these ideas. Two of them use a

simulated SDD implemented entirely in software on a

personal computer: a Mobile Banking system in which

the SDD is used for its display capability, and a Payment

System in which the SDD is an Automatic Teller Machine.

In addition, we describe our work on a prototype

hardware-based implementation of the Mobile Banking

system that can be plugged into a standard computer

monitor or TV. We conclude by analysing the lessons

learnt and canvassing further use cases for SDD systems.

1. Introduction

Internet banking in recent times has proven to be a

widely accepted method of checking and transferring

electronic funds. It offers a 24-hour, 7-day-a-week

service, with the further advantage of access from

anywhere that the Internet is available. However, there

are many security and fraud issues when using a Personal

Computer (PC) to perform Internet banking [17], leading

to personal information being compromised and funds

stolen [12]. Security risks are also present with the use

of Automatic Teller Machines (ATM’s) in public places.

1.1 PC Security Issues

When using PC’s to carry out Internet banking,

viruses, worms and other malware present a major threat

to the security of the transaction. Software known as

Key-Loggers can record a user’s keystrokes, revealing

account numbers and Personal Identification Numbers

(PINs) used to gain access to bank accounts without the

user’s awareness [17].

If the user’s PC is compromised, then potentially

another security issue is that of misleading transaction

data. In this scenario the transactions displayed on a

user’s computer may not be the ‘real’ transaction taking

place at the server.

Another well documented security risk is phishing

websites [17]. These websites are masked as legitimate

bank portals and lure users to enter account details to

illegally gain access to their accounts. Phishing websites

are usually spread via malicious programs or are valid

looking links to bank websites in spam emails [17].

These factors make the personal computer unsuitable as a

trusted platform for internet banking.

1.2 ATM Security Issues

A security threat to our daily banking is linked to the

ATM. There are cases of security fraud where fake

ATMs are intentionally installed to record banking

information. Moreover there are cases where ATMs

were found with fraudulent card readers or digital video

recorders. These devices were used to record card

information to gain access to bank account information

[19].

1.3 Secure Display Device

In this paper we propose an approach which uses a

mobile phone/ handset, in conjunction with a specialised

Secure Display Device (SDD), for high-security personal

applications such as Internet banking and the use of an

ATM. The mobile phone is an appealing platform for

personal applications: most users carry it everywhere, it

is personalised, it has the ability to connect to the Internet,

and it does not suffer from the malware problems that

beset the PC world. On the other hand, the mobile phone

has shortcomings as well: wireless communication is

inherently insecure, and the limited display size can make

for an unsatisfactory user experience.

By designing systems which combine the use of a

mobile phone with a Secure Display Device (SDD) that

has a larger display area, we aim to achieve a better user

experience than is possible with the mobile phone alone,

with equal or better security. Whereas the mobile phone

is portable, the SDD need not be, and so can have a large

display, and, if required, a wired network connection. In

our use cases, it may be located in a public place (e.g. as

a modified ATM), in a semi-public place such as a hotel

room, or privately in the home.

To achieve the properties required of a trusted

platform [1], the SDD should be a custom-built device

with all operations performed by firmware, and use

cryptographic techniques including Public Key

Infrastructure (PKI) and Password Authenticated Key

Exchange (PAKE) for confidentiality and authentication.

This paper describes two proof-of-concept

implementations: one provides the full SDD functionality

but is implemented in software running on a standard PC,

the other is a simple hardware implementation that

contains no software and no security functions. A

complete SDD for commercial deployment would

combine elements of both.

2. Related Work

The term Personal Trusted Device (PTD) is widely

used to indicate a portable device – ranging from a smart

card to a smart phone or PDA – that is personal to a user,

and can be trusted by the user for some purpose.

Veijalainen et al [20] canvas a broad range of

applications, and concentrate on the security and privacy

issues these raise for PTD’s. In particular, they consider

the consequences of loss / theft of the PTD, and

recommend measures such as encryption of data stored

on the device, backup via a network connection, and

partitioning of data between the PTD and another site so

that both partitions are required in order to reconstitute

the data.

Porras et al [14] report on the experience of

prototyping three diverse applications of the PTD

concept on a mobile phone: access control, a personal

direction finder, and a fitness system. The access control

application makes use of digital signatures based on a

Public Key Infrastructure (PKI) in order to authenticate

the PTD.

Weippl and Essmayr [21] consider the use of a PTD

for applications based on Web services, and propose that

the security of this type of application be based on the

use of Multi-Level Security for the Operating System of

the device.

Bao [2] concentrates on the use of a PTD for ticketing

(e.g. airline ticket) applications, and uses digital

signatures (and implicitly, a PKI) to prevent forgery of

the tickets.

The ability to use a mobile handset for Internet

banking is offered commercially by many banks, making

use of a variety of mobile technologies including phone-

based browsers, JavaTM

applications and SMS. At the

current state of development, there is a lack of

standardisation and therefore interoperability. A

potential problem with all such systems is the limitations

imposed by the small screen size.

de la Puente et al [7] propose to address the problem

of insecure personal computer systems for banking

transactions, corresponding to our Mobile Banking case,

by making use of a special-purpose digital signer device

together with the personal computer. In their system, the

signer device computes and displays a signature of data

displayed by the computer: the user manually enters this

signature into the computer, which sends it to the bank

for authentication. The signature is based on symmetric

encryption mechanisms and requires that each signer

device have a unique secret key, which is shared with the

bank. In order to send the data to be signed to the device,

it is displayed in a specially coded form on the computer

screen, from which it is read by photodiodes on the back

of the device. They comment that improvements to their

system could come from the replacement of this

communication mechanism by two-way BluetoothTM

communication, and replacing the symmetric signature

mechanism with one based on public key cryptography.

Without further analysis it is not clear whether this would

deal fully with the inherent insecurity of a system based

on current PC technology.

Oprea et al [13] also studied the use of a PTD

together with a public terminal, but in their case an

untrusted terminal. Their use case allows a user to access

a home PC via a remote desktop running on the untrusted

terminal. All input (keyboard and mouse) is provided by

the PDA, with the terminal restricted to displaying output.

This ensures that sensitive input data such as passwords

are not exposed to the terminal. However, sensitive

output is not protected in this system, so there is potential

for the untrusted terminal to capture output and to alter

output before displaying it. This would be unacceptable

for our Mobile Banking use case. The system does not

appear to be suitable at all for our Payment System use

case.

On the other hand, Oprea et al’s remote desktop use

case could be implemented more securely with our

Secure Display System (SDD) approach. The SDD for

this case could include keyboard and mouse as well as

display output, so that all functions after initialisation

would be performed on the SDD only. The PTD would

be used (a) to validate the trustworthiness of the SDD via

its public key certificate, (b) to provide login credentials

to the remote computer, and (c) to ensure that the remote

desktop session is dropped once the PTD is removed

from the vicinity of the SDD.

Cheng et al [6] discuss the problem of fake terminals,

such as ATM’s, set up to fool users into revealing

personal information such as banking card PINs. This is

the problem that we address in the Payment System use

case. As in our system, the PTD and bank server set up a

secure channel to communicate via the terminal, and use

a digital signature scheme to authenticate the terminal.

The authors confine themselves to discussing alternative

authentication protocols, and do not appear to have

implemented a prototype.

3. Building and Using a Secure Display

Device

This section provides details of the technologies used

and how SDD is implemented. Figure 1 shows the

components in a SDD.

BluetoothTM

Module

Dedicated Network Link

(PS)

Firmware Digital

Certificate

Secure

Memory

Operating

System

Display

Figure 1. SDD components

3.1 Mobile phone as secure platform

Mobile phones are no longer used just for voice

communication and for messaging but are increasingly

utilised as a general purpose computing device. Users of

mobile phones have rather different opinion than PC

users regarding device security and reliability. Since a

mobile phone is regarded as a personal belonging, there

is a higher degree of trust as a reliable and secure

repository for one’s personal data [9].

There are some significant advantages of mobile

phone over computers as they are less prone to security

threats such as virus attacks, malware and keyboard

loggers [22]. For these reasons we can treat the mobile

phone as a more secure platform for our applications.

3.2 Secure Display Device

A Secure Display Device (SDD) is a purpose-built

device, which has a large screen for displaying

information and BluetoothTM

for communication with the

mobile handset. There is no permanent storage for user

data and all transaction details are stored in temporary

volatile memory. The operating system and application

software is embedded in firmware. The device is

tamperproof to prevent modification or extraction of

information from the embedded firmware. All

communication with the handset is encrypted. At the end

of a session the SDD returns to its original state by

erasing all user data.

Since a SDD may be set up in a public place, it is

necessary to take measures to authenticate that the device

is genuine before trusting it. For example in our Payment

System (PS) the SDD is a modified ATM, and there is

potential for criminals to set up a fake SDD which is

identical in appearance to a real one. To defend against

this, the SDD has a public-private key pair and a

corresponding digital certificate [15], which the handset

uses to challenge the SDD to prove that it is genuine.

The SDD has a secure and tamper-resistant module to

store secrets such as its private key.

3.3 BluetoothTM Communication

Having a separate SDD requires communication

between the mobile handset and the SDD. There were

many options available for wireless communication

including WiFi and BluetoothTM

. However, as the

application's target was the mobile handset, BluetoothTM

was the best available choice for the application.

BluetoothTM

is a wireless technology which provides the

benefits of omni-directionality overcoming the line of

sight problem. Our solution involves transfer of sensitive

data between the mobile handset and the SDD; it is

required to transmit the data securely on the BluetoothTM

channel. As a wireless technology, BluetoothTM

has

security vulnerabilities and there are known

shortcomings in BluetoothTM

security [5, 18]. For this

reason, we perform authentication and encryption at the

application level, using both Public Key Infrastructure

(PKI) and Password Authenticated Key Exchange

(PAKE) [15].

3.4 Digital Certificate

The proposed solutions require the display device to

be authenticated before data can begin being transmitted

to it. This authentication is required as all data displayed

is highly sensitive. We authenticate the SDD by using

digital certificates [15].

In our application digital signature verification is used

for the mobile device to verify all the SDD’s involved in

this system. The mobile device will use this technology

to make sure that it connects to a genuine SDD. Each

SDD in our system will be issued with a unique digital

certificate which will be signed by a Certificate Authority

(CA) using CA’s private key. Our mobile application

contains a root certificate provided by the same CA

which contains the corresponding public key. This

public key will be used to verify the digital certificate

issued to the SDD.

The second scenario in which the digital certificate

will be used in our application is when the mobile

application gets locked. This occurs when logging into

the application more than three consecutive times with an

invalid application key. Under these circumstances the

user needs to present their mobile handset to the bank for

resetting. The handset verifies that it is connected to a

valid bank server using the certificate presented by that

server.

3.5 Password Authenticated Key Exchange

(PAKE)

In the case of Internet banking, when a user attempts

to connect to a bank server to access online services they

are prompted to enter their account PIN, which then is

transferred to the bank server for verification. This

procedure is vulnerable to known attacks, and in order to

overcome this issue, a mechanism called PAKE is used

in our application. PAKE [3, 4, 10, 11] is a protocol that

allows different parties to verify each other and share a

common session key for encryption. The protocol does

not require passwords to be transmitted which is

particularly useful for protecting bank account PINs.

This protocol uses the Diffie-Hellman algorithm to

generate a session key based on a shared secret account

PIN [3]. So every time the user tries to connect to the

bank server, the application uses PAKE to verify the

identity and generate a unique session key. Moreover

PAKE is a two way authentication protocol, so not only

the identity of the user is verified, but the application also

makes sure that the user is connected to a genuine bank

server.

3.6 Secure Data Storage

As our application involves banking transactions,

security of data is vital. Apart from data security during

the communication, there is a requirement for the

security of the data which will be stored on a device. In

our application different kinds of data are stored on the

device such as the application access PIN, the user's

account number and receipts of the transactions. Some

of this data is critical such as the application access PIN

which can not be compromised. To store data the Record

Management System (RMS) is utilised. The RMS from

the Mobile Information Device Profile (MIDP) provides

persistent storage facilities for JavaTM

Midlet applications

[8]. However, RMS architecture stores the data in plain

text and this is not acceptable when applications need to

store the PIN. To overcome this problem, the application

PIN is not stored directly into the record store, but

instead a hash of the PIN is calculated and stored. This

scheme depends on the property of pre-image resistance

– given a hash value, it is infeasible to find the PIN that

will produce this hash value. This approach is however

vulnerable to a brute-force or dictionary attack for an

attacker able to access the hashed value directly, and a

better solution would make use of secure memory

hardware available on many more recent phones.

3.7 Session Overview

The implementation of our use cases involves all the

equipment and techniques mentioned above. There are

three major common phases for a user session:

Initialisation, Process Transaction and End Session.

Figure 2. Phases of a session

The initialisation phase includes the user login. In

this phase the application PIN is entered into the mobile

handset and verified against the stored hash value of

application PIN. The next step in the initialisation phase

is to connect to SDD. The SDD is authenticated using

PKI before a secure connection is established. In the

final step of the initialisation phase a session is

established between user’s mobile handset and bank

server. In this step we are using PAKE which verifies

the identity of the user and bank server based on a shared

secret account PIN. As a part of this protocol we

generate a session key used to encrypt all the traffic

hereafter.

The second phase in our application is the processing

transaction. In this step the user selects their desired

service from the menu displayed on the SDD using

mobile handset. The user is prompted to enter all the

relevant information required for the transaction which

then gets forwarded to the bank server. The bank server

accepts and processes the request, and generates the

transaction result in an Extensible Markup Language

(XML) format. The XML is then sent back to the user

through our encrypted channel. In the last step of this

phase the user receives the result from the bank server

and displays the results on the SDD.

The last phase is the end session phase, which

includes clearing all the session data and ending the

application. When the user selects to exit the application,

a request is sent to the bank server clearing all the session

data including the session key used for encryption.

Additionally an end session request is sent to the SDD,

which clears all the data for that particular session and

resets itself back to the initial state for the next session.

3.8 Implementation

Figure 3. Black Box connected to a display

Our proof-of-concept implementations are described

in this section. The software implementation consists of

three subsystems – Handset, SDD and Server – which

combine the functionality of two use cases: Mobile

Banking and Payment System. In the Black Box use case,

the SDD software subsystem is replaced by hardware and

the Handset subsystem is modified to interface with it.

All software was written in JavaTM

.

The HS (Handset Subsystem) was implemented using

Sun’s J2METM

and WTK (Wireless Toolkit) version 2.5.

J2METM

does not have a complete cryptographic library.

We also had problems when running the cryptography

routines on some handsets. To solve this issue we used

third party library Bouncy Castle release 133 for PKI and

cryptography.

The SDDS (SDD Subsystem) was implemented using

Sun’s JavaTM

JDK 1.5. JDK does not have a BluetoothTM

library built-in, therefore we had to use a third party

library for BluetoothTM

connectivity with the handset.

The library we used was BlueCove 1.2.0.

The SDD in the Black Box use case was a hardware

implementation. It has a built-in BluetoothTM

module for

communication with handset. A VOM (VGA Output

Module) is used to connect to a VGA (Video Graphics

Array) display. The VOM is able to take eANSI

(embedded American National Standards Institute) code

as display instructions. The Black Box does not yet have

built-in security hardware for cryptography: this is left

for future work. However the partial implementation is

useful to demonstrate what such a device looks like and

how it can be used.

The SS (Server Subsystem) was implemented using

Sun’s JAVATM

JDK 1.5 and JBoss 4.0.3. The backend

banking database uses MySQL 5.0.18. The Certificate

Authority used by our system is implemented with

OpenSSL 0.9.7a. The CA uses a 4096-bit private key,

and each SDD has a 1024-bit private key, stored in a

password-protected JavaTM

key store, and a public key

certificate signed by the CA.

Communications between the different parties are

encrypted using RC4 (Rivest Cipher 4) [16]. Once each

party is authenticated using PKI or PAKE, a 128-bit

session key is generated for that session. All subsequent

communication is encrypted using that session key. The

key length can be easily increased beyond 128 bits in the

future for better security.

4. Use Cases

Three systems were built to trial the proposed

solution: Mobile Banking System (MBS), ATM/Payment

System (PS), and Black Box MBS. All these systems use

SDD’s (viewed as trusted platforms) that communicate

with a mobile handset and display details of transactions.

The functionality of the SDD differs between the PS and

MBS applications. In the PS the SDD is used for paying

and cashing out at public places: it is connected directly

to the bank server using a dedicated communication line

Bank Server

Shopping

Banking

Ticket

Payment

Account

Profile

Encrypted data

Transaction result

Send profile via

BluetoothTM

Mobile Handset Secure Display Device

and communicates with the handset via BluetoothTM

. In

the MBS the SDD is used for displaying a service menu

and transaction details. In this case the SDD does not

communicate with the bank server, but instead receives

data for display from the handset via BluetoothTM

.

Details of each system are described below. It should

be noted that our implementations are proof-of-concept:

we have not built a complete SDD. The MBS and PS

implementations simulate the SDD in JavaTM

software

running on a standard PC, and so are no more secure than

a PC. The Black Box MBS implementation demonstrates

the ability to implement the SDD as custom hardware,

but does not include any security functions.

4.1 Mobile Banking System

The Mobile Banking System is intended for use in

private places such as the home, office or hotel room. In

this system the handset connects to the bank server over

the air to carry out the transaction. The SDD is used to

show transaction details, progress and results. This

system is similar to performing Internet banking using a

PC, but a mobile handset is utilised instead.

Figure 4. Mobile Banking System

When the handset connects to the bank server, they

perform mutual authentication using PAKE. This

process allows the bank server to identify and

authenticate the user, but more importantly the user

authenticates the bank server. This process eliminates

the phishing website problem. The session then proceeds

as illustrated in Figures 2 and 4, using the SDD instead of

the handset to display the data.

4.2 ATM/Payment System

The Payment System is a proximity application: a

person needs to be physically near the ATM to access it.

The security requirements for proximity applications are

different to remote applications (e.g. MBS). One of the

advantages is that it is much more difficult to hack into

the system from a remote location. The user needs a

security token such as debit card and account PIN to

access the account. Therefore even though PS is used in

public place, the system is still secure.

Unlike the MBS, the Payment System does not

require the mobile handset to have an Internet connection

to complete the transaction. The handset communicates

with the SDD (ATM) via BluetoothTM

, and the SDD is

connected to the bank’s private network.

Communication between the handset and the bank server

uses the SDD as a gateway, with PAKE providing end-

to-end encryption between them. In addition the bank

server communicates with the SDD directly – ie: to

display information on the SDD or to instruct it to

dispense cash. The purpose of the mobile handset is to

provide a more secure way of authenticating the user than

a normal banking card. This increased security comes

from the use of digital certificates to authenticate the

trustworthiness of the SDD, as well as the secure

encrypted storage of user account data on the handset.

The Payment System offers a variety of payment

services to the user. For example, a bank ATM with a

display can act as a SDD and permit a user to verify their

identity to the bank server. In addition to normal day-to-

day banking such as cash withdrawal, the PS could

potentially be used for added-value services such as

shopping, topping up phone cards, purchasing movie

tickets etc. These services require the banks to work in

conjunction with other service providers. The PS

provides a framework for additional services to be added

easily and flexibly.

Figure 5. Payment System

4.3 Mobile Banking System (Black Box)

Black Box MBS is a hardware implementation of the

MBS. The idea is to utilise existing display devices like

TV’s or PC monitors as the output of the SDD. The

Black Box hardware adds SDD ability to conventional

display devices, but is small enough to be portable.

A BluetoothTM

receiver module is embedded within

the black box to communicate with the mobile handset

using wireless technology. A VGA output module is

Transaction details

via BluetoothTM

Transaction result

Encrypted data

Bank Server

Account

Profile

Secure

Display

Device

Mobile Handset

Black

Box

Transaction details

via BluetoothTM

Transaction result

Encrypted data

Mobile Handset Bank Server

Conventional

display device

(TV, VDU)

used to send transaction results to the display device.

This module can be modified to output the signal to a TV.

Figure 6. Mobile Banking System (Black Box)

The black box utilises existing hardware and is

cheaper to make and quicker to deploy than a SDD that

contains a screen. It is also portable; therefore the user

does not have to rely on third parties like hotels or

airports to install a SDD for the user. With the black box,

the user can use a TV in a hotel room or a computer

monitor in the office to perform secure transactions.

This prototype does not implement security features

such as authentication and encryption found in the

software prototypes. The hardware prototype was used

for proof of concept. The prototype demonstrates how

the final product looks like and how it can be used. The

implementation of the security features remains for future

work.

Figure 7. Inside Black Box

5. Future Work

Secure transactions using a SDD is a relatively new

idea. Although three systems were successfully

developed, there is still much work to be done.

5.1 Improvements

The SDD is considered as special purpose built

hardware and in the early prototypes the devices show

promising results. Two of the prototypes use software to

emulate the SDD, hence more hardware implementations

should be considered and tried to further enhance

security, cost and reliability.

All the systems use mobile handset keypads as input

devices: these can be difficult to use when entering

alphanumerical information. To better this situation,

accessories such as external keyboards or pointing

devices would improve the user experience.

New security threats emerge all the time. To make

sure the system remains safe and secure, the security

protocol should be constantly reviewed and updated.

5.2 Other Use Cases

The solution proposed in this paper can be used as a

framework for other areas.

• Email is often used for private and confidential

communication. Using this framework helps the

user have more confidence that what is displayed on

the screen is the true content of the email.

• Online shopping is used by increasing number of

people around the world. This framework can help

to complete purchases more securely.

• Remote desktop as discussed in section 2.

All the use cases can be combined to form a full

featured application. For example, as the mobile handset

becomes more powerful, it can handle most tasks and

processing done on a PC. In principle if the PC were

replaced with a mobile handset and a SDD, the user

would have a more secure platform to work with.

Another potential application is to use a mobile

handset as an Internet gateway to provide secure email,

World Wide Web (WWW) and banking needs. Access

to Internet can be very difficult in many regions around

the world due to lack of telecommunication infrastructure.

A device like a black box can be used to connect to a

family TV and allow quick access to Internet through the

mobile handset. This will satisfy most people’s internet

needs such as checking emails, browsing websites and

viewing pictures.

6. Conclusion

Concerns of using Internet banking and ATMs are

increasing due to issues described in this paper. A

solution is proposed by using a trusted device (mobile

phone/ handset) and a Secure Display Device. The

solution is a framework that can also be used in many

other areas such as email and online shopping.

Three systems were built and successfully

demonstrated the capabilities of a secure platform using a

mobile handset and a Secure Display Device. However,

much work still needs to be completed to enhance the

overall user experience. More importantly, to make

VGA Output

Module

(eANSI)

BluetoothTM

Transceiver

Module

eANSI

Control Code

Process

Engine

certain the platform is updated with continuing changing

security requirements for secure transactions.

Special Acknowledgement

This project was carried out while the first four authors

were students at the University of South Australia. The

original idea of “Secure Display and Secure Transactions

using a Handset” was provided by Paul Montague, Glen

Olafsen and John Douglass from Motorola Australia. We

are grateful for the valuable support and feedback

provided by staff of Motorola Australia throughout the

project.

References

[1] R.J. Anderson, “Cryptography and Competition Policy:

Issues With ‘Trusted Computing’”, Twenty-Second ACM

Symposium on Principles of Distributed Computing (PODC

2003) Boston, Massachusetts, 2003, pp. 3-10.

[2] F. Bao, “A Scheme of Digital Ticket For Personal Trusted

Device”, 15th IEEE International Symposium on Personal,

Indoor and Mobile Radio Communications, PIMRC, 2004, pp.

3065-3069.

[3] S. Bellovin and M. Merritt, “Encrypted Key Exchange:

Password-Based Protocols Secure Against Dictionary Attacks”,

Proceedings of the IEEE Symposium on Security and Privacy

1992, Oakland, California, pp. 72-84.

[4] S.M. Bellovin and M. Merritt, “Augmented Encrypted

Key Exchange: A Password-Based Protocol Secure Against

Dictionary Attacks and Password File Compromise”,

Proceedings of the 1st ACM Conference on Computer and

Communications Security, 1993, pp. 244-250.

[5] C. Bisdikian, “An Overview of the Bluetooth Wireless

Technology”, Communications Magazine, IEEE, Dec 2001, pp.

86-94.

[6] C.Y. Cheng, K. Seman, and J. Yunus, “Authentication

Public Terminals Wth Smart Cards”, TENCON 2000, Kuala

Lumpur, 2000, pp. 527-530.

[7] F. de la Puente, J.D. Sandoval, and P. Hernandez,

“Personal Digital Signer For Internet Banking”, 2003 IEEE

Pacific Rim Conference on Communications, Computers and

signal Processing, PACRIM, Aug 2003, pp. 700-703.

[8] S. Ghosh, “J2ME Record Management Store”. IBM, 2002,

http://www-128.ibm.com/developerworks/wireless/library/wi-

rms/, accessed 25 Jan 2007.

[9] C. Heath, Symbian OS Platform Security: Software

Development Using the Symbian OS Security Architecture,

Wiley, 2006.

[10] D.P. Jablon, “Extended Password Key Exchange

Protocols Immune to Dictionary Attack”, WETICE'97

Workshop on Enterprise Security, 1997.

[11] D.P. Jablon, “Strong Password-Only Authenticated Key

Exchange”, Computer Communication Review, 26(5):5--26,

October 1996.

[12] K.J. Hole, V. Moen, and T. Tjøstheim, “Case Study:

Online Banking Security”, IEEE Security & Privacy, 2006, pp.

14-20.

[13] A. Oprea, D. Balfanz, G. Durfee, et al., “Securing a

Remote Terminal Application with a Mobile Trusted Device”,

Proceedings of the 20th Annual Computer Security

Applications Conference (ACSAC'04), IEEE Computer Society.

[14] J. Porras, P. Jäppinen, P. Hiirsalmi, et al., “Personal

Trusted Device in Personal Communications”, 1st International

Symposium on Wireless Communication Systems Mauritius,

2004, pp. 388-392.

[15] A. Salomaa, Public-Key Cryptography, 2nd ed, Springer,

Berlin, 1996, 271.

[16] B. Schneier, Applied Cryptography, Wiley, New York,

1996.

[17] D. Sullivan, The Definitive Guide to Security

Management, 1 ed, Realtimepublishers, Santa Rosa, 2004.

[18] J. Sun, D. Howie, A. Koivisto, et al., “Design,

Implementation and Evaluation of Bluetooth Security”,

Proceedings IEEE International Conference on Wireless LANs

and Home Networks, 2001, pp. 121-130.

[19] C. Swett, “Risk of Debit-Card Fraud Rises”, The Bee,

12/11/2005, pp. A1,

http://dwb.sacbee.com/content/business/story/13849017p-

14688971c.html, accessed 27/1/2007.

[20] J. Veijalainen, M.A. Haq, and M. Matsumoto (2003)

Privacy and Security Considerations for Personal Trusted

Devices. Fifth WIM Meeting, 2003.

[21] E. Weippl and W. Essmayr, “Personal Trusted Devices

For Web Services: Revisiting Multilevel Security”, Mob. Netw.

Appl., 2003, pp. 151-157.

[22] Q. Zhang, J.N.B. Moita, K. Mayes, et al., “The Secure

and Multiple Payment System Based on the Mobile Phone

Platform”, Workshop on Information Security Applications

WISA, 2004.