5.3 LA MEMORIA Y LOS SIGNOS

From the previous section, section D.2.1, we have discussed the registration process of the merchant when the merchant registers for DUMP.

Since a merchant is able to use a digital certificate in order to secure their information, the merchant would not be issued an authentication tag containing a tag combination, nor would the merchant be issued a device combination.

At the end of the registration process, the bank creates a DUMP profile for the merchant, which will contain the merchant’s username, the merchant’s registered name (which is the same as the merchant’s distinguishing name on their digital certificate, as illustrated in figure 69 of Appendix F), the merchant’s password, the merchant’s account holder ID (AHID) and the merchant’s account ID (AID).

D.2.2.1 Discussion

Since the digital certificates of both the bank and the merchant would be used, there is no need for the bank to create a tag and/or device combination, since the digital certificates are more than sufficient for authentication and authorisation purposes.

For the purpose of this dissertation and this section, we will discuss only the identification and authentication between the merchant’s server and the bank.

To further secure the identification and authentication process, a two-way handshake would be used between the merchant (from their DUMP server) and the merchant’s bank. The merchant’s version of the DUMP server would create a completely random passphrase, which would first be encrypted with the merchant’s password, and then with the merchant’s bank’s public key. After this, it would be sent (in encrypted form) to the merchant’s bank. Upon receiving the identification and authentication request, the bank would extract, decrypt and re-encrypt the passphrase and would send it back to the merchant’s DUMP server. Ther merchant’s server would then decrypt the received passphrase and compare it to the one which the merchant’s version of the DUMP server sent to the bank. If the comparison succeeds, the merchant is successfully identified and authenticated by the merchant’s bank.

178 As illustrated in figure 64, the identification and authentication request consists of the merchant’s random passphrase, the merchant’s password, the merchant’s username, the default password and the bank’s public key.

The random passphrase the merchant created is encrypted using the merchant’s password, forming part A (of figure 64) of the identification and authentication request. This is then encrypted with the merchant’s bank’s public key, forming part C (of figure 64).

.

In order for the bank to identify the owner of the identification and authentication request, the merchant’s username is encrypted using the default password, forming part B (illustrated in figure 64) of the identification and authentication request

To complete the identification and authentication request, part C (illustrated in figure 64) is combined with part B (illustrated in figure 64)

Upon receiving this identification and authentication request, the bank would decrypt the merchant’s username, thereby identifying the owner of the identification and authentication request.

Using the merchant’s username, the merchant’s bank obtains the merchant’s registered name (which is the distinguishing name of the merchant’s digital certificate (as discussed in Appendix F)), as well as the merchant’s password and public key.

Using its own private key, the merchant’s bank now decrypts part A of figure 64, which contains the passphrase the merchant sent, encrypted with the merchant’s password. Using the merchant’s password, the merchant’s bank can decrypt the passphrase.

Figure 64 Merchant’s Identification and Authentication Information (created by author)

179 The merchant’s bank would create an identification and authentication response, as illustrated in figure 65, which consists of the random passphrase the merchant’s public key. The random passphrase the bank decrypted from the merchant’s identification and authentication request is encrypted with the merchant’s public key, forming the identification and authentication response, as illustrated in figure 65. This identification and authentication response is sent to the merchant.

Upon receiving the identification and authentication request, the merchant would use its own private key to decrypt the identification and authentication response and obtain the passphrase the bank sent back to the merchant.

The merchant would now compare the bank’s version of the merchant’s passphrase, with its own version of the passphrase. If the comparison succeeds, the bank successfully identified and authenticated the merchant. If the comparison fails, the merchant did not use the correct identification and authentication information (such as the merchant’s username and/or password), or the merchant’s digital certificate has expired or is otherwise invalid.

To illustrate the identification and authentication process and construction of the message, the next section will provide an example of how a merchant, Happy Shopping, will proceed to register for DUMP.

D.2.2.2 Example

The previous section provided a discussion on how the registration process for a merchant is created. Unlike the registration for an individual, the registration for a merchant would not result in the creation of a tag combination and a device combination – this security is creating by making use of public key cryptography.

To illustrate this identification and authentication phase, the merchant (Happy Shopping) would use the following information to create an identification and authentication request illustrated in figure 65.

- Random Passphrase: ThisIsTheMerchant’sPassphrase - Merchant’s Username: HS_002@

- Merchant’s Password: HSPWD_@#01 - Bank’s Public Key: 999fBbbcDe33390F - Default Password: DefaultPassword

180 See figure 64 for an explanation on how the data is combined and encrypted in order to create the Identification and Authentication Request. Note that the information contained in figure 66, does not reflect real values, nor does it provide an unsecure reflection of the data – this is only an illustration.

Figure 66 Identification and Authentication Request (created by author)

Upon receiving this identification and authentication request, the merchant’s bank will extract the merchant’s version of the passphrase and the merchant’s bank would use the following information to create the identification and authentication response, as illustrated in figure 67:

- Bank’s version of the merchant’s passphrase: Bank’sVersionOfPassphrase - Merchant’s public key: 333Edfbba1000Cb

See figure 65 for an explanation on how the data is combined and encrypted in order to create the Identification and Authentication Response. Note that the information contained in figure 67, does not reflect real values, nor does it provide an unsecure reflection of the data – this is only an illustration.

181

Appendix E: DUMP Profile

183

Appendix E: DUMP Profile

When an individual registers for DUMP at his bank, the bank would need a copy of the information (such as the tag combination, device combination, username and password) that the bank and individual has created during the registration phase.

This copy would be maintained in a DUMP Profile, which the bank would store in a database located at the bank.

A note should be made that this is a generic discussion of the DUMP Profile. The DUMP Profile would be used for both individual and merchant users however, there are elements the user’s DUMP Profile would contain which the merchant’s DUMP Profile would not contain, and vice versa.

As illustrated in figure 68, besides keeping track of the tag combination, device combination, username and password, the DUMP Profile contains two pointers to the user’s banking profile27.

Figure 68 DUMP Profile (created by author)

27

The user’s banking profile is the profile that the user has with their bank, consisting of all account information, online banking profiles, mobile banking profiles, cellphone banking profiles, etc.

184 One pointer is known as the Account Holder ID (AHID), which is a pointer to the unique identifier that the bank has associated with the individual’s banking profile.

The other pointer is known as the Account ID (AID), which is a pointer to the unique identifier associated with the individual’s primary, or main, account.

The DUMP Profile is constructed in this format, in order to further strengthen the security and confidentiality protocols used within DUMP. This is achieved by storing and using only unique identifiers, thus not actual account information.

Therefore, when the bank communicates with the individual’s or merchant’s version of DUMP, these unique identifiers (along with a limited representation of account information for display purposes) are sent. When the individual’s version of DUMP communicates with the bank, it sends only the unique identifiers to the bank, ensuring confidentiality of information when the communication is intercepted or if security protocols should be compromised.

185

Appendix F: Digital Certificate Layout

187

Appendix F: Digital Certificate Layout

A digital certificate consists of numerous pieces of information in order to determine ownership and validity of the certificate.

Illustrated in figure 69, is only a limited representation of a digital certificate, but important for the use in DUMP.

Figure 69 Layout of a Digital Certificate (adapted from (IBM, 2010))

The distinguishing name (DN) is used to uniquely identify a digital certificate and would be used in the merchant’s version of DUMP to inform the individual’s version of DUMP about the identity of the merchant, in order to decrypt the information that the merchant’s version of DUMP has sent to the individual’s version of DUMP.

The public key of the owner (the merchant), is used to decrypt the information. The individual’s version of DUMP would search for the correct DN in order to obtain the public key.

In order to validate that the digital certificate is valid, the certificate expiry date would be used to verify the lifetime of the digital certificate. If the certificate has expired, no communication can take place. To verify whether a secure digital certificate and not a

188 maliciously created certificate created by malicious users is being used, the digital certificate of the issuing authority would be validated.

Once the digital certificate passed the validations, the information can be encrypted using the merchant’s private key (not present in the digital certificate) and decrypted using the public key.

189

Appendix G: Securing Mobile Applications in

191

Abstract: In rural Africa, where land-based Internet connectivity is a huge

problem due to a lack of infrastructure, wireless Internet connectivity and the adoption of mobile devices are a huge success. However, when it comes to mobile payments, Africa still has a long way to go. The biggest concerns with mobile payment applications are a lack of readily available banks, vendors and other shops that can accept mobile payments, the hostile environment in which mobile devices are being used and the lack of proper electricity provisioning. However, in this paper, we will discuss a mobile payment application that can be used no matter how hostile the physical and logical environments are, where the user can rest assured that their financial transactions are kept secure and confidential.

Keywords: Mobile Devices, Mobile Payments, Mobile Payment Applications,

Security, Near Field Communication, Multi-factor authentication.

1. Introduction

“Africa is the Silicon Valley of banking. The future of banking is being defined here. The new models for what will be mainstream throughout the world are being incubated here. It’s going

to change the world.” – Carol Realini, CEO of Obopay [1]

The year is 1998, Africa has less than 4 million mobile devices in use, whilst Europe got introduced to cellular devices as early as 1981, with the rest of the world following suit not long after [1][2].

Let’s move forward to the present date, Africa now sees more than 500 million mobile devices [1].

This sudden rise of mobile devices can be linked to a poor infrastructure implementation, since Africa – in a majority – is a rural and/or poor continent, there are no sufficient financial backings to implement proper infrastructure for Internet connectivity.

However, socioeconomic conditions also played a major role in the sudden rise of mobile devices [3]).

The major problem in Africa – besides infrastructure – is the sparseness of banks. Rural people do not all have the means of saving money and having bank accounts in order to store money safely, nor do they all have the means of requesting for financial aid from family members living in different countries – besides receiving money via the postal service, which could very easily become expensive [3].

However, with the introduction of mobile devices, Africa saw a major change – and even a new trend. This change addresses the very problem mentioned earlier – the lack of banking facilities, bank accounts and receiving financial aid.

Numerous organisations started investing in developing and creating mobile payment and mobile banking applications, which quickly solved the socioeconomic problem. M-Pesa, a mobile banking application developed by Safaricom, is seeing great success. Using M-