Department of Computer and Information Science
Examensarbete
Design and Implementation of a Secure In-app
Credit Card Payment System
av
Patrik Bjurling
LIU-IDA/LITH-EX-A--14/057--SE
2014-12-11
Examensarbete
Design and Implementation of a Secure In-app
Credit Card Payment System
av
Patrik Bjurling
LIU-IDA/LITH-EX-A--14/057--SE
2014-12-11
Handledare: Rahul Hiran (IDA), Eero Piitulainen (TaxiCaller)
Examinator: Nahid Shahmehri
§ Smartphones are often used in order to make purchases today and mo-bile payments are estimated to continue growing in numbers the following years. This makes mobile payment systems attractive to companies as a new business platform. It also increases the number of malicious users trying to exploit the systems for financial gain.
This thesis is conducted for the company TaxiCaller which desires to integrate mobile payments into their existing service. It discusses the cur-rent security standards for mobile payments and evaluates existing mobile payment solutions. The focus of the evaluation is on the security of the solu-tions and vulnerabilities, as well as mitigasolu-tions of identified vulnerabilities, are discussed.
Based on the evaluation, a mobile payment solution is designed and implemented. This system fully integrates with TaxiCaller’s existing system. A threat analysis of the implemented mobile payment solution is performed to provide confidence in the security.
This thesis also provides an insight into the ecosystem of mobile pay-ments including the stakeholders, the regulations, the security standards and difficulties during implementations.
Keywords: Android, Credit card, Java, Mobile payment, Security, Smart-phone
I would like to thank my supervisor, Rahul Hiran for all the support and enlightening discussions throughout this thesis.
I would also like to thank my examiner, Professor Nahid Shahmehri for taking the time and giving me the opportunity to have this thesis.
Finally, I express gratitude to my family for all the support they have given me.
1 Introduction 1 1.1 Problem statements . . . 2 1.2 Contribution . . . 3 1.3 Methodology . . . 3 1.4 Company . . . 4 1.5 Desideratum . . . 5 2 Background 7 2.1 Cryptography . . . 7
2.1.1 Internet protocol stack . . . 7
2.1.2 Encryption . . . 8
2.1.3 Symmetric encryption algorithm . . . 8
2.1.4 Asymmetric encryption algorithm . . . 9
2.1.5 Certificate authorities . . . 9
2.1.6 Secure socket layer / transport layer security . . . 10
2.1.7 Tokenization . . . 12
2.2 Payment card industry data security standard . . . 14
2.2.1 History . . . 14
2.2.2 Data security standard . . . 15
2.2.3 Requirements . . . 15
2.3 Other information security standards . . . 18
2.3.1 Health Insurance Portability and Accountability Act (HIPAA) . . . 18
2.3.2 Sarbanes-Oxley (SOX) . . . 18
2.3.3 Discussion . . . 18
2.4 Existing mobile payment solutions . . . 19
2.4.1 Point-of-sale . . . 19 2.4.2 Token . . . 20 2.4.3 Payment device . . . 21 2.4.4 Discussion . . . 21 2.5 Android security . . . 22 2.5.1 System architecture . . . 23 2.5.2 Permissions . . . 23 2.6 Attacks . . . 24
2.6.3 Keylogger . . . 25 2.6.4 Eavesdropping . . . 26 2.6.5 Man-in-the-middle . . . 27 3 Requirement analysis 29 4 Design 33 4.1 Stakeholders . . . 33 4.2 Marketplace . . . 34 4.3 Third-party providers . . . 35 4.4 Paymill security . . . 36 4.5 Component design . . . 38 4.5.1 Interfaces . . . 39 4.5.2 Register card . . . 40
4.5.3 Add a company to the marketplace . . . 46
4.5.4 Payment . . . 47
4.6 Threat modeling . . . 52
4.6.1 Assets . . . 52
4.6.2 Card theft vs impersonating attack . . . 53
4.6.3 Attack strategies . . . 53
4.6.4 Excluded attacks . . . 53
4.6.5 System specific attacks . . . 54
4.7 Discussion . . . 56 5 Implementation 57 5.1 Development Environment . . . 57 5.1.1 Passenger application . . . 57 5.1.2 Server components . . . 58 5.1.3 Database . . . 58
5.1.4 Paymill software development kits . . . 58
5.2 Process . . . 58 5.3 Secure coding . . . 59 5.4 Testing . . . 59 5.5 Delimitations . . . 60 5.6 Difficulties . . . 60 6 Related work 61 7 Conclusion 65 7.1 Study and evaluation . . . 65
7.2 Design and implementation . . . 65
7.3 Conclusion . . . 66
ADB Android Debug Bridge
ADT Android Development Tools
ASV Approved Scanning Vendor
BIN Bank Identification Number
CA Certificate Authority
CDE Cardholder Data Environment
DSS Data Security Standard
GPS Global Positioning System
HIPAA Health Insurance Portability and Accountability Act
IDE Integrated Development Environment
IIN Issuer Identification Number
JSON JavaScript Object Notation
LCD Luhn Check Digit
PAN Primary Account Number
PCI Payment Card Industry
PCI-DSS Payment Card Industry-Data Security Standard
POS Point-Of-Sale
QR Quick Response
QSA Qualified Security Assessor
ROC Report On Compliance
SMS Short Message Service
SOX Sarbanes-Oxley Act
SSC Security Standards Council
SSL/TLS Secure Socket Layer/Transport Layer Security
TCP Transmission Control Protocol
1.1 High level idea of registration of credit card. . . 5
1.2 High level idea of payment flow. . . 5
2.1 Internet protocol stack. . . 8
2.2 Symmetric encryption. . . 8
2.3 Asymmetric encryption. . . 9
2.4 SSL/TLS handshake.. . . 10
2.5 Square point-of-sale solution. . . 19
2.6 LevelUp token solution. . . 20
2.7 System architecture. . . 23 2.8 Eavesdropping attack. . . 26 2.9 Man-in-the-middle attack. . . 27 4.1 Stakeholders. . . 33 4.2 eCommerce solution. . . 34 4.3 Marketplace solution. . . 35 4.4 Network topology. . . 38
4.5 Primary account number layout. . . 40
4.6 Generic card layout. . . 41
4.7 Register card screen. . . 42
4.8 Register card error screen. . . 42
4.9 Interaction among di↵erent components in new topology when reg-istering new card. . . 44
4.10 Card menu screen after successful registration. . . 45
4.11 Unsuccessful registration. . . 46
4.12 Payment flow step 1. . . 48
4.13 Payment request screen. . . 49
4.14 Payment accept screen. . . 50
4.15 Payment deny screen. . . 50
4.16 Payment flow step 2. . . 51
4.17 Payment receipt. . . 52
4.18 Token hijacking. . . 54
2.1 Token format examples. . . 13 4.1 Third-party payment gateway providers . . . 36
Introduction
The number of mobile phone users are growing each year and there are 96 active mobile phone plans for every 100 people in the world today [1]. This means a total of almost seven billion existing mobile phones connected to the mobile network, an astonishing number in itself, and two billion ad-ditional mobile devices are estimated to be shipped globally in 2014 [2]. However, these mobile phones are not evenly distributed over the popula-tion, as wealthier persons tend to have more than one cell phone, so there are still a lot of people without cell phones in the world. Despite the un-even distribution of cell phones, these devices provide an opportunity for businesses to reach out to potentially billions of customers. According to eMarketer, the number of smartphone users will reach a total of 1.75 billion in 2014 [3].
Smartphones are multi-functional and can be described as a digital Swiss army knife containing your calendar, alarm clock, camera, music player, web browser and countless other types of applications. A lot of people also use their smartphone for home banking and shopping [4].
The concept of trading products or services via computer networks such as the Internet is called eCommerce. The part of eCommerce conducted via mobile phones is called mCommerce. The market for mCommerce is still fairly small relative to the total eCommerce market and only accounted for 11 percent of the total eCommerce sales in 2012 [5]. It is estimated to grow and account for 25 percent of the total eCommerce sales by 2017 [5]. Increasingly, companies want to take advantage of this aspect and introduce their applications for mobile platforms.
TaxiCaller is a company that o↵ers a cloud based taxi dispatching system to various customers around the globe and now wants to include in-app credit card payments into their system in order to make it more attractive on the market. Although attractive from a business sense, one must consider the fact that growing commerce activities on smartphones will also make them more interesting targets for malicious users seeking to obtain credit
card credentials. This motivates the company to implement in-app payments with security in focus.
1.1
Problem statements
The main problem this thesis will discuss is:
How can one implement mobile in-app credit card payments securely? To be able to answer this question we need to break it down to essentially three sub-questions:
• What mobile payment solutions exists today, and what possible at-tacks exists?
• How does the mobile environment, compared to general computer en-vironments, a↵ect information security?
• Is TaxiCaller able to align their existing system to current security standards set by the major card brands without rebuilding their whole system?
Following is a motivation of the importance of these questions and the problems they bring to the table:
In order to process credit card transactions, every merchant is recom-mended to be compliant with a security standard set by the major card brands in the world. This standard is called Payment Card Industry Data Security Standard (PCI-DSS) [6]. This security standard exists to help mer-chants make their systems more robust and prevent theft of sensitive card information. There have been discussions on what impact the PCI-DSS re-ally has on protecting sensitive card information, as a study including 517 PCI-compliant companies showed that 79 percent of them had su↵ered from data breaches [7]. Some people go even further and say that the card issuers used their economic power to design PCI DSS with a view to dump liability onto other organizations such as merchants [8]. There are also people who think that the PCI-DSS is needed because of the constant increase of credit card frauds. They think for example that the presence of the standard is en-couraging merchants to address the security issues that comes with handling of credit card information [9].
Card frauds are still growing in numbers overall and, generally, computer security are more frequently entering the spotlight in media with some large breaches of Sony and Target for example, where as many as 110 million card credentials might have been stolen [10][11]. These examples on breaches of major companies certified as PCI-compliant can indicate problems in the standard and implementation. Everyone needs to be aware of the risks and responsibilities that are involved with implementing card payments.
The fact that the number of existing smartphones are rapidly increasing and the security in mobile environments are arguably a lot di↵erent from the one on personal computers [12], warrants the need for thorough mobile se-curity evaluations. Furthermore the rising amount of m-commerce activities also motivates the importance of such an evaluation of payment solutions developed for smartphones.
1.2
Contribution
We implement a credit card based in-app payment system for smartphones and evaluate its security. In order to accomplish this we gather knowledge on how to securely process sensitive data (i.e. credit card credentials), un-derstand the role of di↵erent actors involved in a credit card transaction and discover and mitigate mobile specific security vulnerabilities.
As the in-app payment system is integrated into an existing non-payment system, we examine the current system and locate the components into which functionality must be implemented in order to achieve a functional system. We provide answers to the questions stated in Section 1.1, and present a deeper insight into the area of mobile payments.
1.3
Methodology
The thesis work is divided into three major parts. The first part involves a thorough literature study in order to gain a deep knowledge in the areas of mobile payments and credit card payments. This includes the regulations set by the card brands on all entities that process credit card transactions (PCI-DSS), the cryptology used to protect credit card credentials, and the current mobile payment solution types adopted by the industry. Internet sources are used to gather the latest information and statistics in various fields. We consider this literature study an important and necessary part. In order to design and implement a mobile payment system for credit cards securely it is important to have knowledge about existing solution types, security techniques used, and steps involved in a credit card payment. Without this knowledge we consider it impossible to design a robust mobile payment system suitable for the needs of TaxiCaller.
The second part focuses on the requirements TaxiCaller has on the im-plementation. This part contains an evaluation of existing mobile payment solution types in terms of economical, complexity, and security aspects. The economical aspect is important as TaxiCaller wants the mobile payment sys-tem to be as cost-efficient as possible, both to implement and to use. The complexity aspect is important as TaxiCaller wants the mobile payment sys-tem to be easy to use and simple to integrate into their existing syssys-tem. If the mobile payment system is complex to integrate then the cost is also higher. The security aspect is important since credit card credentials are
considered to be sensitive data, and customer’s trust in TaxiCaller may de-crease if their sensitive data is not handled securely. In the evaluation of the di↵erent solution types, we describe vulnerabilities, attacks, and high-light positive and negative aspects with each solution type. We choose one solution to base our mobile payment system upon and motivate this choice. We investigate both how to develop a mobile payment system from scratch and how to develop a mobile payment system using a third-party payment gateway to handle the processing of card transactions. Di↵erent third-party payment gateways are evaluated in terms of cost, geographical availability, and responsibilities towards the regulations of the card brands. These are TaxiCaller’s main points of interest. Since TaxiCaller is a global company with customers across all continents, it is essential that the third-party payment gateway supports as many countries as possible. TaxiCaller wants to provide the mobile payment system as cost-efficient as possible for the customers, which imply that the third-party payment gateway needs to be as cost-efficient as possible to use. TaxiCaller is also keen on keeping their customer’s trust and therefore the third-party payment gateway needs to have sufficient security in place. We motivate the choice of a third-party payment gateway to use for card processing in our mobile payment system. The third part involves a design and implementation of a mobile pay-ment system for smartphones, a threat modeling of the system and finally an integration of the newly designed mobile payment system into TaxiCaller’s existing system. In the design we first familiarize ourselves with the exist-ing system of TaxiCaller in order to integrate the mobile payment system with the existing system. Without taking into account the existing sys-tem during the design, an integration of our mobile payment syssys-tem into the existing system might not be possible. We perform a threat analysis to identify threats and calculate risks in our mobile payment system. This provides confidence in the security of our mobile payment system. The im-plementation is done using agile software development method and includes continuous testing. We prefer the agile method over the waterfall model mainly because in the waterfall model the testing is done in a separate step near the completion of the implementation phase. This might complicate the testing as the bugs can propagate and remain unknown until the test-ing step. With an agile method the testtest-ing is done continuously durtest-ing the implementation. This enables us to correct bugs early and reveal design flaws early in the implementation which can be corrected. We think this contributes to a more robust mobile payment system.
1.4
Company
TaxiCaller Nordic AB o↵ers cloud based dispatching systems to taxi com-panies all over the world. This solution includes online access to the owner console and dispatch console through a web browser. Separate driver and passenger applications available for iOS and Android based mobile phones
and integration of an online booking form and map to the customers web site.
By using the Global Positioning System (GPS) on the driver’s smart-phone, it is possible for the dispatcher, driver and passenger to receive real time positions of the taxi vehicles. TaxiCaller o↵ers companies to receive both bookings via the web form and the mobile based passenger application. The companies can choose to be included in the free TaxiCaller application where passengers can view all vacant taxis for a specific route, regardless of which company the taxi belongs to. Another solution is a branded ap-plication where only the taxis belonging to that company are shown to the passengers.
The web based dispatch console includes an in-browser Voice over IP (VoIP) based soft phone which enables the dispatcher to accept incoming calls through the browser as well as making outgoing calls. Since the solution is cloud based no local installation is needed and it is easily scalable to meet the need of taxi fleets of various sizes[13].
In order to be able to use the passenger application a user needs to sign up for a free user account.
1.5
Desideratum
TaxiCaller is in need of a feature where the passengers link their credit card to their user account through the passenger application, to be able to pay for future taxi rides. This idea is shown with flow diagrams in Figure 1.1 and Figure 1.2.
Figure 1.1: High level idea of registration of credit card.
Figure 1.2: High level idea of payment flow.
Figure 1.1 shows the initial high level idea of the registration process of a payment card initiated by the passenger through the passenger application. Figure 1.2 shows the initial high level idea of the payment flow where the
driver shall be able to issue payment requests from the driver application, notifying the passenger about the payment request.
The passenger shall be able to respond to the request, and money shall be transferred from the passengers bank account to the taxi driver or taxi company’s bank account.
Background
This chapter gives background of cryptography techniques and the PCI-DSS standard, which is set by the major card brands for processing of credit card information. Furthermore this chapter explains di↵erent existing mobile payment solutions, mobile specific security and common attacks targeting mobile devices.
2.1
Cryptography
This section covers the cryptographic methods which underlay the security of credit card information in a digital environment as of today. This includes methods used to protect credit card information from malicious users when transmitted, stored and processed.
2.1.1
Internet protocol stack
To understand the following cryptographic concepts this section gives a brief introduction to the Internet protocol stack.
In order to provide structure to the design of network protocols, network designers organize protocols - and the network hardware and software that implement the protocols - in layers [14].
The five-layer Internet protocol stack shown in Figure 2.1 illustrates this structure where each layer provides its service by performing certain actions within that layer and by using the services of the layer directly below it. This section mainly focuses on the application- and transport-layer in which functions to protect credit card data are implemented. The bottom three layers are considered out of scope in this thesis.
Figure 2.1: Internet protocol stack.
2.1.2
Encryption
Encryption is the process of protecting data from unauthorized access by users. It is intended to provide confidentiality to the data and is widely used to protect sensitive data such as passwords and credit card informa-tion. The two major categories of encryption are symmetric and asymmetric encryption.
2.1.3
Symmetric encryption algorithm
Figure 2.2: Symmetric encryption.
Symmetric encryption algorithms use the same key for both encryption and decryption of the data. This key has to be kept secret to everyone except those authorized to both encrypt and decrypt the data. Figure 2.2 visualizes the concept of symmetric encryption for secure communication between a
sender and a recipient. The drawback of this approach is that in order to set up secure communication with several di↵erent recipients, you need a new key for each recipient. This raises the problem of how to distribute the key securely to all recipients.
2.1.4
Asymmetric encryption algorithm
In asymmetric encryption algorithms di↵erent keys are used for encryption and decryption. The two keys are algorithmically related but it should be nearly impossible to derive the decryption key from the encryption key or vice versa.
Asymmetric encryption is useful when one want to send confidential information and be confident that only parties intended to view the infor-mation are able to decrypt it. Consider the scenario in Figure 2.3 where a sender encrypts the data using the recipients public key and the recipient uses his private key to decrypt the data.
Figure 2.3: Asymmetric encryption.
Since it should be nearly impossible to derive the decryption (private) key from the encryption (public) key, the recipient can make the encryp-tion key public. This enables multiple senders to use the encrypencryp-tion key to encrypt the data and be confident that only the recipient holding the decryption key can decrypt the data. Since the encryption key can be made public, asymmetric encryption does not have the key distribution problem of symmetric encryption discussed in Section 2.1.3.
2.1.5
Certificate authorities
In the case of the asymmetric encryption in Figure 2.3, the public key is public but needs a confirmation that it indeed belongs to the entity that claims to own it. This is where the role of a Certificate Authority (CA) comes into the picture. The two main purposes of a CA is to verify that an
entity (a person, a router, and so on) is who it says it is and, once verified, issue a certificate that binds the public key of the entity to the entity [14].
For this system to work properly the clients need to trust CAs. Develop-ers of web browser often include a set of trusted certificates in the browser software, in other words you have to trust the developers not putting in any rogue certificates in the browser you use out of the box.
Certificates are arranged hierarchical creating chains of certificates, each certificate signed by the previous one in the chain. The highest certificate in a chain is called a root certificate and is often self signed, and made trust worthy by other methods. The browsers validates a certificate by tracing the certificate chain for a certificate included in the browsers trusted certificates and warn the user if no trusted certificate was found in the chain.
2.1.6
Secure socket layer / transport layer security
Figure 2.4: SSL/TLS handshake.
Secure Socket Layer / Transport Layer Security (SSL/TLS) provides a secu-rity layer on top of the stateful connection-oriented transport layer protocol Transmission Control Protocol (TCP). It resides between the application
layer and the transport layer in the (Internet Protocol) IP stack, and relies on the reliable delivery of data provided by TCP and thus only concerns about providing confidentiality, data integrity, server authentication and client authentication to the TCP which itself lack these security features [15]. SSL/TLS makes use of symmetric encryption, asymmetric encryption and certificate authorities to provide security to the data to be sent. SSL/TLS is proposed by the PCI-DSS to be used every time sensitive payment card information are to be transmitted over the internet [16].
The following enumeration provides a description of the procedure to set up a communication channel using the SSL/TLS protocol showed in Figure 2.4 [17].
1. ClientHello
This message contains:
• The highest SSL/TLS version the client supports
• A random number used only once which is called nonce. It is used when deriving the master secret later on
• A list of suggested cipher suites ordered according to the client‘s preferences
• A list of suggested compression algorithms ordered according to the client‘s preferences
• A session id (0 if the client wish to establish a new SSL/TLS session)
2. ServerHello
This message contains:
• The SSL/TLS version to be used
• A random server nonce to be used when deriving the master secret later on
• The cipher suite to be used
• The compression algorithm to be used
• A session id (If the server allows the client to attempt to resume and reuse the session at some later point in time)
3. Certificate
This message contains:
• A certificate chain with the server’s certificate first in the chain followed by a series of CA certificates proceeding sequentially upwards until a root CA is reached.
The server can choose to also send additional messages ServerKeyEx-change (Depending on the chosen cipher suite) and RequestCertificate (To require the client to authenticate itself)
4. ServerHelloDone
This message is sent to indicate the end of the ServerHello and asso-ciating messages.
5. ClientKeyExchange
The content of this message depends on the chosen cipher suite but in general contain:
• A pre-master secret encrypted with the public key of the server. Both parties will now have all the ingredients to generate the symmet-ric session keys to be used.
6. ChangeCipherSpec
States that the client from now on will communicate using the agreed upon cipher suite and session keys
7. Finished
The first message protected by the newly negotiated algorithms and keys. It is sent to verify that the key exchange and authentication process have been successful and contain:
• A hash and a Message Authentication Code (MAC) of all previous handshake messages for integrity check
8. ChangeCipherSpec
States that the server from now on will communicate using the agreed upon cipher suite and session keys
9. Finished
A hash and MAC of all previous handshake messages for integrity check
Both parties now have a shared symmetric session key to encrypt all following communication with.
2.1.7
Tokenization
Tokenization is a method used to replace sensitive data with non-sensitive placeholders called tokens. In di↵erence from encryption where you just di↵use the data using a key, tokenization is the concept of replacing the data with a token not algorithmically related to the original data. The original data is placed in a separate secure server and the tokens are used
to represent the data outside the servers domain. This method has been discussed in several papers [18][19].
Tokenization limits the impact of a breach since a malicious user is not able to extract card information from the token itself and the token are only valid in a limited environment. Many payment gateway providers of-fer tokenization service to the merchants and it is very popular because it relieves merchants from keeping sensitive credit card information on their own servers. The credit card information are instead stored in card vaults hosted by the payment gateways and the merchants can more easily obtain PCI-compliance [20]. The payment gateways, possibly storing millions num-ber of unique cards, are however becoming high-profile targets for malicious users [21][22].
Primary account number Token Comment
3124 005917 23387 7aF1Zx118523mw4cwl5x2 Token consists of alphabetic and nu-meric characters 4959 0059 0172 3389 729129118523184663129 Token consists of numeric characters only 5994 0059 0172 3383 599400x18523mw4cw3383 Token consists of truncated PAN (first 6, last 4 of PAN are retained) with alphabetic and numeric char-acters replacing middle digits. Table 2.1: Token format examples.
Table 2.1 shows three examples of token formats that may be used. In the first two, the token gives no clue about the Primary Account Number (PAN) whilst in the third, the first six and last four digits of the PAN is in the token. This is useful as you want to easily display to card holders which of their cards are stored by showing a masked PAN generated from the token.
The PCI-DSS permits the display of the first six and the last four digits of the PAN, so the third example in Table 2.1 is thus an acceptable token format.
In order for a malicious user to retrieve the PAN given a token, he needs to perform a brute force attack since the token and PAN number is algorithmically unrelated. Including the first six and last four digits from
the original PAN in the token clearly gives a lower security as the malicious user is given as many as 10 out of 16 numbers of the PAN and only need to perform a maximum of 106 operations to retrieve the PAN compared to
1016 in the case where no digit from the original PAN is known.
2.2
Payment card industry data security
stan-dard
This section describes the function and content of the Payment Card Indus-try Data Security Standard (PCI-DSS).
2.2.1
History
Originally each major card brand developed and maintained their individual security program for protection of cardholder data. The merchants and pro-cessors using multiple major card brands had to comply to multiple di↵erent non-aligned card security programs which made integration of the payment system troublesome.
The five major card brands American Express, Discover Financial, JCB International, MasterCard and Visa Incorporated agreed upon a joint set of requirements to reduce this burden to merchants and processors. The re-sult was a standard named Payment Card Industry Data Security Standard (PCI-DSS), which was published in December 2004 [23].
Each brand kept its own security program but modified them in order to adopt to the PCI-DSS and the merchants and processors could mainly focus on the requirements in PCI-DSS to achieve compliance across all major payment brands. Visa and MasterCard were maintaining and administrating the PCI-DSS until September 2006, when the five major card brands founded the Payment Card Industry Security Standards Council (PCI-SSC). From thereon the PCI-SSC is solely responsible for developing and maintaining of the PCI-DSS.
Today the PCI-SSC have developed a rich document library including: • The current PCI-DSSv3.0
• Self Assessment Questionnaires (SAQ) for merchants outsourcing stor-age of credit card data and/or processing of credit card transactions to third-party companies, and thus reducing their own PCI-compliance scope. These self assessment questionnaires are basically subsets of the complete PCI-DSS and exist to provide simplified compliance val-idations for the merchants. For example if a merchant uses a PCI-compliant third-party company for storage of credit card data, it is not necessary for the merchant to fulfill the requirements in the PCI-DSS concerning safe storage of credit card data. The third-party company
is instead responsible for fulfilling these requirements, but the mer-chant still need to ensure that the third-party company fulfills these requirements.
• Report On Compliance (ROC) for Qualified Security Assessors (QSA) performing PCI-compliance evaluations
• Instructions and guidelines for PCI-compliance on – SAQ
– eCommerce – Cloud hosting – Mobile payments – Cash machines (ATM) – Use of wireless networks – Tokenization
– Virtualization
Apart from administrating the standards, the PCI-SSC also runs programs for approving QSAs which are persons certified to review merchants and service providers and issue PCI-compliance.
Even though the council is responsible for administration of the stan-dard PCI-DSS and all documents around it, they are not responsible for compliance enforcement or validation. This is instead the responsibility of the card brands under their respective card security program [24].
2.2.2
Data security standard
Anyone who wants to store, process or transmit credit card credentials to any extent needs to comply to the PCI-DSS standards, and only certified QSAs can approve PCI-compliance. The standard consist of 12 major requirements which is divided into a numerous sub-requirements concerning everything from network infra-structure to security education [16].
2.2.3
Requirements
In this section, a summary of the major requirements as proposed in the PCI-DSS v3.0 is presented [16]:
1. Install and maintain a firewall configuration to protect cardholder data This section describes requirements regarding the infrastructure of the overall Cardholder Data Environment (CDE). Its purpose is to en-lighten the positive e↵ect of mapping the network infrastructure and all its component as well as the card data flow into, within and out
from the CDE. It enforces policies on roles and responsibilities of em-ployees regarding the security of the network as a whole as well as security on their work stations.
2. Do not use vendor-supplied defaults for system passwords and other security parameters
This section states that all default passwords and settings of network components should be changed before installation as common pass-words and settings are known to and used by malicious users. It en-courages the company to evaluate which protocols and functions are required for its business and to disable non-used functionality. An inventory of network components in the PCI-scope and security poli-cies for how to integrate new components to the network in a secure way should be maintained. This enables the company to be confident that all default passwords and other security parameters have been reviewed on every component in the PCI-scope. The company shall also review operating systems, databases and enterprise applications that are used by the company for known vulnerabilities.
3. Protect stored cardholder data
This section covers not only what cardholder data that may or may not be stored, but also how to properly encrypt cardholder data, maintain-ing policies regardmaintain-ing access to stored cardholder data and also stormaintain-ing of cryptographic keys used to encrypt cardholder data. Policies con-cerning generation of keys and access control to stored keys are also described.
4. Encrypt transmission of cardholder data across open, public networks This section states that usage of secure encryption must be in place when transmitting cardholder data, and that no sensitive card data should ever be sent by end-user messaging technologies.
5. Protect all systems against malware and regularly update anti-virus software or programs
This section covers the usage of anti-virus software on all components connected to the CDE and policies how to maintain these software by regularly updating them and making sure they are running periodical scans.
6. Develop and maintain secure systems and applications
This section encourages development of components with security as the main target. Vulnerabilities such as SQL-injection and cross-site scripting as well as other commonly known vulnerabilities should be considered when developing custom code applications. When using third party software the company should ensure it has been developed
with security as focus and not contain vulnerabilities that could com-promise the company’s CDE. Risk analysis, code reviews and testing should be a included in the development process.
7. Restrict access to cardholder data by business need to know
The term “need to now” implies that access rights are granted to only the least amount of data and privileges needed to perform a job. Employees should therefore be assigned roles with di↵erent levels of access to the CDE and strong access control is needed to allow each employee to access only the resources required to accomplish their jobs.
8. Identify and authenticate access to system components
The key in this section is to require a unique ID for each user of the system and encourage of logging all access to CDE. It also enforces two-level authentication for remote access to the CDE, have requirements on the authentication methods and recommendations about password policies.
9. Restrict physical access to cardholder data
This section covers requirements regarding access to server facilities, surveillance recommendations and monitoring of who and when some-one may have physical access to the CDE.
10. Track and monitor all access to network resources and cardholder data This section further enlighten previous requirements regarding moni-toring. It especially enforces having strong, tamper-proof audit trails and logs.
11. Regularly test security systems and processes
This section focuses on security testing procedures such as external and internal network scans, penetration testing and policies about how often and what should be included in the testing procedures. 12. Maintain a policy that addresses information security for all personnel
This section encourages companies to introduce security awareness training to all their personnel and also include risk assessment. This briefly summarize the PCI-DSS v3.0 standard. The span of the stan-dard is immense and covers the security of the whole CDE network as well as the interaction with connected networks. It also encourages development with security in mind, and access control on both physical and virtual level with monitoring and audit trails.
2.3
Other information security standards
This section describes other security standards similar to the intentions of the PCI-DSS concerning confidentiality and integrity of sensitive data.
2.3.1
Health Insurance Portability and Accountability
Act (HIPAA)
The HIPAA exists in United States of America and concerns safe handling of health records to prevent health care fraud and abuse. It is a law enacted by the United Sates Congress in 1996 [25].
2.3.2
Sarbanes-Oxley (SOX)
The SOX act of 2002 is like HIPAA a federal law in United States of Amer-ica. It was enacted as a response to multiple financial scandals to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprises [26].
2.3.3
Discussion
Compliance to both HIPAA and SOX are federal laws in United States of America, while PCI compliance is not. However PCI compliance is a state law in Nevada [27]. This may indicate that PCI compliance might become a federal law in the future as long as credit card frauds are growing in numbers. One of the initial sub-questions of this thesis is Is TaxiCaller able to align their existing system to current security standards set by the major card brands without rebuilding their whole system?. After the literature study on PCI-DSS this sub-question is considered to be unsatisfiable in this thesis. The arguments for this is first of all that the existing system of TaxiCaller is not originally designed to hold a payment system and the extensiveness of all the PCI-DSS requirements will most likely cause a major rebuilding of the system. The second argument is that the expected income on the mobile credit card payment feature does not justify the amount of time and money spent on becoming and maintaining PCI compliance for the company.
The cost of becoming PCI compliance varies a lot depending firstly on the investment in meeting all the requirements and secondly on the assessment and validation of the compliance. The average cost per year to ensure PCI compliance has been found to be as high as $225,000 [28]. By using third-party providers for processing of the credit card transactions TaxiCaller can avoid this costly process. Further details are discussed later on in this thesis.
2.4
Existing mobile payment solutions
Mobile payment solutions can be categorized in two di↵erent categories, proximity payments and remote payments [29]. Proximity payments means the merchant and customer physically interact during the transaction and re-mote payments means that they do not. Proximity payments can further be divided into card-present and card-not-present payments based on whether or not the physical credit card needs to be present during the transaction.
Remote payments are always card-not-present in the sense that the cus-tomer is not physically present with the payment card at the time of the purchase. The following subsections describes the three mobile payment solutions:
• Smartphone as point-of-sale (Card-present proximity payment) • Smartphone as token (Card-not-present proximity payment) • Smartphone as payment device (Card-not-present remote payment)
2.4.1
Point-of-sale
Figure 2.5: Square point-of-sale solution.
To replace traditional checkout registers or other physical immobile point-of-sale terminals merchants can choose to use smartphones. This is mainly a solution for merchants on the road given its flexibility, but can also be used in-store to allow the cashiers to be mobile.
Companies such as Square Inc. [30], o↵er a mobile card reader to plug into the smartphone’s audio jack to turn it into a point-of-sale device [31]. Readers encrypt the card data during the swiping using asymmetric encryp-tion and it stays encrypted on its way to the payment gateways server where it is decrypted and the transaction is processed securely.
This reduces the PCI-compliance burden on the merchant since he never handles the card data in clear text and do not possess the encryption key. The interface included with the reader simulates the one of a traditional terminal. This solution is mainly for card-present transaction (i.e. swiping) and would be rather inconvenient if the customer has to enter the card credentials manually for each purchase.
The picture showing a mobile phone being used as a point-of-sale device is shown in Figure 2.5.
2.4.2
Token
Figure 2.6: LevelUp token solution.
The smartphone can be used as a token when making payments. This method can be seen as a virtualization of the customer’s physical wallet into his smartphone and can in combination with the device specific au-thentication, such as screen lock, bring a higher security compared to the point-of-sale solution.
An example is LevelUp which is an smartphone application that act as a wallet [32]. The customer pays by showing a QR-code representing his wallet to a reader in any shop equipped with a LevelUp compatible QR-reader shown in Figure 2.6. This solution takes advantage of the physical possession of the token as well as additional device specific security mea-surements such as screen-locking. The customer can also set an authorize password which needs to be provided to use the application introducing one more authentication level.
2.4.3
Payment device
A regular mCommerce solution enables the customers to enter their card cre-dentials directly into a smartphone application, usually to pay for a product or service. This is very similar to eCommerce conducted on web sites on the internet, the major di↵erence is that a smartphone is always used in a wireless environment. Typical mCommerce examples are merchants pro-viding stores in the form of smartphone applications, where customers can purchase products via their own smartphones.
A normal feature is the storing of credit card credentials for future billing and there exist payment gateways which provide this service. To reduce the PCI burden on the merchant a common solution is client side encryption of card data by using a mobile SDK of a third-party payment gateway. This way the card data will be unreadable by the merchant, and can only be decrypted on the servers of the provider of the mobile SDK. For future billing the sensitive card data is often replaced by a token that the provider can map to the actual card credentials. Tokenization is described in Section 2.1.7.
2.4.4
Discussion
Each of the previous solutions represent one of the solution types described in Section 2.4. The point-of-sale solution is the only solution where the customer is vulnerable to physical card theft, since it is the only one requiring the card to be present at the purchase.
All of the solutions discussed in previous subsections use end-to-end en-cryption to encrypt the card data as soon as it enters the device until it reaches the servers processing the cards. The solutions also use Hypertext Transfer Protocol Secure (HTTPS) as communication protocol, which is based on SSL/TLS discussed in Section 2.1.6. This combination provides confidentiality and integrity to the card data and is excellent for merchants wanting to avoid the burden of making their own system completely PCI-compliant.
Both the point-of-sale and token solutions require each merchant to have the appropriate reading device in place, either a card reader in the case of the point-of-sale solution or a QR-reader in the case of the token solution. Without this additional hardware it is not possible for the merchant to receive credit card payments.
The third solution is more flexible as it does not force the merchant to have any additional hardware in place, and it can be used anywhere as the merchant and the customer do not need to physically interact during the purchase. With the addition of using a third-party provider for processing and storing of the card credentials and card transactions this solution can be seen as the most easily adaptable of the three solutions described.
A possible attack on the point-of-sale solution would be if a malicious user modify the reader, possibly by placing another reader on top of the le-gitimate one, in order to collect the card credentials before it gets encrypted
by the legitimate reader.
A possible attack on the token solution would be if a malicious user manages to get a screen shot of the QR-code representing the victims wallet, and use this screen shot to conduct purchases at any merchant equipped with a LevelUp QR-reader. LevelUp tries to mitigates this by embedding an access token in the QR-code which is only valid for a limit amount of time, and the customer also has the possibility to change the QR-code representing their wallet at any time.
A possible attack on the payment device solution and a general attack in eCommerce overall is if a malicious user eavesdrops the network traffic and retrieves the card credentials in transit. This must be mitigated by using a secure communication protocol like the commonly used HTTPS.
To summarize this section we conclude that all three solutions have di↵er-ent advantages and drawbacks. The point-of-sale solution o↵ers merchants the ability to be mobile and accept credit card payments regardless of where they are located but it also requires the physical card to be present. The to-ken solution relieves the customers from needing their physical cards present during purchase but requires the merchants to invest in additional hardware at all their merchant locations. Lastly the payment device solution decou-ples the customer from the merchant in a physical sense but is vulnerable to common attacks targeting eCommerce.
For the implementation later on in thesis we choose the payment device solution mainly because of that the company does not desire to force hard-ware upon their merchants, and secondly because it gives us more flexibility in the implementation.
2.5
Android security
In this thesis Android is used as the mobile operating system during the implementation. Security specific only to other mobile operating systems such as iOS are thus not in the scope of this thesis.
This section briefly covers the layout of the Android platform and com-mon attack vectors targeting Android devices.
2.5.1
System architecture
Figure 2.7: System architecture.
Figure 2.7 shows the system architecture which is divided into four layers [33][34]. The lowest layer consist of the Linux kernel which is the first soft-ware layer that interacts with the device hardsoft-ware. Above the kernel layer are libraries and the Android runtime. The libraries are written in C/C++ and function as a translation layer between the application framework layer and the kernel layer. Via a Java API, developers gain access to the libraries. Examples are libraries for playback and recording of audio and video, the graphic engine and cryptographic functions such as SSL [33]. The Android runtime consist of a Dalvik virtual machine that interacts with and run applications.
The application framework provides a rich set of Java application pro-gramming interfaces to use when building applications [34]. It contains managers for activities, resources, locations and notifications among other services.
The layer closest to the end-user is the application layer and within this layer resides for example applications such as calendar, alarm clock and any custom developed application. The applications are written in Java and execute in this spacing using previously mentioned Java application programming interfaces and the Dalvik virtual machine.
2.5.2
Permissions
Within Android, all processes run in its own isolated environment and no inter-process communication is allowed unless it is explicitly permitted [34]. Developers of Android application must specify which permissions their ap-plications are required to have access to, in order to gain access to them. For example a location-based application would generally need permission to use the GPS of the device but not permission to make phone calls.
The permissions are presented to the user upon installation of new ap-plications and they have the option to either accept or deny all of them.
There is no option for the user to allow just a subset of the permissions [33]. Once a user has granted the permissions for an application, the only way to remove them is to uninstall the application. If a user does not read through the permission list upon installing applications they can become victim of a permission abuse attack, where the installed application acquires more per-missions than needed for the functionality. This attack is further described in Section 2.6.2.
2.6
Attacks
This section describes possible attacks that can be mounted in order to obtain sensitive data with a focus on Android devices. As this thesis focuses on protection of card credentials the attacks will be ranked in the probability of them being successfully used in order to obtain card credentials. The rankings used are low, medium and high.
2.6.1
Stolen device
Because of the mobility and size of smartphones they are at greater risk of being stolen than personal computers. A recent report indicates that about 3.1 million smartphones where stolen in 2013 [35]. The thieves might extract all information from the device and possibly retrieve sensitive personal data so it is critical for users of smartphones to install some form of mitigation for this scenario.
Apart from the front line authentication methods such as screen locks there exists a lot of security features such as remotely disabling the device, remote locking and remote GPS tracking of the device.
The probability of obtaining card credentials from this attack is con-sidered low since a fair assumption is that most of the users do not store card credentials in their smartphones. It is difficult to mitigate the theft of smartphones because it mainly depends on what environments the users use their smartphones in. However, by using the previously mentioned features such as remote disabling/locking of the smartphone, at least the content in the smartphone can be protected from unauthorized access.
2.6.2
Permission abuse
There are several ways of performing the permission abuse attack. The first and most straight forward variant is when a malicious developer develops an application requesting more permissions than needed to function and assumes that the user will not care to fully examine all the permissions listed upon installation and approve the permissions. A real example of this was discovered in September 2012 when a malicious game application was detected to use SMS permission in order to make the user subscribe to a
premium service. The developers managed to collect almost $400,000 before fraud was discovered [36].
The second variant is when a malicious application developer develops applications that are originally legitimate but request more permissions than they need to o↵er the functionality. Once a sufficient amount of users have downloaded the application the developer may release a update injecting malicious code to exploit these extra permissions. It has been reported that over 50 popular free applications on the Android market where re-released and injected with malicious code [37].
The current Android permission model may be to coarse-grained and inflexible, consider for example the permission to use the Internet which almost every application needs to function properly [38]. Once this permis-sion is allowed an application can send HTTP(S) requests to every domain on the internet. There are studies on alternative solutions to the current permission model, for example the context aware model ConUCON which enables the developers to define more fine-grained permissions [39].
The probability of obtaining card credentials from this attack is consid-ered medium since it is a common attack targeting Android users. Consider a scenario where a malicious developer releases an application with in-app purchases, and requests the card credentials of a user. These credentials may then secretly be sent over the Internet and possibly stored in some remote location. As in the case of the stolen device attack, this attack is hard to mitigate from a developer’s point of view. Instead, the users need to critically examine the permissions each application requests before installa-tion of new applicainstalla-tions, and ask themselves if the requested permissions are reasonable. As example, if a simple game application requests permission to read your contacts and/or send SMS this can indicate that the application has a hidden agenda to exploit these permissions.
2.6.3
Keylogger
Smartphones do not have any hardware keyboards present, instead they have a software keyboard for user input.
There exists applications that can log every key stroke and send the data over the Internet, but the user must be tricked to install it and grant the per-missions. Research have been done in creating keyloggers using the phones motion sensor to read the key strokes of the user. An example is touchlogger which claims to be 70 percent accurate on a number-only software keyboard, only asking for the permission of accessing the motion sensor of the smart-phone [40]. This functionality could possibly be embedded into an otherwise legitimate application and used combined with the internet permission to secretly send the logged key strokes to the malicious user as the permission to use motion sensors probably do not raise any suspicion.
The probability of obtaining card credentials from this attack is con-sidered low since it either requires a user to install a malicious third-party
keyboard or a application similar to touchlogger which use motion sensors to collect keystrokes. In the later case the accuracy is however still fairly low so the probability of obtaining the full card credentials is considered to be minor.
We consider user awareness about possible attacks as mitigation of this attack. Users need to know about this possible attack. By knowing that this kind of attack exists, a user is less likely to download a third-party keyboard. In the case of the touchlogger, it is a form of permission abuse attack and we refer to the mitigation technique proposed in Section 2.6.2.
2.6.4
Eavesdropping
Figure 2.8: Eavesdropping attack.
In eavesdropping, a malicious user listens to the communication channel between two parties without modifying the messages. This attack is also called sniffing.
Consider the scenario in Figure 2.8 where Alice communicates with Bob and Eve is eavesdropping the communication channel. If Alice sends card credentials in cleartext to Bob this attack has a high probability in success-fully obtaining the card credentials. If encryption such as SSL/TLS is used the probability is instead considered low since Eve need to have knowledge of the generated session keys which Alice and Bob individually calculate during the initial SSL/TLS handshake.
2.6.5
Man-in-the-middle
Figure 2.9: Man-in-the-middle attack.
Man-in-the-middle (MITM) is a widely known attack on the Internet where a malicious user intercepts communication between to parties without their knowledge [41]. The malicious user has the possibility of eavesdropping, altering or discarding every message sent by any of the parties.
Consider the scenario in Figure 2.9 where Alice and Bob are legitimate users wanting to communicate with each other and Eve is a malicious user. In a successful MITM attack Alice and Bob think they are communicating safely with each other where in reality Eve is intercepting all messages and controlling the communication flow. A MITM attack can be accomplished in many ways including Address Resolution Protocol (ARP) poisoning through ARP packets or Internet Control Message Protocol (ICMP) packets [42].
The success probability of this attack is considered high to be used in order to try to obtain card credentials. Consider again the scenario in Fig-ure 2.9 where Bob and Alice think they communicate with each other. In this scenario the malicious user can act as Alice and ask Bob for credit card credentials for example, and if Bob trust Alice he may very well give out this sensitive information. Compare this to the eavesdropping attack where the malicious user needs to passively wait for sensitive information to be sent between Bob and Alice in order to obtain it. By using SSL/TLS including authentication of each participant, both Alice and Bob can be confident that they are in fact communicating with each other.
Requirement analysis
This chapter contains a list of requirements which the mobile payment sys-tem developed in this thesis shall comply with. The list is prepared on consulting with the main stakeholder, the head of TaxiCaller. It consists of 11 main requirements with numerous sub-requirements and descriptions to clarify the functionality required by the mobile payment system.
1. The passenger shall be able to register a credit card issued by VISA or MasterCard to his/her TaxiCaller user account.
(a) The passenger shall have the possibility of approving/disapproving that his/her credit card issued by VISA or MasterCard can be charged by taxi companies using services of TaxiCaller.
(b) The passenger shall be able to register a credit card issued by VISA or MasterCard to his/her user account through the smart-phone based TaxiCaller passenger application.
(c) The passenger shall be able to remove a previously registered credit card issued by VISA or MasterCard from his/her user ac-count through the smartphone based TaxiCaller passenger appli-cation.
TaxiCaller wants the company costumers to have the possibility to receive payment from their passengers through credit cards issued by VISA and MasterCard. TaxiCaller wants to enable this feature by allowing passengers to register their credit card to their user account. The passenger has to be a registered user of TaxiCaller’s smartphone based passenger application, and should be able to enter his/her credit card credentials through the menu in the passenger application. A key aspect of this feature is the need for the passenger to only have to insert his/her credit card credentials once.
Caller passenger application.
(a) This payment options shall only be available to passengers who have registered their credit card to their user account.
When a passenger book a taxi through the smartphone based pas-senger application TaxiCaller want him/her to be able to choose the payment option during the booking phase. The reason is to notify the driver in advance on whether or not the passenger want to pay using credit card through the smartphone based passenger application at the end of the journey.
3. The transaction of money from the passenger to the taxi company, including the transaction fee taken from TaxiCaller will be handled automatically by a payment gateway solution.
TaxiCaller do not want to handle transactions on their own between passengers and taxi companies. The only procedure performed by TaxiCaller will be to set up the initial details of the payment gateway. TaxiCaller wants to act as a marketplace which connects many buyers (the passengers) and many sellers (the taxi companies).
4. The driver shall be able to send a payment request to a passenger through the smartphone based driver application at the end of a taxi ride, if the passenger has registered a valid credit card to his/her Taxi-Caller user account.
(a) The driver shall be notified whether the passenger have registered a valid credit card or not before he/she issues a payment request. (b) The driver shall not be able to send a payment request to a passenger who has not registered a valid credit card in his/her smartphone based TaxiCaller passenger application.
(c) The driver shall only be able to send a payment request to a pas-senger who selected credit card as payment option when he/she booked the taxi ride.
TaxiCaller wants to enable for a taxi driver to send a payment request to the passenger at the end of a taxi ride, if the passenger has specified credit card as the payment method. The procedure should be initiated by the driver and the passenger should receive a notification of the payment request to his/her smartphone based passenger application. 5. The passenger shall be notified of the payment request of a driver
(a) The passenger shall be able to add tip based on a desired percent of the cost of the taxi ride through his/her smartphone based passenger application.
(b) The passenger shall be able to either confirm or deny the payment request through his/her smartphone based passenger application. When a passenger receive a payment request from a driver he/she should have three options according to TaxiCaller. The main options should be to confirm or deny the payment request and the driver should receive a notification about the choice of the passenger. The passenger should also be able to add a tip to the payment. TaxiCaller wants to achieve this by letting the customer add a certain percent of the total amount as tip if desired.
6. When a payment request have been confirmed by the passenger and approved by the payment gateway, the passenger will receive a receipt to his/her smartphone based passenger application.
(a) The driver shall receive notification on whether or not a passen-gers payment is successful.
The payment gateway will charge the credit card for the total amount of the taxi ride included possible tip and process the transaction. If the transaction is successful the passenger shall receive a receipt as a proof of the transaction. The driver should also be notified about any successful/unsuccessful transaction.
7. The solution will be PCI-compliant according to PCI-DSS standard. By using a payment gateway many of the requirements in PCI-DSS will be delegated to the payment gateway. With that said TaxiCaller will still need to comply to some of the requirements regarding safe transmission of data related to the credit card credentials.
8. The cost for implementing the components will be kept to a minimum while still achieving TaxiCaller’s requirements in this document as well as requirements for PCI-compliance.
The main desire of TaxiCaller is to implement this feature as cost effi-ciently as possible yet still fully functional according to requirements. This will be the main reason to follow out a evaluation of existing payment gateway solutions and comparing their current pricing. 9. The payment option shall work with companies situated in USA and
western Europe.
Di↵erent payment gateways requires the companies using their services to be situated in di↵erent countries. TaxiCaller want to provide this feature to their customers in USA and western Europe. By western Europe they mainly mean large countries like France, Germany, Spain,
solution.
10. The components shall be implemented in the smartphone based Taxi-Caller driver application and the smartphone based TaxiTaxi-Caller pas-senger application.
(a) The graphical user interface of the components shall be designed according to TaxiCaller’s existing graphical user interface in terms of color schemes, font and sizes.
(b) The component shall be implemented in the smartphone based TaxiCaller driver application and the smartphone based Taxi-Caller passenger application for smartphones using Android as operating system.
As the integration of the feature should be as smooth as possible for the users of the passenger and driver applications the design of the graphical user interface is of great importance. TaxiCaller require that the color scheme and font will be identical as the rest of the applications.
11. The components shall interact with the TaxiCaller servers using mes-sages formatted using JSON.
Design
This chapter describes the stakeholders and problems in the business model of TaxiCaller. The requirements of TaxiCaller are presented and an evalu-ation of existing payment gateways is done towards the requirements. Fur-thermore the design and implementation of a mobile in-app credit card pay-ment system using a paypay-ment gateway is described, which is followed by threat modeling to provide confidence in the security of the implementa-tion.
4.1
Stakeholders
A description of the various stakeholders in a credit card processing life cycle are given in this section.
Figure 4.1: Stakeholders.
Description of the stakeholders in Figure 4.1
• Credit card - Representing a credit card of a customer • Customer - A buyer of any goods and/or services
• Merchant - A seller of any goods and/or services
• Payment gateway - A middleman between merchants and acquirers that are providing secure processing of payment card transactions, and can help merchants with storage of card information and fraud mon-itoring for example [51]. This is an optional choice for the merchant but can greatly reduce the workload on becoming PCI-compliant. • Acquirer - Bank used by the merchant to process their payment card
transactions
The dotted line in Figure 4.1 shows that the merchant is not required to use a payment gateway. The merchant can interact directly with the acquirer, but in that case all the beneficial features provided by a payment gateway are not available out-of-the-box.
In this thesis, as previously stated, a third-party will be used for secure processing and storing of credit card credentials to reduce the burden of becoming PCI-compliant and limit the scope of this thesis.
4.2
Marketplace
The most common eCommerce solution involves one online shop and many customers. In this scenario the payment flows from many customers to one single point, the merchants account.
Figure 4.2: eCommerce solution.
Payment gateways as of today have constraints regarding in which country the merchant of the e-shop is situated but the customers can be situated anywhere, as long as they adhere to the merchants payment method.
In the case of the scenario in Figure 4.2, a merchant only requires to find a payment gateway who supports merchants in their country of origin. TaxiCaller does not have a e-shop but instead provides a service for taxi companies to connect with new passengers via the TaxiCaller passenger application. TaxiCaller can solve this by acting like an e-shop and retrieve all the transactions to one single account, only to distribute them amongst the taxi companies later on. It is however infeasible for TaxiCaller to handle
thousands of transactions between multiple passengers and taxi companies on their system. TaxiCaller is in need of a marketplace solution where they act as a middle man connecting many taxi companies with many passengers, without handling the actual transactions on their end.
Figure 4.3: Marketplace solution.
Figure 4.3 shows the marketplace solution implemented in this thesis. The passenger pays for a trip and the payment gateway processes the payment, taking their and TaxiCallers service fee and transacts the rest of the money to the correct taxi company.
A marketplace solution complicates the process of finding a sufficient payment gateway, since the existing ones have constraints on where the merchants can be located. Judo Payments for example requires all the merchants (taxi companies) to be located in the United Kingdom [52]. Taxi companies using TaxiCaller’s services are present across all continents in the world and an ideal solution would therefore be to find a payment gateway which works globally. For this project however it is sufficient if the credit card payment option works in United States of America, Sweden and the larger countries of Western Europe.
4.3
Third-party providers
Several third-party providers where evaluated on TaxiCaller’s requirements. Note that this table may only be accurate at the time of writing this thesis.
