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 1.1 PC Security Issues 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.
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 phonebased 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 Display
Operating System
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
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
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
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
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. Secure Display Device
Transaction details via BluetoothTM
Account Profile
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 endto-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-today 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. Banking
Encrypted data
Shopping
Account Profile
Transaction result Mobile Handset
Ticket
Bank Server Payment
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
Send profile via BluetoothTM
Encrypted data
Transaction result Bank Server Mobile Handset
Secure Display Device
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
used to send transaction results to the display device. This module can be modified to output the signal to a TV. Transaction details via BluetoothTM
Encrypted data
Black Box
Transaction result
Conventional display device (TV, VDU)
Mobile Handset
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.
Bank Server
5.2 Other Use Cases 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.
VGA Output Module (eANSI)
BluetoothTM Transceiver Module
eANSI Control Code Process Engine
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.
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
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/wirms/, 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/13849017p14688971c.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.
