a new architecture for secure two-party mobile payment transactions

More documents

Recommendations

Info

$MATH 2000 ASSIGNMENT 6 SOLUTIONS a) B â A iff (âx) [x â B ...$

$MATH 2000 Assignment 4 Solutions 1. a) List of tautologies and ...$

$MATH 2865 â Test 3 (10pts) Problem 4:$

$Solutions to Homework 8 - Math 3410 1. (Page 190: # 5.49(b)) Let a ...$

$Solutions to Homework 6 - Math 2000 The solutions to 3.7,3.15,3.21 ...$

Abstract The evolution of wireless networks and mobile device technologies has increased concerns about performance and security of mobile systems. We propose a new secured applicationlevel architecture for a two-party mobile payment transaction that is carried out between a resource-limited mobile device and a resource-rich computer server over wireless networks. As an example of such transactions, the mobile banking transaction is focused on throughout this thesis. The proposed architecture, namely SA2pMP, employs a lightweight cryptography scheme (combining both a Public-key cryptography algorithm (ECDSA) and a Symmetric-key cryptography algorithm (AES)), a multi-factor authentication mechanism, and a transaction log strategy. The proposed architecture is designed to satisfy the four properties of confidentiality, authentication, integrity and non-repudiation that are required by any secure system. The architecture can be implemented on a Java ME enabled mobile device. The security API library can be reused in implementing other two-party mobile applications. The present study shows that SA2pMP is a unique lightweight security architecture providing comprehensive security for two-party mobile payment transactions. In addition, simulations demonstrate that SA2pMP can be installed in resource-limited mobile devices as a downloadable software application. The main contribution of the thesis is to suggest a design for a security architecture for two-party mobile payment transactions, for example, mobile banking. It suggests a four-layer model of mobile payment participants, based on Karnouskos (2004). This model clarifies how participants are involved in a mobile payment transaction. In addition, an improved model is suggested to guide security aspects of system design, which is based on an Onion Layer Framework (Wei, C.Liu, & Koong, 2006). iv
List of Appended Papers Parts of the thesis have been published in the following papers. Paper A) Rice, J. E., & Zhu, Y. (2009, August). A proposed architecture for secure twoparty mobile payment. 2009 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing. Paper B) Zhu, Y. and Rice, J. E. (2009, August), A Lightweight Architecture for Secure Two-Party Mobile Payment. 7th IEEE/IFIP International Conference on Embedded and Ubiquitous Computing. v
Page 1 and 2: A NEW ARCHITECTURE FOR SECURE TWO-P
Page 3: I wish to dedicate this thesis to m
Page 7 and 8: Contents Title Page Approval/Signat
Page 9 and 10: 4.2.2 Server Architecture .........
Page 11 and 12: List of Figures 2.1 The major mobil
Page 13 and 14: in becoming a successful mobile ser
Page 15 and 16: 1.3 Problem Statement The objective
Page 17 and 18: limited environment of mobile devic
Page 19 and 20: the Record Management System (RMS).
Page 21 and 22: are presented. Chapter 7 This chapt
Page 23 and 24: can provide more convenience, mobil
Page 25 and 26: GSM is limited in its low data tran
Page 27 and 28: Code Division Multiple Access (W-CD
Page 29 and 30: as it does not provide a secured en
Page 31 and 32: 2.3.1 Mobile Payment Overview A mob
Page 33 and 34: Figure 2.1: The major mobile paymen
Page 35 and 36: 2.4.1 Mobile Devices’ Overview A
Page 37 and 38: ian OS are developed using standard
Page 39 and 40: Linux Linux is a Unix-like computer
Page 41 and 42: included in the iPhone SDK agreemen
Page 43 and 44: 2. a profile which is a set of APIs
Page 45 and 46: MIDP occupies the layer above CLDC,
Page 47 and 48: 2.6.1 Authentication: Definition In
Page 49 and 50: 2.6.3 Multi-factor Authentication F
Page 51 and 52: A cryptography algorithm is a mathe
Page 53 and 54: Advanced Encryption Standard The Ad
Page 55 and 56:
The AES algorithm is required to be
Page 57 and 58:
on a paper document (Stallings, 200
Page 59 and 60:
Table 2.2: Applications for DSA, RS
Page 61 and 62:
suitable for securing mobile bankin
Page 63 and 64:
2.7.4 A Comparison of Symmetric-key
Page 65 and 66:
chitecture to provide comprehensive
Page 67 and 68:
mum base memory of 192 KB and a 16/
Page 69 and 70:
produces software components that c
Page 71 and 72:
the financial sector and the client
Page 73 and 74:
3.1.4 Application Layer The current
Page 75 and 76:
The information in the table is exp
Page 77 and 78:
Figure 3.5: An Onion Layer Framewor
Page 79 and 80:
Illustrated in Figure 3.6, the X-ax
Page 81 and 82:
As illustrated in Figure 3.6, the r
Page 83 and 84:
mobile devices, the employment of E
Page 85 and 86:
• Something you are or do: This m
Page 87 and 88:
Chapter 4 System Design This chapte
Page 89 and 90:
• DVeri f y: Denotes the verifica
Page 91 and 92:
the application layer, it focuses o
Page 93 and 94:
crypter were the same sender (Davis
Page 95 and 96:
Encryption Layer SA2pMP utilizes a
Page 97 and 98:
control. 4.1.5 Distributed Transact
Page 99 and 100:
log server is maintained by the mob
Page 101 and 102:
nature does not share anything secr
Page 103 and 104:
is transferred to the authenticatio
Page 105 and 106:
and government systems (Lam et al.,
Page 107 and 108:
Figure 4.7: The mobile banking modu
Page 109 and 110:
key and a public key. It then distr
Page 111 and 112:
the encryption and decryption publi
Page 113 and 114:
Chapter 5 System Simulation In this
Page 115 and 116:
The simulation system was developed
Page 117 and 118:
5.2.1 Business Work Flow The work f
Page 119 and 120:
described as follows: 1. To initiat
Page 121 and 122:
which is used to compare with the d
Page 123 and 124:
Figure 5.2: The variables’ transf
Page 125 and 126:
ackground on the cryptography algor
Page 127 and 128:
The Criteria of Nielsen (1995) Base
Page 129 and 130:
focused on the delay caused by prot
Page 131 and 132:
Figure 5.4: The time delay on Sony
Page 133 and 134:
caused by verifying operation on th
Page 135 and 136:
although some visual or multi-modal
Page 137 and 138:
Chapter 6 System Comparison In this
Page 139 and 140:
uns at over 165 Kbits/s on the Java
Page 141 and 142:
and the end-to-end security mechani
Page 143 and 144:
6.1.4 Secure Electronic Transaction
Page 145 and 146:
end-to-end client authentication, a
Page 147 and 148:
• In comparing the employment of
Page 149 and 150:
• A mobile payment transaction ha
Page 151 and 152:
Although it is impossible to make u
Page 153 and 154:
Chapter 7 Conclusions and Future Wo
Page 155 and 156:
Additionally, the security API pack
Page 157 and 158:
this thesis. However, the transacti
Page 159 and 160:
K E Denotes the secret key for the
Page 161 and 162:
[RK S ,PK S ] Denotes a digital sig
Page 163 and 164:
FIPS FORTRAN Federal Information Pr
Page 165 and 166:
MFA MIDlet MIDP Mobile Device Multi
Page 167 and 168:
SFA SHA SHA-1 SM Smartphone Single-
Page 169 and 170:
References ABI Research. (2007). 20
Page 171 and 172:
Diffie, W., & Hellman, M. (1976). N
Page 173 and 174:
Java Community Process. (2002). Mob
Page 175 and 176:
Microsoft Corporation. (2009). Wind
Page 177 and 178:
Roto, V., & Oulasvirta, A. (2005).
Page 179 and 180:
Tipton, H. F., & Krause, M. (2007).
Page 181 and 182:
Appendix Part of Client Simulation
Page 183 and 184:
24 public class MoBankMIDlet extend
Page 185 and 186:
75 return alert_notes ; 76 } 77 78
Page 187 and 188:
129 / ** 130 * The MoBankMIDlet c o
Page 189 and 190:
167 / / w r i t e post −a c t i o
Page 191 and 192:
208 / ///GEN−BEGIN:∣66− g e t
Page 193 and 194:
251 textAccound = new TextField ( "
Page 195 and 196:
285 / / w r i t e pre−a c t i o n
Page 197 and 198:
Page 199 and 200:
367 / / //GEN−END:∣74− g e t
Page 201 and 202:
409 groupPayto = new ChoiceGroup (
Page 203 and 204:
America / Edmonton " ) );/ / GEN−
Page 205 and 206:
487 * R e t u r n s an i n i t i l
Page 207 and 208:
528 return sucForm ; 529 } 530 / /
Page 209 and 210:
569 loginScreen = new LoginScreen (
Page 211 and 212:
614 return image1 ; 615 } 616 / / /
Page 213 and 214:
656 public Image getImage2 ( ) { 65
Page 215 and 216:
Page 217 and 218:
740 public void execute ( ) throws
Page 219 and 220:
787 / / //GEN−END:∣156− gette
Page 221 and 222:
825 * @return t h e i n i t i a l i
Page 223 and 224:
868 * R e t u r n s an i n i t i l
Page 225 and 226:
913 * @return t h e i n i t i a l i
Page 227 and 228:
962 963 / ** 964 * C a l l e d t o
Page 229 and 230:
24 25 / ** 26 * HTTP CONNECTION TO
Page 231 and 232:
72 } catch ( ClassCastException e )
Page 233 and 234:
13 import org . bouncycastle . asn1
Page 235 and 236:
63 64 65 } 66 67 68 69 / ** 70 * 71
Page 237 and 238:
AES256Crypto package org.yunpu.cryp
Page 239 and 240:
40 private SecureRandom random = ne
show all

a new architecture for secure two-party mobile payment transactions

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?