Mobile Banking Architecture

This two-part series on mobile banking security will help Bank security officers and auditors understand the security threats in Mobile banking. Here, I will present two popular mobile banking architectures and dive into the exchange of messages between the components. Next month, we will look at the threats inherent in this architecture and how to mitigate them.

The concept is different from SMS Banking which was discussed previously. The architecture is based on the specific requirement that the facility is provided through GRPS, GSM, CDMA, EDGE, 3G and CSD enabled mobile phones.

With Mobile banking, the following services can be availed of, but is not restricted to,

• Viewing A/C statement
• Viewing Cheque Status
• Stopping Cheque Payment
• Cheque Book Request
• Fixed Deposit Enquiry
• Bill Payment
• Shopping/ Purchasing items

The services can be provided to customers directly by the bank or through a 3rd party vendor; and explanations for both are followed.

Architecture 1: When the bank provides the service directly to the customer

The setup will have a web server, application server and the database at the bank’s premises. We shall call this the mobile banking server for ease of understanding.

The application will ensure what services are to be provided to the customer. Based on the banking services provided to the customer, the security of the infrastructure has to be built in. The database can be the same as the Core Banking database, having another table for mobile banking users.

The customer uses his/her mobile phones to transact through the mobile network. The Mobile banking server in turn talks to the Core banking systems of the bank for user authentication, processing transactions, authorization, etc.

Architecture 2: When banks outsource this facility to 3rd party vendors

This is the more popular architecture as Banks can quickly roll out their mobile banking solutions by connecting to a 3rd party. This is also the architecture with more security issues as interconnection with a 3rd party is involved. In this architecture, the mobile banking servers are located at the 3rd party vendor’s data centre. These servers will talk to the Core Banking servers of the bank through a secured channel (dedicated or shared link) for authentication, authorization and transaction processing.

Pre requisites to using this facility

The customer has to first register with the Bank for using Mobile banking facility by linking the user’s mobile number with the account number.

Application functionality

The mobile banking facility can be provided to mobile phone users through a client or a web based access. Using the client or web browser, the necessary security features are to be built.

Customer performs banking transactions based the services like check account balance, fund transfer, bill payment, shopping, etc provided by the bank.

Exchange of messages when a 3rd party provides the service to the bank’s customers

User Authentication

1. User uses the browser or the client to connect to the mobile banking server located at the 3rd party site. The connection over the mobile network is encrypted using public/private key. The public keys can be transferred during the client installation on the mobile phone or when the client first communicates with the server using the browser.

2. The mobile banking server asks for authentication. Here, there can be multiple layers of authentication, one authentication for the 3rd party and another for the bank.

   1. The credentials required for the 3rd party should be encrypted by the client-side application using the 3rd party’s public key
   2. The credentials required for the bank should be encrypted using the bank’s public key

   Authentication can be based on both the 3rd party and bank’s credentials or just the bank’s credentials. Choosing the dual or single authentication depends on the role played by the vendor. If the vendor also requires authentication for its records and for other services it provides to customers, then having different authentication mechanisms should be a good idea.

3. If both credentials are required, then user has to register with vendor by providing personnel details like name, e-mail-id, mobile number and bank account number; and creates an ID/PIN for the mobile user. These credentials can be used for authentication with the vendor. If only bank’s credentials are required, then these are encrypted by the bank’s public key and transmitted. The server will then forward the encrypted data to the bank’s server.

   1. If the vendor provides this infrastructure to multiple banks, the bank name should be encrypted using the vendor’s public key, so that it can pass the data encrypted by the bank’s public key to the correct bank.

   The idea behind having different encryption keys is to ensure that only data required by the vendor is accessible only to the vendor and the rest of the data is only available to the bank.

4. Mobile user is authenticated with the mobile banking server at the vendor.

5. The credentials entered by the user which is required for authentication with the bank is forwarded to the bank.

6. The bank authenticates the user and provides a list of services which is available to the mobile banking server.

7. The mobile banking server forwards the data to the mobile user.

User requesting a transaction

8. The user selects the service he wants to perform like check account balance, bill payment, etc.

9. The mobile banking server asks for re-authentication for critical transactions.

   1. Re-authentication with the mobile banking sever ensures that critical transactions are verified and mapped to the user.
   2. The re-authentication can be restricted with the vendor only; the user need not authenticate with the bank every time a transaction is performed. Again this depends on the role played by the vendor.

10. User re-enters the credentials.

11. Server authenticates the mobile user and forwards the data to the bank on how to process the mobile user’s service request.
    For e.g., checking the account balance service, the mobile banking server will contact the bank’s server on how to process the request.

Bank processing the transaction

12. The bank server will ask for details required to service the user request

    1. Taking the above example, the bank will ask for cheque number and this is forwarded by the mobile banking server to the end user.

13. The end user enters the details and sends it to the mobile banking server.

14. The server again asks for authentication. Once authenticated, the mobile banking server will forward the cheque number to the bank’s server.

    1. This can be an optional check based on the criticality of the service requested. For e.g., if the bank provides fund transfer service, then it may be a good idea to again check for the user’s credentials. Again this is purely based on the criticality of the service provided

15. The bank’s server will check the status of the cheque and provide the details to the mobile user via the mobile banking server.

Finally, this is just an example to show how the application should process requests from the mobile user. Based on the services provided by the bank, the security of the application can be built-in. For e.g., if the application allows fund transfer or bill payment, then the required security threats should be identified and mitigated.

In my next article, I’ll be discussing these aspects and also how to mitigate the threats observed while using this facility. The article will focus on security of some services provided by the bank like cheque request, account balance, mobile shopping, etc. Also how data is protected over during transmission and storage will be discussed.

The important part is maintaining Confidentiality, Integrity and Availability while using this facility without comprising on functionality.