4.2 Application Architecture
4.2.2 Server Architecture
The Mobile Banking Platform Server consists of the Business Logic Server (BLS), the Authentication Server (AS), the Key Management Server (KMS), and the Business Trans-action Log Server (BTLS). Figure 4.9 illustrates the architecture of the mobile banking platform server.
• Key Management Server: KMS in the mobile banking platform server is in charge of the storage of the public key, and initializing renewal process of a key pair. If the clients decide to use a mobile banking service, the first step is to invoke KMS module in the mobile client to generate the key pair in addition to installing the client application software. Distributing the key is a separate procedure from business op-erations. For the key pair of the digital signature, the public key is sent from the mobile client to the mobile banking platform server while the private key is stored in the mobile client. After receiving the public key, KMS stores it, as well as the client personal information. During the payment transaction, when key verification proce-dures ask for a public key, it is provided by KMS. KMS is responsible for generating
Mobile Banking Platform Server
Http(s) Req/Rep
Business Req/Rep
Log Operation
Key Application & Distribution
Banking Biz Job Http(s) Req/Rep
Figure 4.9: The mobile banking platform server’s architecture.
the encryption and decryption public key, saving one copy in the server and sending the other one to the mobile device. The key pair has a life cycle. When the key pair needs renewing, KMS is responsible for sending a command to initiate a renewal procedure in the mobile client application.
• Authentication Server: AS provides the authentication service for the mobile banking platform server. The following security duties are operated in AS:
1. Checking for username/password legality during log on, 2. Verification of the digital signature, and
3. Decryption of message(s).
Any message passing through the AS is a legal business message, so it can be sent to BLS for processing.
• Business Logic Server: BLS handles all legal business requests. BLS interacts with the regular bank to process business logic and to exchange business information.
When BLS has finished processing a business job, it responds by sending the result-ing information to the client’s mobile device.
• Business Transaction Log Server: BTLS is the component realizing the distributed transaction log strategy, which contributes to maintain non-repudiation. It creates and maintains the log files for transactions. BTLS is indicated by a broken line boundary in Figure 4.9, as BTLS is located in the mobile banking platform server logically rather than physically. The transaction log is physically positioned on the wireless network gateway. As shown in Figure4.1, the network gateway is a physical facility maintained by the mobile network operator.
SA2pMP is an architecture proposed in this thesis for protecting the security for two-party mobile payment transactions. To evaluate SA2pMP’s performance in security and practicality, a series of simulations are conducted. In the next chapter, details for system simulation are introduced.
Chapter 5
System Simulation
In this chapter the system simulation is explained. A mobile bank is employed as a scenario for system simulation. The proposed architecture, SA2pMP is implemented to facilitate a
“money transfer” banking transaction. The hardware and the software environments for system simulation are described in Section5.1, followed by an introduction of the specific implementation in Section5.2. Finally, the evaluation of the system simulation is described in section5.3.
5.1 Simulation Environment
In this section, the computer environment for simulating SA2pMP is described.
As illustrated in Table5.1, the present simulation is operated on an IBM IntelliStation M Pro PC, with Pentium 4 CPU 2.80 GHz and 2 GB RAM. The operating system is Windows XP Professional SP3.
Since the goal of the implementation is to enable SA2pMP to run on a typical Java ME enabled mobile device, three mobile device emulators were chosen for the simulation. All three support Java ME. These mobile device emulators are the Nokia S60 Emulator (Nokia, 2009), the Sony Ericsson Emulator (Sony Ericsson, n.d.), and the Sun WTK 2.5.2 CLDC simulator (Sun Microsystems, 2009). The simulators support the Device Configuration of CLDC-1.1 and the Device Profile of MIDP-2.0. For the simulated banking server, a Java Platform, Enterprise Edition (Java EE) application is implemented on an Apache HTTP Server 2.2, cooperating with Tomcat 5.0. A MySQL Server 5.1 serves as the database server.
Table 5.1: The simulation environment.
Item Requirements
Hardware IBM IntelliStation M Pro:
Pentium 4 CPU 2.80GHz RAM 2.00GB
Operating System Windows XP Professional SP3
Banking Server Apache HTTP Server 2.2 Tomcat 5.0
MySQL Server 5.1
Mobile Client Nokia S60 Emulator and Sony Ericsson Emulator and
Sun Java Wireless Toolkit 2.5 for CLDC Simulator:
Device Configuration as CLDC-1.1 Device Profile as MIDP-2.0
Development Tools NetBeans 6.0 Eclipse 3.4.1 BouncyCastle 1.41
The simulation system was developed on NetBeans IDE 6.01and Eclipse SDK 3.4.12. NetBeans IDE 6.0 was used as it integrates well with the emulators. In addition, the visual MIDlet designer in NetBeans IDE 6.0 enables developers to design a business logical pro-cess easily. The implementation of cryptography algorithms (AES, SHA-1 and ECDSA) was done with help from the third party cryptography API provider Bouncy Castle3. Sub-section5.1.1gives a brief introduction to Bouncy Castle.