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
[email protected], [email protected],
[email protected], [email protected], [email protected]
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.