HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science Telecommunications Software and Multimedia Laboratory
Master’s Thesis
A System for Secure Mobile Payment Transactions Teppo Halonen
January 2002
Supervisor: Professor Teemupekka Virtanen Instructor: M.Sc. Kimmo Rytkönen
Abstract HELSINKI UNIVERSITY OF TECHNOLOGY
ABSTRACT OF MASTER’S THESIS
Abstract Author:
Teppo Halonen
Name of thesis:
A System for Secure Mobile Payment Transactions
Date:
3 January 2002
Pages: 78
Department:
Department of Computer Science and Engineering
Chair: Tik-110
Supervisor:
Professor Teemupekka Virtanen
Instructor:
M.Sc. Kimmo Rytkönen
A need for secure payment methods in the mobile access channels has arisen as a result of the increase of on-line commerce. Most of the current payment methods that can be used in conducting transactions e.g. on the Internet have major drawbacks either in terms of functionality, usability, costs or security. The only widely accepted way of securely and reliably authorizing electronic payment transactions is through the use of digital signatures in a PKI framework. Organizations like the WAP Forum and MeT Initiative have made efforts to introduce industry standards for bringing PKI capabilities to mobile phones. The WAP version 1.2.1 compliant handsets already come with support for making digital signatures using the wireless identity module WIM. These new capabilities readily lend themselves to implementing mobile payment systems. This thesis work presents a system that makes use of the MeT WPKI framework in implementing electronic payment authorization. The Mobile Payment System interacts with the merchant, the payer and the issuer as well as supporting back-end systems in coordinating secured payment transactions. The system is engineered to be highly scalable and modular in addition to meeting the high security requirements set to it here and in general terms. The Mobile Payment System enables securely authorizing payment transactions using a standard WAP enabled handset. It fulfils all the basic requirements set to it. However, the success of payment systems based on this technology and these concepts, remains to be decided by the markets and consumers. This paper starts by discussing the enabling security technologies and standards that act as the foundation for this work. The issues addressed include public key cryptography, PKIs – especially X.509v3, the WAP security specifications and the MeT specifications. Some systems closely related to or resembling the one created in this thesis, are discussed. The criteria for the work are presented. The system architecture and design of the Mobile Payment System are discussed on a high level. The special issues of the system implementation and testing are presented and finally the work is analyzed to determine how the criteria were met. The work and the findings are finally summarized in the conclusions chapter. Keywords:
Mobile payments, PKI, WPKI, WAP, WIM
Language:
English
II
Tiivistelmä TEKNILLINEN KORKEAKOULU
DIPLOMITYÖN TIIVISTELMÄ
Tiivistelmä Tekijä:
Teppo Halonen
Työn nimi:
Järjestelmä turvallisille mobiilimaksutapahtumille
Päivämäärä:
03.01.2002
Sivuja: 78
Osasto:
Tietotekniikan osasto
Professuuri: Tik-110
Valvoja:
Professori Teemupekka Virtanen
Ohjaaja:
DI Kimmo Rytkönen
Verkossa tapahtuvan kaupankäynnin lisääntyminen on synnyttänyt tarpeen turvallisille maksutavoille langattomassa mobiiliympäristössä. Useat nykyiset tällaiseen käyttöön tarkoitetut maksamisjärjestelmät kärsivät ongelmista toiminnallisuudessa, käytettävyydessä, hinnassa tai turvallisuudessa. Ainoa laajasti hyväksytty tapa luotettavasti ja turvallisesti valtuuttaa maksutapahtumia on käyttää sähköisiä allekirjoituksia julkisen avaimen infrastruktuurissa. Monet organisaatiot, kuten WAP Forum ja MeT Initiative, ovat luoneet standardeja, jotka tuovat PKI-mekanismit matkapuhelimiin. WAP-määritysten versiota 1.2.1 tukevissa laitteissa onkin jo tuki digitaaliselle allekirjoittamiselle käytettäessä ’langatonta identiteetti moduulia’ WIM:ä. Tämä uusi toiminnallisuus mahdollistaa turvallaisten, mobiilien maksujärjestelmien rakentamisen. Tämä diplomityö kuvaa järjestelmän, joka on pohjautuu MeT:n määrittelemään WPKI-viitekehykseen mobiilien maksutapahtumien valtuuttamisessa. Järjestelmä mahdollistaa vuorovaikutuksessa myyjän, myöntäjän ja tukevien taustajärjerjestelmien kanssa turvallisten maksutransaktioiden suorittamisen WAP päätelaitetta käyttäville maksajille. Järjestelmä on suunniteltu erittäin skaalautuvaksi ja modulaariseksi sen lisäksi, että se takaa korkean tietoturvatason. Se täyttää tässä ja yleisesti siihen kohdistuvat vaatimukset. Se, tulevatko tähän teknologiaan ja malliin perustuvat järjestelmät yleistymään, jää kuitenkin markkinoiden ja kuluttajien ratkaistavaksi. Tämä dokumentti alkaa työn perustana olevien tietoturvateknologioiden kuvaamisella. Julkisen avaimen salaus, PKI:t - erityisesti X.509v3, WAP:n turvallisuusmääritykset ja MeT:n määritykset kuuluvat käsiteltyihin asioihin. Järjestelmiä, jotka ovat saman tyyppisiä kuin tässä kuvattava järjestelmä, kuvataan yleisellä tasolla. Työlle asetetut kriteeristöt määritellään. Järjestelmän arkkitehtuuri ja suunnittelu esitellään yleisellä tasolla. Erityiskohdat järjestelmän toteutuksessa ja testauksessa esitellään ja asettettujen kriteerien täyttämistä analysoidaan. Lopuksi työ ja tehdyt löydökset esitellään tiivistelmässä Avainsanat:
Mobiilimaksaminen, PKI, WPKI, WAP, WIM
Kieli:
englanti
III
Preface
Preface
This thesis is a result of my studies in the Telecommunications Software and Multimedia Laboratory at Helsinki University of Technology. These studies have been at times challenging, but also very rewarding. First of all I want to thank professor Teemupekka Virtanen who acted as the supervisor for this thesis. His views and inputs were very helpful throughout the process. I wish to express my gratitude to my colleagues at TietoEnator. I thank especially Kimmo Rytkönen who acted as my instructor and my manager Olli Lötjönen who has always been very constructive and understanding. I also thank my family and fiancée Katri who have encouraged me to carry out the work all the way to completion. I give special thanks to my friend M.Sc. Sami Jormalainen who took the time to give me some invaluable help and input in the work.
Helsinki, 3rd January 2002
Teppo Halonen
IV
Table of Contents
Table of Contents Abstract............................................................................................................................... II Tiivistelmä.......................................................................................................................... III Preface................................................................................................................................ IV Table of Contents ................................................................................................................V Table of Terms and Abbreviations.................................................................................VII Table of Figures.............................................................................................................. VIII 1
Introduction..................................................................................................................1 1.1 Background ............................................................................................................1 1.2 Goal and Scope of the Thesis.................................................................................2 1.3 Organisation of the Paper.......................................................................................3 2 Secure Mobile Payment Transactions........................................................................4 2.1 Mobile Public Key Infrastructure...........................................................................4 2.1.1 Fundamentals of Public Key Infrastructures..................................................4 2.1.2 X.509 Public Key Infrastructure ....................................................................7 2.1.3 Wireless Application Protocol .......................................................................8 2.1.4 Security vs. Accessibility .............................................................................11 2.2 Electronic Payments.............................................................................................13 2.2.1 Credit Card Payments ..................................................................................13 2.2.2 Electronic checks and Account Transfers ....................................................15 2.2.3 Electronic Cash Payment Systems ...............................................................16 2.2.4 Micropayment Systems................................................................................17 2.3 Existing Systems ..................................................................................................18 2.3.1 Ericsson MCP ..............................................................................................18 2.3.2 Nokia Payment Solution ..............................................................................19 3 Criteria for Design and Implementation .................................................................21 3.1 Functionality ........................................................................................................21 3.2 Technical ..............................................................................................................22 3.3 Security ................................................................................................................23 3.4 Scalability.............................................................................................................24 3.5 Performance .........................................................................................................24 3.6 Modularity............................................................................................................24 3.7 Maintainability .....................................................................................................25 4 The System Specification...........................................................................................26 4.1 The Concept and Relation to Prior Work.............................................................26 4.2 Actors and Use Cases...........................................................................................27 4.2.1 Actors ...........................................................................................................28 4.2.2 Use Case: Payment Request Creation ..........................................................30 4.2.3 Use Case: Payment Authorization ...............................................................30 4.2.4 Use Case: Payment Request Committal.......................................................30 4.3 System Model ......................................................................................................31 4.3.1 System structure ...........................................................................................31 4.3.2 The workflow ...............................................................................................32 4.3.3 Synchronization ...........................................................................................34 4.3.4 Data entities..................................................................................................36 V
Table of Contents
5
6
7
8
4.4 System Architecture .............................................................................................42 System Implementation and Testing ........................................................................46 5.1 The Environments, Platforms and Products.........................................................46 5.1.1 The Development Hardware and Software ..................................................46 5.1.2 The Java Platform ........................................................................................46 5.1.3 The RDBMS and JDBC drivers...................................................................47 5.1.4 Cryptographic Modules................................................................................47 5.1.5 The WAP Gateway and Terminals ..............................................................48 5.2 Special Issues in the Implementation...................................................................49 5.2.1 WAP SignedContent ....................................................................................49 5.2.2 The Directory Interface ................................................................................50 5.2.3 Database Connection Pooling ......................................................................50 5.2.4 Implementing the MVC Design Pattern.......................................................51 5.3 Tests .....................................................................................................................51 5.3.1 Functional Tests ...........................................................................................52 5.3.2 Performance Tests........................................................................................54 Analysis and Discussion.............................................................................................59 6.1 Meeting the Goals ................................................................................................59 6.1.1 Functional.....................................................................................................59 6.1.2 Technical ......................................................................................................61 6.1.3 Security ........................................................................................................61 6.1.4 Scalability.....................................................................................................63 6.1.5 Performance .................................................................................................65 6.1.6 Modularity....................................................................................................66 6.1.7 Maintainability .............................................................................................67 6.2 Maturity of the Solution and the Technology ......................................................68 Further Development Needs .....................................................................................70 7.1 The system data model and actors .......................................................................70 7.2 Administration tools.............................................................................................70 7.3 Payment initiation by WAP PUSH ......................................................................71 7.4 Interfaces ..............................................................................................................71 7.5 WAP Signed Content ...........................................................................................72 Conclusions .................................................................................................................73
References ...........................................................................................................................76
VI
Table of Terms and Abbreviations
Table of Terms and Abbreviations ACID ASN.1 B2B B2C BER DER ECDSA FIPS HST ICC IETF ITU-T Java 2 EE or J2EE Java 2 SE or J2SE LDAP MTBF MTTR NIST PIN PKCS POS RDBMS RSA SDK SSL TPM URL WAP WML WSP WTLS
Atomicity Consistency Integrity Durability Abstract Syntax Notation Business to Business Business to Consumer Basic Encoding Rules Distinguished Encoding Rules Elliptic Curve Digital Signature Algorithm Federal Information Processing Standards Citizen’s Electronic Identification (a public sector PKI deployment in Finland) Integrated Circuit Card Internet Engineering Task Force International Telecommunication Union Telecom Standarization Sector Java 2 Enterprise Edition Java 2 Standard Edition Lightweight Directory Access Protocol Mean Time Between Failures Mean Time To Repair National Institute of Standards and Technology Personal Identification Number Public Key Cryptography Standard Point of Sales Relation Database Management System The RSA Pubic Key Cryptosystem Software Development Kit Secure Sockets Layer Transaction Processing Monitor Universal Resource Locator Wireless Application Protocol WAP Mark-up language WAP Session Protocol WAP Transport Layer Security
VII
Table of Figures
Table of Figures Figure 1 – Public Key Cryptography [20]..............................................................................5 Figure 2 – WPKI SignText [12].............................................................................................9 Figure 3 – The MeT reference model [28]...........................................................................10 Figure 4 – Entities involved in credit card transactions [7] .................................................14 Figure 5 – The Mobile Payment System conceptual scheme ..............................................27 Figure 6 – The process flow.................................................................................................28 Figure 7 – The use case diagram for the system ..................................................................29 Figure 8 – The central classes and interfaces of the Mobile Payment System ....................31 Figure 9 – The sequence diagram ........................................................................................33 Figure 10 – The payment record lifecycle ...........................................................................34 Figure 11 – The SignedContent may be transformed at the WAP Gateway to PKCS #7 ...37 Figure 12 – The software architecture of the system ...........................................................43 Figure 13 – The Functional Testing Environment ...............................................................52 Figure 14 – The Performance Testing Environment............................................................55 Figure 15 – The performance test results – response times .................................................64 Figure 16 – The performance test results – throughput .......................................................64
VIII
1 Introduction
1 Introduction This chapter is an introduction into the thesis. It describes the background for the work and explains the selection of subject. The goals and scope for the work are also presented. Finally the organization of the paper is explained.
1.1
Background
Financial institutions and merchants are increasingly interested in automated electronic forms of payment. The reasons for this are simple; the more the payment process is made electronic, the lower the costs of both the technology to process conventional money and the actual manual processing of payments are. Furthermore the lack of easily accessible and versatile standard means of electronic payments is one of the biggest obstacles for the on-line electronic commerce in the B2C model. The systems so far have all their limitations in terms of usability and security. As the standard wireless public key infrastructure is emerging, there exists a foundation, on top of which payment systems can readily be built. The Internet is more and more being used for conducting commerce. Wide scale automated electronic commerce requires special protocols and systems. A large number of systems and protocols like this exist already for all areas of the e-Commerce process – browsing and selecting goods, ordering, paying and logistics. Probably the most in challenging of area in terms of reliability and information security, payment, is however, lacking widely accepted standard protocols and methods. This is the most important reason for the fact that B2C e-Commerce hasn’t grown as quickly as possible and anticipated by many people [1]. The work on this thesis was started in spring 2001. The mobile technology and legislation surrounding the topic are moving targets – a lot of things have changed during the work. This is why the emphasis in the work was placed on defining the model for the system rather than being able to fix every detail of the implementation.
1
1 Introduction
1.2
Goal and Scope of the Thesis
The goal of this thesis is to specify and implement a system that enables users to perform secure payment transactions using mobile phones. The system is hereafter referred to as Mobile Payment System or just system when the context permits it. The system will be based on the use of Wireless Application Protocol 1.2 [16] compliant mobile terminals that have a Wireless Identity Module [10] - in other words, mobile terminals with a standards-based capability to create digital signatures. As the payment type, the system will support digitally signed authorization by the payer. The money transfer will be based on a customer account scheme, details of which are outside the scope of this thesis. It has to be noted, that the system does not make an attempt to implement electronic money. It is rather a system that applies secure mobile authorization to the business case of mobile electronic payment. The mobile payment system is envisaged to interact dynamically with WAP terminals, certification authorities, electronic merchant systems, point-of-sales terminals and invoicing and account management systems. The communication with those entities takes place over both mobile and fixed networks. This thesis concentrates on systems for the application layer, i.e. layer 7 of the ISO-OSI model [24]. Details of protocols for the lower layers of the model aren’t discussed in this paper, when the comprehension of the discussion doesn’t require in-depth knowledge and understanding of them. The scope of the thesis is limited to specifying and implementing the server-end of the Mobile Payment System with well-defined interfaces to the above-mentioned external systems. However, user interfaces for e.g. the WAP users are implemented. The scope of the thesis also covers setting up a pilot implementation of a merchant system that uses the Mobile Payment System for testing and demonstration purposes. The Mobile Payment System adheres to the standards frameworks defined by the WAP Forum, ITU-T, IETF, RSA Laboratories, the National Institute of Standards and Technology and the MeT initiative. Standards specified by RSA Laboratories, ITU-T and FIPS are foundation for the information security solutions in the system. WAP Forum and the MeT initiative define the ways in which those standards are applied to mobile
2
1 Introduction Internet and WAP in particular. IETF RFCs form the basis for the networked distributed applications. The legislative framework regarding payment systems and their operation as well as that related to digital signing and certificates is evolving in Europe very quickly. New regulations and new interpretations of existing ones are being made. Defining the business models and earning logics for the Mobile Payment System in this regulatory and business environment would be very challenging and in fact out of scope in this thesis.
1.3
Organisation of the Paper
This paper consists of this, the Introduction, plus seven chapters. The second chapter, Secure Mobile Payment Transactions is an overview of the theory, and previous work done in the topic area. The chapter focuses on the different models for secure electronic payment, theory and background on security and cryptography, WAP public key architecture and existing mobile payment systems. Chapter 3, Criteria for Design and Implementation, presents the criteria and requirements for the system to be specified and implemented. The theory of chapter 2 and the criteria presented in chapter 3 are the basis for the The System Specification in the following chapter. The chapter describes first the processes implemented by system, then presents an object-oriented model of the system and finally describes the software architecture for the system. Chapter 5 describes the system implementation as well as the testing of the system. The system implementation is only presented on a rough level of detail. Test cases are presented together with their results. In chapter 6 the system and the test results are analysed and discussed in view of the criteria specified in chapter 3. Chapter 6.1.7 presents the needs for further development for the system. The conclusions made are finally presented in chapter 8.
3
2 Secure Mobile Payment Transactions
2 Secure Mobile Payment Transactions This chapter presents the background for this thesis. The theory of public key cryptography is discussed in detail, as both, the previous work done in the area of electronic payments in general and the theory related to information security, especially public key infrastructures, as it is the fundamental basis for securing any transactions in a distributed environment.
2.1
Mobile Public Key Infrastructure
This chapter presents the emerging wap public key infrastructure (WPKI) specified by the WAP Forum and the MeT. In order to discuss the WPKI, the fundamentals of public key infrastructures in general are also presented. The most widely deployed PKI specification, the X.509, is discussed in a more detail as it is the basis for the WPKI.
2.1.1 Fundamentals of Public Key Infrastructures Public Key Cryptography Traditional cryptography is based on a secret, i.e. a key that can be used to both encipher and decipher information. This of course implies, that all parties who want to do either operation have to know the secret. Public key cryptography, on which public key infrastructures are based, in turn makes use of two keys – one that is kept secret (the private key) and one that is made public and thus known to everyone. Furthermore the keys are such, that it is computationally virtually impossible to deduce the private key by just having knowledge of the public one. In public key cryptography data enciphered with one of the keys, can only be deciphered using the other. The concept is illustrated in Figure 1. W. Diffie and M.E. Hellman first proposed the paradigm of public key cryptography in 1976 [20][21]. Since then it has been the mainstream in strong cryptography as it solves the problem of key management, that is the major problem in more traditional symmetric cryptography.
4
2 Secure Mobile Payment Transactions Public key cryptography can be used to either to accomplish confidentiality or digital signatures. The prior can be achieved when the enciphering key is made public and the deciphering key is kept secret. Signatures, on the other, hand are achieved when the enciphering key is kept secret and the deciphering key is made public. [19]
Public Key
Plain text
Encrypt
Private Key
Ciphertext
Decrypt
Plain text
Figure 1 – Public Key Cryptography [20]
Digital Signatures Digital signatures, the electronic counterpart of handwritten signatures, possesses the following properties: it is authentic, unforgeable, non-reusable and non-repudiable. Furthermore, the signed document is unalterable after the signature. [20] Enciphering a document that is the subject to signing with the secret key, creates digital signature. Others can verify the signature by deciphering the enciphered document with the public key. In practical implementations, to save time, complete documents aren’t encrypted just for the purpose of signing, because of the inefficiency of existing public key cryptography algorithm. One-way hash functions are used to reduce the documents to be signed to digests that can be efficiently enciphered. The verification of the signatures produced in this manner, involves reproducing the digest and comparing it to the deciphered original digest. [20] Blind signatures are a special form of digital signature. They are of great interest especially in electronic cash systems. A blind signature is accomplished, when the signer doesn’t have knowledge of what he is actually signing. A blind signature protocol between A and B works as follows: A selects a random blinding factor that he uses to multiply the message and passes the blinded message to B for signing. B signs the blinded
5
2 Secure Mobile Payment Transactions message and passes the signature to A. A divides the signature by the blinding factor to remove, which removes the blinding factor from the signature. A prerequisite of course is, that the blinding and signature operations are commutative. [7]
Digital Certificates Digital signatures by themselves are not sufficient means for automatic verification of authorities – even if a signature can be verified, there is no guarantee of the fact that the person who made the signature is who he claims to be. Public-key certificates are a powerful means of establishing trust in public-key cryptography. A public-key certificate is someone’s public key, signed by a trustworthy person [20]. A public-key certificate (shortly certificate) normally also contains information related to the secret key related to the signed public key. The trustworthy party naturally signs this extra information along with the key. If the public-key certificate contains information about the identity of the owner of the secret key, the certificate is called an Identity certificate. If the attached information attached identifies the key holder as a member of a group or an organization, the certificate is called an accreditation certificate. An adaptation of the accreditation certificates are authorization and permission certificates. They contain information about the authorities and permissions of the secret key holder – e.g. the person is entitled to withdraw money from account 212-34. [19] There are three parties related to public-key certificates. The requesting party, issuing party and the verifying party or parties. The issuer is normally called a certification authority (CA). The requesting party must perform a proof of possession of the secret key, and to supply sufficient information about his identity that can physically be verified to the CA. Certification authorities can form so called certification or trust chains by certifying each other. Thus the trustworthiness of a CA in a chain depends on that of all the CAs before it in the chain. The first CA – the one that is implicitly trusted – is called the root certification authority.
6
2 Secure Mobile Payment Transactions
2.1.2 X.509 Public Key Infrastructure X.509 is an ITU-T recommendation. Its core is the use public-key identity certificates with each user of a system. The certificates in X.509 are identity based. The recommendation specifies the certificate format as well as the role of the CA. The CAs can create hierarchical trust models - i.e. all but the root-CAs are certified by other CAs. Also cross certification is possible. This enables creating trust relationships between different CA certification trees. [22][4] The X.509 is based on a X.500 directory. According to the paradigm there is a global directory, where there is an entry for each individual. The certificates are stored in the X.500 directory along with other data about the individuals. According to the original approach, the names of the individuals would be globally unique. In real world deployments of the X.509 the directories normally cover only one organization or e.g. the users of some application. In practice there can’t be any strict uniqueness requirements for the names in the X.500 directory, at least across different directories. Thus, also the certificates need, often be considered as a permission to use some application or service, rather than a 100% proof of identity. Normally this is an adequate level of authorization, since the whole notion of certification relies on the issuance process - the users are positively at one point as members of the group and they are issued the certificates. [19] X.509 is currently the most widely adopted PKI. Its current version is X.509v3. [22] Also the WAP PKI is based on the X.509v3. [12] X.509v3 certificate expressed as an ASN.1 has the following format:
7
2 Secure Mobile Payment Transactions Certificate ::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueId [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueId [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL } Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } Name ::= RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
Table 1 – X.509 version 3 certificate [4]
2.1.3 Wireless Application Protocol Wireless application protocol (WAP) is the mobile counterpart of the world wide web in GSM systems. WAP Forum has specified the protocol family making up WAP. The WAP Forum is a consortium of mobile equipment manufacturers, content and service providers, financial institutions, system developers and systems integrators. The specifications cover all the protocol layers from the transport level up and all topic areas from security to content presentation in user interface. The WAP protocol family currently has a status of an industry standard for interactive mobile Internet on top of the GSM system. The current version (fall 2001) that is being more and more supported by new mobile terminals coming to market is 1.2. The 1.2 version includes all the necessary specifications needed to support a PKI based security model in a wireless environment. The WAP Forum specifications related to the functional area of wireless security are: WAP Public Key Infrastructure Specification [12] Wireless Transport Layer Security Specification [11] Wireless Identity Module Specification [10]
8
2 Secure Mobile Payment Transactions WMLScript Crypto API Library Specification [13] WAP Certificate Profile Specification [15] WAP TLS Profile and Tunneling Specification End-to-End Transport Layer Security Specification The five first ones of the specifications are most relevant to this thesis. The other two discuss future ways of securing mobile-to-service communications (end-to-end session security) and are out of scope for the purposes of payment systems based on WAP version 1.2. The WAP PKI specified in [12] (details are in [11], [10], [13] and [15]) defines three levels of transport layer session security, WTLS (WAP Transport Layer Security) classes 1,2 and 3 and a signText- WMLScript functionality for digital signatures. WTLS Class 1 provides encryption, Class 2 encryption and gateway authentication and Class 3 encryption and two-way authentication. The WMLScript signText is a functionality that the user interface can utilize for creating digital signatures. The signText, uses the underlying security element, WIM (Wireless Identity Module), that actually performs the cryptographic procedures and stores the secret keys securely. The process of signing, as well as the preparatory process of certificate issuance in the WPKI model, is illustrated in the Figure 2.
(1) Certificate request
PKI Portal
(2)
CA
(3) Issued Certificate
(4) Public key certificate or a URL to it (via Gateway) (A) Signature request
WAP Terminal
(B) SignText
GATEWAY
(C) Signature and certificate / certificate URL
Certificate Database
(D) User (E) User Certificate Certificate retrieval
Server
(F) Signature Verification
Figure 2 – WPKI SignText [12]
9
2 Secure Mobile Payment Transactions The Mobile Electronic Transactions initiative, MeT, is an initiative like the WAP Forum focusing on creating industry standards for the implementation of secure transaction capabilities in mobile terminals. It was founded by Ericsson, Nokia and Motorola. Later on also other leading mobile phone manufacturers joined in. Any company working on the topic area can join the initiative as an associate member. MeT’s goal is “to establish a framework for secure mobile transactions, ensuring a consistent user experience independent of device, service and network” [28]. Its work is based mainly on that of WAP Forum, IETF and ITU-T. It co-operates strongly with especially the WAP Forum. As the WAP Forum’s goal is to introduce standards for technical issues, the MeT works on areas surrounding those standards – it strives to make the time-to-market of the new security standards shorter as well as to generate as wide an industry acceptance for them as possible. The MeT has introduced a set of specifications related to secure mobile transactions. The MeT Core Specification documents the core functions and features used in various usage scenarios [28]. The MeT reference model illustrated in Figure 3 describes the relevant parties and interfaces needed to establish the framework for secure mobile transactions. MeT also introduces some important concepts. One of them is the PTD, personal trusted device. It stands for a mobile connected device that has the interfaces illustrated in the Figure 3.
Proprietary Interface Issuer
Acquirer Proprietary Interface
Service Registration Interface User Interface Service Execution Interface PTD Security Element Interface
Content Server
Figure 3 – The MeT reference model [28]
10
2 Secure Mobile Payment Transactions
The Service Execution Interface and the Security Element Interface (in Figure 3) are adopted as such from the WAP Forum Specification the User Interface and the Service Registration Interface are more or less defined by the MeT itself. The rest of the interfaces are up to the industry to define on a case-by-case basis. Sometimes the task may even be very easy, as the Issuer, Acquirer and Content Server roles may be somewhat overlapping or interlinked (the Acquirer and Issuer roles are explained in section 2.2, while credit card payments are discussed). The MeT discussion in the MeT associate member summits has focused a lot on the personal transaction protocol related issues as well as the business framework. The personal transaction protocol is a protocol for application level communication between an Internet-connected device, e.g. a PC, and the PTD over mediums like BlueTooth or IrDA. The MeT model is the basis for the system that is specified in this thesis. The idea of having the ability to make digital signatures in the mobile phone as well as the private key management functionalities provided the WIM are the foundation for the system.
2.1.4 Security vs. Accessibility In a public key cryptosystem the level of security achieved should always be dependent only on the key lengths, not the used crypto algorithms [20]. It is also clear, that the prerequisite for having any security at all in a public key cryptosystem is that the secret key is kept truly secret. This is actually one of the most problematic issues in any PKI deployments. Issuing mobile entities (entities that are not connected statically to any system, network or place) public key certificates, is only meaningful if those entities have access to their secret key, when ever they need to perform crypto operations using that key. The traditional scenario for secret key management is, that the secret key is stored somewhere on the hard drive of a PC and it never leaves it. This doesn’t allow for a lot of mobility – the only way the secret key can be used, is by having access to the PC. Of course the key could be carried along on a floppy, but that would mean that the key can
11
2 Secure Mobile Payment Transactions only used, when there is a compatible floppy disk drive available. Carrying a floppy disk with a secret key around is also hazardous, since it might be lost, stolen or damaged. The secret key management is clearly an issue, where more security may require compromising the level of ubiquitous usability. Alternatively a high security, widely deployed and accessible scheme should exist. Currently there are two main streams of secret key management solutions: a centralized and a distributed smart card based stream. Centralized Secret Key Management In a centralized secret key management scheme, the key pairs are generated centrally on a key server. The private key is stored permanently on the server and it never leaves it. The key holders have access credentials to the server (i.e. user id and a password), which they can use to access their key, and perform signing and encryption operations. The 3D SET, specified by Visa and some other credit card companies makes use of the centralized scheme [7]. It is an extension of the normal SET, which was based on a distributed scheme. The problem with the distributed SET scheme is, that the secret keys have to be stored on the PCs of the users and special client software has to installed in order to use the SET system. The fundamental problem of a centralized secret key management scheme is that doesn’t give the key holders real control over their secret keys. Depending on the authentication scheme used to access the key, the level of security reached can vary greatly – it may even be non-existent, in case a user id and a badly selected password is used.
Distributed Secret Key Management Using ICCs Integrated circuit cards, ICCs (also called smart cards) are a viable technology for storing secret keys. The ICC is a credit-card like piece of plastic, with a small microchip cast inside it. On top of the card there are the connectors for the chip pins. In a public key cryptography application making use of ICCs, the key pair is normally generated inside the ICC. The card communicates the public key out, but the secret key
12
2 Secure Mobile Payment Transactions is kept inside it. The card performs the cryptography operations that need the use of the secret key. Typically there is a PIN code authentication for using the secret key. The advantage of embedding the secret key into the chip in a smart card, is that the key can not be extracted from the card by any means – the card is said to be tamper resistant. [7]
2.2
Electronic Payments
Forms of, at least partially, electronic payments have been around since late 1970s [6]. As a communications infrastructure is a prerequisite for electronic payments, the enormous expansion of the Internet has enabled a fast progress in the area during the 1990s. Electronic payment systems are classified in to four groups in [6]: 1. Credit card based systems 2. Electronic checks and Account Transfers 3. Electronic cash payment systems 4. Micropayment systems The grouping is based for the most part on the business model behind the payment solutions. The grouping may not be the best, in terms of the functional perception of the systems but it serves the purpose of presenting the different types nicely. Differences between the different groups of payment systems are not in all cases very dramatic and in many cases a real life system is hard to classify to belong to any one of the groups –for example some of the micropayment schemes could be used to implement e.g. electronic checks.
2.2.1 Credit Card Payments Credit cards have payments set against an account with a pre-agreed repayment scheme. The entities involved in a credit card transaction are illustrated in the figure below – the scheme is inherent to all account based schemes, and is thus useful to understand. Both the credit card issuers and the acquirers are members of a card association, e.g. Visa or
13
2 Secure Mobile Payment Transactions MasterCard. Normally both of them are banks. The merchants have association with the acquirer, who provides the necessary infrastructure for the merchant for accepting credit card payments. The general schema doesn’t change even if the transactions were direct debits from a bank account or a pre-paid account.
Card Association
Issuer
Acquirer
Card holder
Merchant
Figure 4 – Entities involved in credit card transactions [7]
Payments using credit cards can be made both when being physically present and e.g. over telephone or Internet – i.e. when the card holder and the merchant aren’t colocated. This is called a MOTO (mail order / telephone order) payment transaction. Clearly this form of payments using credit cards increases the risk borne by the merchants – the merchant doesn’t have any means to positively prove the transaction actually took place if the cardholder decides to repudiate it afterwards [7]. The Secure Electronic Transaction, SET, protocols were developed to overcome the possibilities of fraud in credit card transactions over the Internet. It defines two major interfaces – the one between the cardholder and the merchant and that between the merchant and the acquirer (called the payment gateway in the SET context). SET relies on a certification hierarchy, based on the X.509 PKI. Original SET makes use of client software (SET wallet) installed on each cardholder’s PCs. The software is primarily used to perform digital signing and authentication operations as well as the key and certificate management. As the key problem with SET has been the accumulation of the critical mass of cardholders willing to install the client software another version of SET has
14
2 Secure Mobile Payment Transactions been developed. The Three Domain SET (3-D SET) is based on having the SET Wallets on a centralized server. The Wallet Server that is accessed with a web browser can perform the same operations as the original client software while removing the requirement of client installation. On the other hand the model compromises security by weakening the level of cardholder authentication.
2.2.2 Electronic checks and Account Transfers Check, be it electronic or paper, is an authorization to transfer funds from the payer’s account to the payee’s account. Also the process of handling the checks is similar with both paper and electronic ones – optimally banks can make use of their existing clearing and settlement infrastructure, in case of private electronic check systems, a different scheme may be exercised: 1. The payer authorizes the transfer/payment by writing and signing the check 2. The payee’ delivers the check to its bank for clearing and settlement 3. The banks use a clearing and settlement network to transfer the funds Most of the electronic payment systems on the Internet rely on a centralized account model, where both the payer and the merchant need to have accounts in the same institution and funds can thus be transferred directly from one account to another. Frameworks that support inter-payment provider transfers have also been defined. The most prominent one of those is the FSTC (Financial Services Technology Consortium, a joint organization between U.S. banks) initiatives. The FSTC has defined a format for electronic checks called the FSML. The FSML has an XML like syntax for describing financial documents – especially checks. The FSTC has also defined a number of different functional flows in electronic check payment in the inter-bank case that enable flexible implementation of the actual payment systems. In centralized account scenario, the most problematic issues are naturally the ways for funding and debiting the accounts. From the payer’s perspective, funding the account is normally done by transferring funds from a bank account or by a credit card to the account at the payment provider. In any case, some other form of electronic payment is
15
2 Secure Mobile Payment Transactions normally needed for funding the account. The payment provider normally provides APIs for the merchants for debiting the payers’ accounts on-line. The merchants normally get the funds out of their accounts with the payment provider via traditional automated account transfers. [7]
2.2.3 Electronic Cash Payment Systems Cash is the most popular form of payment in retail transactions between consumers and businesses – depending on country 75% - 95% transactions are paid in cash [7]. The attractive properties of cash as form of payment are: Acceptability – cash is almost always accepted Guaranteed payment – cash is safe for the merchant to accept. If the money isn’t forged the payment is always honored No transaction charges Anonymity Many electronic cash payment systems are more or less focusing on a subset of the above. The key advantage of electronic cash over physical cash is the lack of running handling costs. The downside is the fact there isn’t a well-established global infrastructure for electronic cash. Clearly electronic cash systems also attract attempts at fraud – someone may try to counterfeit tokens of electronic money, issued electronic money may be attempted to be ‘double-spent’, i.e. spent many times. Criminals might also abuse electronic cash payment systems for tax evasion, bribes or money laundering, especially when the blind signatures are used. As the goal of this thesis is not to implement electronic money, this type of payment systems is not discussed in more detail.
16
2 Secure Mobile Payment Transactions
2.2.4 Micropayment Systems In applications, where the number of transactions between each payer and the merchant is large and the amount of the each individual transaction is low, the transaction processing cost grows proportionally large. Traditionally this kind of setting is addressed by a subscription scheme – the use of a service is paid for on an estimate basis; a bulk amount is paid for which the use of a service is bought for a certain period of time. In practise there is, however, a clear need to be able to pay per use – as some people might only occasionally use the service that some use very frequently. Micropayment systems are targeting this problematics. There are many different micropayment schemes. A group of micropayment systems are based on probabilistics or computational cost of ‘minting’ payment tokens. E.g. PayWord, MicroMint (proposed by Rivest and Shamir) and the probability-based schemes all relax security while reducing processing costs – small-scale fraud may even be relatively easy. Other micropayment schemes aim at providing fool proof secure payments while also reducing the transaction costs, possibly at the cost of flexibility and elegance. [7] A very representative example of a micropayment scheme belonging to the latter group is jalda. It is a proprietary standard for electronic micropayments specified by the EHPT – a joint venture between Ericsson and Hewlett Packard. Jalda is a protocol and an API for implementing charging for service or goods. It is based on a concept of a payment session that is initiated by the payer by accepting and electronically signing a session contract with the merchant (vendor in jalda terminology). A jalda payment provider verifies the contract for the vendor. After the contract has been verified by the payment provider, the vendor can start sending ‘ticks’ indicating that the service is being consumed and the payer should be charged. Clearly the protocol is intended for uses like multimedia services, where the user subscribes to e.g. a video stream and he is invoiced during the video plays ‘tick’ at a time by the service vendor. The protocol makes no constraints on what channel (web, DVB-T, mobile, etc.) the actual service is consumed over. The protocol is also flexible in terms of the way the digital signature is created. [7][29]
17
2 Secure Mobile Payment Transactions
2.3
Existing Systems
In this section some systems that resemble in concept the one that is to be specified in this thesis. The functionalities offered by these systems are described on a high abstraction level.
2.3.1 Ericsson MCP The Ericsson Mobile Commerce Platform (MCP) is based on two products – the Mobile e-Pay and the EHPT SafeTrader. The Mobile e-Pay is a front-end product for authentication of mobile subscribers. It works over SMS and WAP. In SMS mode the authentication of the users is based on a PIN code, that the user has to submit to the server or optionally a customized SIM Toolkit solution that enables the use of PKI based strong authentication over SMS. With WAP, currently only the PIN code authentication over the network is permitted – in future releases also WAP 1.2 compliant WTLS class 3 and signText based methods are said to be supported. When no signing capabilities exist in the client and a PIN authentication is used, the Mobile e-Pay server performs the signing on behalf of the client. The approach is based on a kind of a wallet server concept. The setting is similar to that of the 3-D SET discussed in section 2.2.1. The EHPT SafeTrader is a back-end payment provider system. It is in no way limited to the mobile channel. In practise the SafeTrader is a user account management system. The merchant and payer interface towards the SafeTrader is jalda. It is intended to be used as the core of a payment provider infrastructure. There are interfaces for all the necessary external systems, like invoicing, pre-payment, revenue assurance and business intelligence. The interfaces are, however, rudimentary and based on file transfer of data. The fact that the product is based on the proprietary jalda as the integration protocol towards merchant systems doesn’t pose problems, as there are publicly available APIs offered free of charge for major programming languages. The inherent nature of jalda, however, forces the merchant to adopt a payment session concept, which may not be perfectly optimal for all purposes. The Mobile e-Pay and the SafeTrader bind together to form a complete payment provider infrastructure, the MCP. However, they do not depend on each other in any way. When put together, the Ericsson MCP is a quite versatile one. The problem with the
18
2 Secure Mobile Payment Transactions package is, that is also pretty expensive considering the problems it solves – quite a lot of integration is required to set up a complete system with all the links to the necessary supporting systems. The Mobile e-Pay is a solution in some ways similar to the one specified in this thesis. However, in the Mobile e-Pay support for MeT/WAP 1.2 compliance is only promised in future releases. [31][30]
2.3.2 Nokia Payment Solution The Nokia Payment Solution enables payments in mobile terminals. Its focus is on payments for electronic content delivered from web or mobile portals, although the Payment Server can be also used for payments for other goods and services. The solution consists of five major components: the Nokia Payment Server, Nokia Payment Proxy Server, Nokia Virtual Purse application and two administrative tools. The payment concept is based on consuming credits from the pre-paid account managed in the virtual purse application. The payments are authorized using digital signatures created on a WAP 1.2 -based WIM. The Payment Proxy Server monitors and analyses the content headers in HTML and WML pages moving between the content providers and merchants. Whenever it intercepts priced content it initiates a payment transaction and redirects the user to the Payment Server. Pricing and provisioning of the digital content and the payment service can be done through the administration tools. These tools are also used to monitor the events occurring in the payment server. The Nokia Payment Server manages the interfaces towards financial institutions and e.g. telecommunications billing systems. The solution can thus be integrated to the whole of the enterprise infrastructure. The Nokia Payment Solution suite is a comprehensive set of services that can readily be used to establish a mobile payment service. At the package was studied for the purposes of this thesis, it was, however, still in development phase and e.g. the WIM-based digital signing capabilities were only announced on paper.
19
2 Secure Mobile Payment Transactions What comes to the system structure of the Nokia Payment Server, it resembles in functionality that of the Mobile Payment System presented in this paper. The concept of automated on-line payment of digital content is, however, not embraced in the Mobile Payment System as it is in the Nokia suite.
20
3 Criteria for Design and Implementation
3 Criteria for Design and Implementation This chapter presents the criteria that the system should fulfill. There are two groups of criteria that have been considered relevant: functional and architectural. The functional criteria define what the system should be able to do, and the architectural criteria, i.e. security, scalability, performance, modularity and maintainability define how the system should be constructed. The criteria specified in this chapter will be the foundation for the analysis of the solution in the chapter 6 Analysis and Discussion.
3.1
Functionality
The goal of the thesis is to construct a system that enables payments using a WAP 1.2 compliant mobile terminal which is equipped with a WIM. The criteria to be fulfilled by the system in terms of functionality are: 1. The system should not implement electronic money – rather a secure means of authorization of payments, either on credit or direct debits. 2. There are three actors that interact with the system: the merchant, the payer and the issuer 3. The system should enable merchants to register payment transaction requests, with details about the payment transaction into the system 4. The system should maintain payment information including the status of the payment transaction requests in the system 5. Merchants should be able to query the status of a payment transaction request from the system 6. Merchants should be able to commit the payment transactions, when the payers have authorized the transaction and the authorization is verified by the system
21
3 Criteria for Design and Implementation 7. When committed, the transactions should be possible to register automatically to an external system by the Mobile Payment System 8. The payers should be able to retrieve payment contracts formulated from the payment requests from the system for authorization by using their WAP terminal, and they should be able to submit a digital signature as authorization to the system 9. The system should be able to verify the signatures made by the payers 10. The system should be able to verify the payers’ certificates. I.e. a validity- and a CRL check should be included in the verification. 11. The system should be able to query the payer’s certificates from an LDAP directory, in case there is only a reference to the certificate in the signature. 12. The system should be able to verify the payer’s creditability from an external system after the payer has authorized the transaction.
3.2
Technical
Some technical criteria should be fulfilled by the system, so that it is in line with the standards of the customer organization and those of the industry in general. 1. The system should be implemented in Java 2 so that it can easily be integrated with other systems implemented on the same platform 2. The system should use Oracle 8i as the system database 3. The system should support merchant systems implemented using any relevant technology 4. The system should be based on and support the WAP 1.2.1 based PKI
22
3 Criteria for Design and Implementation
3.3
Security
The system’s security model should be in line with that specified by the WAP Forum in [12]. The system design and implementation doesn’t need to consider the issues related to key lengths, key generation, certificate issuance and distribution, certificate revocation, mobile terminal implementation or security module implementation. This thesis makes the following assumptions about the above issues: 1. The signing key length used by the security element, i.e. WIM, in the mobile terminal is sufficiently long to provide a sufficient level of security. E.g. a key length of over 1280 bits proposed by [20] for corporate use is assumed. 2. The keys are generated in such a manner, e.g. inside the security element, that they cannot be recovered by any means. 3. The issuer or CA of the public key certificates enforces a high security practice in authentication of the subjects before issuing and distribution of the certificates. 4. The issuer or CA keeps the CRLs up-to-date in real time. 5. The intranet area in the target infrastructure, i.e. the environment where the system is to be installed, is considered secure in nature. The criteria for security that the system has to fulfill are related to the secure and error free implementation of the functionality described above, as well as the design of the service architecture in a way that malicious attacks against the system can be prevented. The following criteria have to be fulfilled by the system: 1. No unauthorized entity may gain access to the system or its data. 2. Access to the system and the system database has only to take place through the specific interfaces provided by the system. There may not be any ‘back doors’. 3. The communications between the clients and the system have to be encrypted.
23
3 Criteria for Design and Implementation
3.4
Scalability
The system should be scalable. I.e. the response times exhibited by the system should increase linearly as the load on the system increases linearly, when not near the maximum capacity of the system. Scalability also means, that it should be possible to increase the capacity of the system linearly by linearly increasing the capacity of servers that host the system. There are two methods that can be used to scale up the system capacity – either by increasing the number of servers running the software, or by increasing the processing capacity of each of the servers running the software. An exact measure of the scalability of the system is not defined as a criterion. Rather it is just expected that a scalable behavior be exhibited in tests run on the system. In the environment in which the system is expected to operate there may be up to 100 000 daily users – the system should be able to cope with this kind of load.
3.5
Performance
The system should have good performance. As a working hypothesis, a response time of 1 to 2 seconds for each of the services provided by the system should be achieved under normal load. The performance should be illustrated by running tests against the system.
3.6
Modularity
The system should be built in such a manner, that it is possible to attach new functionality into the modules to the system, without influence to other, parallel modules. This is especially important for the interfaces towards other external systems - the interface implementations should be ‘pluggable’, i.e. re-building the entire system in order to take into operation a new interface implementation should not be necessary. It is also important that when ever possible, use of ready-made components or libraries should be considered to avoid reprogramming existing functionality.
24
3 Criteria for Design and Implementation
3.7
Maintainability
The system should be easy to manage. At the very least, the system’s operation should be possible to follow by inspecting the system logs. The system administrator should be able to correct problems by some simple means.
25
4 The System Specification
4 The System Specification The goal of this chapter is to present the necessary framework and guidelines for the implementation of the system. Based on the criteria specified in the previous chapter, the functionality and the processes that the system implements and a high level logical and structural model for the system will be specified. The model is further concretised to a system architecture. The description approach in this chapter is based on UML notation – the functional processes are presented as use cases, the system is modelled as UML class diagrams. The interaction between different parts of the system and the actors are illustrated in a UML sequence diagram. The diagrams are presented only superficially, i.e. nonessential features are not discussed.
4.1
The Concept and Relation to Prior Work
As defined already in the introductory chapter, the goal of this thesis is to design a system that enables authorization of mobile payment transactions using a WAP terminal with standard cryptographic functionalities. The need for the system arises from several factors. Firstly, that most feasible way to achieve secure payment transactions seems to be through the use of a public key cryptography based scheme. On the other hand, a clear demand arising from a ubiquity of service usage cannot be satisfied to the full by currently available systems at the same time with the strict security requirements. Chip card based schemes, the like of HST and EMV come close to solving the issue, but a wide network of compliant card readers need to be deployed. Finally, a new generation of connected mobile terminals with a similar capacity for digital signing (i.e. WAP 1.2.1 together with a WIM) is becoming available. This creates a possibility for building a PKI based payment infrastructure, that doesn’t require any proprietary solutions for connectivity (e.g. card readers for the ICCs and closed protocols endorsed by credit card companies), signature processing or PKI functionalities and services.
26
4 The System Specification The system presented in this chapter doesn’t fit into any one of the business model based classifications presented in 2.2 Electronic Payments. This is due to the fact that the goal of this work isn’t do design a system that supports one single money earning logic, but to produce a generic system that enables authorization of payment transactions as a whole. The Figure 5 presents the Mobile Payment System concept as a schematic sequence diagram from the perspective of the payer. The actual money traffic is not illustrated in the schema. This is because the Mobile Payment System is not actually handling the money traffic – it is merely registering and forwarding the authorized and validated payment transactions. The ultimate goal is to have money move from one entity’s account to that of another entity. The solutions for implementing complete monetary process are outside of the discussion of this paper.
3. Payment Authorization
Mobile Payment System
4. Payment 2. Information about information expected payment 1. Selects the goods for purchase
5. Delivery of goods
Merchant System
Figure 5 – The Mobile Payment System conceptual scheme
4.2
Actors and Use Cases
The Mobile Payment System implements three core use cases. Payment request creation
27
4 The System Specification Payment request authorization Payment request committal Putting these three use cases (when successfully completed) together in the above sequence, completes a mobile payment transaction. The use case of Shopping, is not included in the scope of the system. Naturally it is, however, expected that the payer has, before payment, done some ‘Shopping’, i.e. selected goods he wants to purchase. The use case of Check-out, i.e. retrieval or shipping of the purchased goods is similarly out of scope. It is implemented by the merchant system. The Figure 6 illustrates the sequential relationships between the use cases in form of a process chain. In the figure, the black bubbles denote use cases implemented by the Mobile Payment System. The gray ones are implemented by external systems.
Shopping
Create Payment Request
Authorize Payment
Verify Credit
Commit payment
Check certificate revocation
Check-out
Debit or Invoice Payment
Figure 6 – The process flow
4.2.1 Actors There are two main actors that participate in the use cases: the payer and the merchant. The payer has two roles, a PCD (Personal Communication Device) role and a PTD (Personal Trusted Device) role. These roles denote, the fact that the user may use different access channels for the shopping use case and the payment authorization use case. There are five different systems interacting in the process chain. The systems are: Mobile Payment System Merchant System
28
4 The System Specification Invoicing or Account Management System Credit Verification System Certification Authority The role of the Mobile Payment System in relation with the other is that of an integrator - the Mobile Payment System co-ordinates the payment transaction processing between the actors and the systems. The Figure 7 illustrates the relationships of the actors, systems and the use cases.
Payer (PCD role)
Payer (PTD role)
Merchant
Create Payment Request
Shopping
Commit payment
Authorize Payment
Mobile Payment System
Check-out Debit or Invoice Payment
The Merchant System
An Invoicing or Account Management System
Verify Credit
A Verification System
Check certificate revocation An issuer of the certificates
Figure 7 – The use case diagram for the system
The three individual core use cases are described in detail in the following subsections.
29
4 The System Specification
4.2.2 Use Case: Payment Request Creation After the payer has selected the goods and proceeded to the payment phase in the merchant system, the merchant system creates a payment request data entity and submits it to the Mobile Payment System. Each individual payment request entity has a unique identifier both in the merchant system and the payment system. Those identifiers can be used to reference the individual requests in later stages of the transaction. The Mobile Payment System registers the payment transaction into persistent data storage.
4.2.3 Use Case: Payment Authorization When the merchant has registered the payment request into the Mobile Payment System, the payer should authorize the payment using his PTD (i.e. in PTD role). The payer performs the authorization by requesting a payment contract for signing using his PTD from the Mobile Payment System. The payment contract is produced by the system based on the information supplied by the merchant during payment request creation. After the payer has verified the information on the payment contract to be correct (i.e. the recipient of the payment, the object of the payment and the amount) he creates a digital signature of payment contract and submits it to the Mobile Payment System. The system verifies the signature, the correlation between the original contract and the signature and the authority of the payer to perform the payment transaction. The Mobile Payment System also verifies the creditability of the payer from the verification system.
4.2.4 Use Case: Payment Request Committal After the payer has successfully authorized the payment request, the merchant needs to be informed about it. After the merchant receives the information, it commits the payment transaction. The committal causes the transaction information to be propagated to external invoicing or payment account systems.
30
4 The System Specification
4.3
System Model
This section describes the system design model. The system is described from a structural point of view – the major entities that make up the system are presented and discussed. The emphasis is on describing the business logic fundamentals. The details of implementation, like utility classes and specificities of the sequence diagram etc. are left out of the discussion.
4.3.1 System structure In Figure 8 the core of the system is illustrated in UML form. There are of course a number of other classes that the system uses and consists of. They are not discussed in this section, since their details are a matter of implementation.
PaymentServer +submitPaymentRequest(in paymentRecord, in paymentRecord : PaymentRecord) +getReceiptForSigning(in merchantId : long, in merchantRef : String) +submitSignedReceipt(in signedContent, in signedData : PKCS7SignedData) +queryPaymentStatus(in merchantId : long, in merchantRef : String) +commitPayment(in merchantId : long, in merchantRef : String) «interface» PaymentStoreInterface +storePaymentRecord(in record : PaymentRecord) +getPaymentRecord(in merchantId : long, in merchantRef : String) : PaymentRecord +setPaymentRecordStatus(in merchantId : long, in merchantRef : String, in status : PaymentStatus) +getPaymentRecordStatus(in merchantId : long, in merchantRef : String) : PaymentStatus +storeSignature(in merchantId : long, in merchantRef : String, in signature : PKCS7SignedData)
«interface» InvoicingSystem +storeTransaction(in paymentRecord, in identity)
«interface» AuthorizationSystemInterface +verifyPayment(in identity) : double
PaymentRecord +merchantId +merchantReference +heading +total +contract +signature +lineItems +issuedTime +authorizedTime +status
Figure 8 – The central classes and interfaces of the Mobile Payment System
31
4 The System Specification
The core of the Mobile Payment System is the payment server. It co-ordinates the transaction and the work flow in the system. It also binds together the different external systems involved. The interfaces towards the external systems are defined clearly – adding support for new system instances is just a matter of implementing the interface. The payment record is the abstraction of a payment transaction. It holds the information pertaining to payment elements and its state in the system.
4.3.2 The workflow The workflow of a payment transaction is illustrated in the UML sequence diagram in Figure 9. The payer has two roles in the sequence diagram – in the PCD role the payer does the ‘shopping’ and initiates the payment by indicating the merchant that he wants to pay. In the PTD role the user performs the actual payment. The merchant in the sequence diagram represents the merchant system – the other parties in the diagram are those represented in the class diagram of Figure 8. All the calls in the diagram are synchronous and, depending on the context, return a value.
32
4 The System Specification
Payer (PCD role)
Merchant
Payer (PTD role)
PaymentServer
InvoicingSystem
AuthorizationSystem
PaymentStore
do Payment! submitPaymentRequest() storePaymentRecord()
getReceiptForSigning() getPaymentRecord()
signText()
submitSignedReceipt() verifySignatureAndSubject() setPaymentRecordStatus() verifyPayment()
setPaymentRecordStatus()
payment Done! queryPaymentStatus() getPaymentRecordStatus()
commitPayment() storeTransaction()
setPaymentRecordStatus()
Figure 9 – The sequence diagram The payment transaction is managed as a payment record entity in the Mobile Payment System. The payment record has a certain life cycle in the system. The states and the state transitions allowed for the payment record are illustrated in the Figure 10. The PaymentServer controls the state transitions.
33
4 The System Specification
create and submit
New
cancellation by merchant
get contract for signing cancellation by merchant Pending
submit signed contract
Not set
cancellation by merchant
Authorized
commit payment Committed
archival
archival
Figure 10 – The payment record lifecycle
4.3.3 Synchronization The complete payment transaction, as seen in the Mobile Payment System, involves multiple parties. The synchronization of the actions performed by the different parties is a challenge for the system. The goal is naturally, that everything happens in the correct sequence and as swiftly as possible and with little manual intervention by the payer – i.e. there aren’t too long latencies between the actions. As the design of the system is based on a distributed and open paradigm, it is not possible to require two way synchronous communications between all of the entities, i.e. the communication cannot necessarily be initiated from both ends. Clearly, some compromises need to be made, in order to maintain openness and distribution. Below, all communication links that exist between entities participating in the payment transaction are discussed and the choice of the synchronization model is explained.
Merchant – Payer The issue of synchronization between the merchant and the payer culminates into the phase, where the merchant should be indicated that the payment has been successfully carried out. The optimal case would be, that the merchant would automatically get the
34
4 The System Specification information of the completed payment from the Mobile Payment System. This isn’t, however, easily accomplished – it would imply quite a lot of technical requirements for the merchant system that might not be realistic to comply with. An asynchronous mode for synchronization was chosen. The sequence of events goes as follows: 1. The payer submits the signature to the Mobile Payment System 2. The Mobile Payment System verifies and stores the signature. 3. The payer indicates to the merchant system, that the payment is done 4. The merchant system queries for verification from the Mobile Payment System
Payer – Mobile Payment System Synchronization is an issue when the merchant system passes control to the Mobile Payment System. At this point, the user should start using a different channel and device to perform the authorization operation over WAP. Optimally, the user is automatically ‘thrown’ the receipt onto his WAP terminal – this is possible with two conditions: 1. The user’s A-subscriber number has to be known in the merchant system 2. The user has a WAP PUSH capable WAP terminal If the conditions are in force, the merchant system can make a SI (Service Indication) or SL (Service Loading) push message to the user, where a link to the Mobile Payment System with the payment reference identifier is passed as a parameter. In case the conditions aren’t met, the merchant system can show the payer the payment reference identifier on the user interface. The user is left the task of indicating the Mobile Payment System the reference. This scenario is not as user friendly, but also involves fewer costs, as WAP push is not made. The user may also remain anonymous towards the merchant system.
35
4 The System Specification Merchant – Mobile Payment System The previous interfaces already present the issues of synchronization between the merchant system and the mobile payment system. The problem of synchronizing the whole of the transaction, including the indication of completed payment from the Mobile Payment System to the merchant system could be solved in two ways: 1. The connection from the merchant system to the Mobile Payment System could be left open after the merchant system has transmitted the payment receipt. The merchant system could thus remain ‘on-line’ waiting for the indication of payment completion. 2. The merchant system could implement a call-back mechanism – e.g. a HTTP server, that would listen for indications of completed payments. Both of the above would imply a high consumption of resources in especially on high volume sites. In some cases the second alternative isn’t even possible without major modifications to the existing merchant infrastructure. In any case this would create potential security threat as extra ‘holes’ are opened into the merchant system. As it is not known beforehand, how long it takes for the payer to complete the payment, there is a possibility of connection time-outs. Both of the above alternatives would make it possible for the merchant system to wait for the payment completion before the payer is served a new page. The time-out issue obviously exists also here. In this project it has been decided to keep the synchronization as straightforward as possible. As described above, in most of the interfaces an asynchronous communication mode was chosen. In part this also ensures the good scalability of the system – no state is necessary to store in the runtime systems.
4.3.4 Data entities All the data entities that are used in communications between entities are described here in ASN.1 notation. This doesn’t mean, however, that e.g. standard BER encoding of the ASN.1 entities would be used between all the entities – the encoding is rather selected
36
4 The System Specification on case-by-case basis. ASN.1 notation for describing the data entities is used just because it is a very generic approach.
Signed Data The payment authorization digital signature is relayed from the mobile terminal as a SignedData entity. The entity follows the specification in the WMLScript Crypto Library [14] (hereafter WAP SignedData). It is a simplified and wireless optimized form of the generally used PKCS #7 SignedData entity. However, there exists a direct mapping from the WAP SignedData to the PKCS #7 SignedData. According to the WMLScript Crypto library, the WAP Gateway may take responsible of making the transformation between the two. The early implementations of the WAP gateways are, however, not expected to have the transformation functionality. This is why the WMLScript SignedContent has to also be handled on the application level. For versatility, the Mobile Payment System, will be able to handle both types of signature formats. Case 1 Mobile Terminal
SignedContentWAP
WAP Gateway
SignedDataPKCS #7
Application
Case 2 Mobile Terminal
SignedContentWAP
WAP Gateway
SignedContentWAP
Application
Figure 11 – The SignedContent may be transformed at the WAP Gateway to PKCS #7
Essentially, both the WAP SignedContent and the PKCS #7 SignedData contain an encrypted digest of the original document, information about the digest and encryption algorithms, information about the signer, i.e. his certificate and optionally the original document. In this case the inclusion of the original document into the signature is not necessary but advantageous. If the original content is included, the signature entity is a self sufficient, unambiguous proof of the payment authorization. The encoding format of the PKCS #7 signed content is ASN.1 with BER. The WMLScript SignedContent is
37
4 The System Specification encoded using a proprietary encoding specified in [12]. The correlation between SignedContent and the PKCS #7 SignedData is illustrated in the Table 2 and Table 3.
SignedContent ::= SEQUENCE { version INTEGER, signature Signature, signerInfos SignerInfo, contentInfo ContentInfo, authenticatedAttribute AuthenticatedAttribute } Signature ::= SEQUENCE { algorithm DataSignatureAlgorithm, signature OCTET STRING } DataSignatureAlgorithm ::= ENUMERATED { rsa_sha_pkcs1 (1), ecdsa_sha_p1363 (2) } SignerInfo ::= SEQUENCE { signerInfoType SignerInfoType, sha_key_hash [1] OCTET STRING OPTIONAL, wtlsCertificate [2] WTLSCertificate OPTIONAL, x509Certificate [3] OCTET STRING OPTIONAL, x968Certificate [4] OCTET STRING OPTIONAL, certificateURL [5] OCTET STRING OPTIONAL } SignerInfoType ::= ENUMERATED { sha_key_hash (1), wtls_certificate (2), x509_certificate (3), x968_certificate (4), certificate_url (5) } ContentInfo ::= SEQUENCE { contentType ConentType, contentEncoding INTEGER, contentPresent BOOLEAN, content OCTET STRING OPTIONAL } ContentType ::= ENUMERATED { text (1), data (2) } AuthenticatedAttribute ::= SEQUENCE { attributeType AttributeType, gmtutcTime SET OF INTEGER OPTIONAL, signerNonce OCTET STRING OPTIONAL } AttributeType ::= ENUMERATED { gmt_utc_time (1), signer_nonce (2) }
Table 2 –SignedContent in WMLScriptCrypto library (with relevant parts) [14]
38
4 The System Specification SignedData ::= SEQUENCE { version Version, digestAlgorithms DigestAlgorithmIdentifiers, contentInfo ContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier SignerInfos ::= SET OF SignerInfo Version ::= INTEGER ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } ContentType ::= OBJECT IDENTIFIER Data ::= OCTET STRING SignerInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, digestAlgorithm DigestAlgorithmIdentifier, authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, encryptedDigest EncryptedDigest, unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL } EncryptedDigest ::= OCTET STRING
Table 3 –SignedData in PKCS #7 (with relevant parts) [9]
PaymentRequest The merchant relays the information about a payment it is expecting to be made in a PaymentRequest entity. The payment request consists essentially of identifying information and payment details, like the price and the basis of the transaction. The expected payer is not specified, as it is not relevant who is paying.
39
4 The System Specification PaymentRequest ::= SEQUENCE { version Version, merchantIdentifier MerchantIdentifier IMPLICIT, merchantReference MerchantReference, totalPrice Price, currency Currency, contractHeading Text, detailRows DetailRows } Version ::= INTEGER MerchantIdentifier ::= INTEGER MerchantReference ::= OCTET STRING DetailRows ::= SET OF DetailRow DetailRow ::= SEQUENCE { itemName Text, itemPrice Price } Text ::= OCTET STRING Price ::= REAL Currency ::= ENUMERATED { fim (0), eur (1), usd (2), dem (3), ffr (4), gbp (5), sek (6) }
Table 4 – Payment Request
PaymentStatusRequest and PaymentStatusResponse The merchant queries the payment request status from the Mobile Payment System by using a PaymentStatusRequest. The response is sent as a PaymentStatusResponse.
40
4 The System Specification PaymentStatusRequest ::= SEQUENCE { merchantIdentifier [0] MerchantIdentifier OPTIONAL, merchantReference [1] MerchantReference } PaymentStatusResponse ::= SEQUENCE { merchantIdentifier MerchantIdentifier, merchantReference MerchantReference, statusCode StatusCode } StatusCode ::= ENUMERATED { notSet (0), new (1), authorizationPending (2), authorized (3), verified (4), committed (5) }
Table 5 – Payment Status Request and Response
AuthorizationVerificationRequest and AuthorizationVerificationResponse When the Mobile Payment System has received and authorization signature from the payer and it is verified to be valid, the system requests for verification for the payment from the Authorization System using a AuthorizationVerificationRequest. The response is an AuthorizationVerificationResponse.
AuthorizationVerificationRequest ::= SEQUENCE { merchantIdentifier [0] MerchantIdentifier OPTIONAL, merchantReference [1] MerchantReference, totalPrice Price, currency Currency, payerIdentifier PayerIdentifier } PayerIdentifier ::= CHOICE { certificate [0] X509Certificate, commonName [1] Name, uniqueId [2] UniqueIdentifier, payerId [3] INTEGER } AuthorizationVerificationResponse ::= ENUMERATED { ok (0), unknownPayer (1), overLimit (2), payerBlocked (3) }
Table 6 – Payment Authorization Verification Request and Response
41
4 The System Specification
PaymentCommitRequest The merchant requests the payment transaction to be committed using the PaymentCommitRequest. The response is a PaymentCommitResponse.
PaymentCommitRequest ::= SEQUENCE { merchantIdentifier [0] MerchantIdentifier OPTIONAL, merchantReference [1] MerchantReference } PaymentCommitResponse ::= ENUMERATED { ok (0), notAuthorized (1), notVerified (2), unableToCommit (3) }
Table 7 – Payment Commit Request
4.4
System Architecture
The Mobile Payment System is implemented using Java technology. The architecture follows a layered architectural style and the MVC (Model View Controller) design pattern [33]. This allows for good encapsulation of the business logic and good maintainability. The layered paradigm also enables the isolation of the application server, i.e. the server running the business logic, from the Internet. This means that access to the application server is only allowed from the web server that provides the presentation tier functionality. Authentication is performed on the controller. In this way, unauthorized users may never have access to the application server. The servlets acting as the controllers in the system manage the co-ordination of the transactions and the user interface functionality. The presentation logic is implemented in JSP pages that the servlets dispatch with the necessary arguments. The JSPs render the user interface – minimal amount of dynamic elements is embedded into the JSPs for a cleaner MVC model.
42
4 The System Specification
Client tier
HTTP Adaptation tier
Presentation and controller tier
Servlet Engine with SOAP Merchant Application (any platform)
Business logic tier
Java Virtual Machine
Data tier
Back-end tier
Database Management System
(SOAP) RPC Router Invoicing/Account Service
Java Virtual Machine
Servlet Engine
Merchant Application (java)
Merchant Server Java API
Merchant Passthru Servlet
PaymentServer
Payment Record Store Authorization Service
Mobile Client / WAP terminal
Payer Passthru Servlet
WAP Gateway
Payer LDAP System Scope Boundary
Denotes an entity (interface of component) implemented in the scope of the system
Figure 12 – The software architecture of the system
Business Logic Tier The PaymentServer plays the role of the model from the MVC design pattern. It extends the java.rmi.server.UnicastRemoteObject interface and runs therefore as an RMI server listening for and serving method calls from the payers and merchants. As the PaymentServer is implemented as a RMI server, an adaptive thread pooling mechanism is automatically in use. This allows for the scalable parallel processing of simultaneous requests. The PaymentServer binds to the RMI naming service, rmiregistry, from which the clients look up references to it. No transactional state is stored in the business logic tier. Consecutive requests are processed as atomic and unrelated tasks. The request processing logic and rules is coded into the PaymentServer and its supporting utility classes.
HTTP Adaptation Tier The HTTP adaptation tier turns the requests coming into the Mobile Payment System over HTTP to calls to the HTTP servlets implementing the controller role. The HTTP adaptation tier is in a way external to the Mobile Payment Server. It contains protocol
43
4 The System Specification conversion modules for transforming other protocols and technologies to HTTP suitable for the Internet. When a direct RMI connection cannot be made from a Java based merchant system to the Mobile Payment System, the Java remote client interface can be used to integrate the two systems. It tunnels the Java method calls over HTTP for easy firewall penetration. The WAP gateway transforms the WAP requests arriving over WSP to HTTP that is understood by the Mobile Payment System’s controller tier servlets. The WAP gateway contains no application specific logic. It is rather a transparent protocol converter between the WAP clients and the Mobile Payment System.
Presentation and Controller Tier The presentation and controller tier contains the user interface logic of the Mobile Payment System as well as the API for the merchant systems. In essence, it converts the requests arriving over HTTP to RMI calls to the Payment Server. As illustrated in the Figure 12, there are two alternative ways that the merchant system can use to interface to the Mobile Payment System. The two communication modes are offered to the merchant, so that Java based merchant systems have minimum requirements for integration while also non-Java based merchants can interface to the system. The tier consists of servlets and the RPC router that maps SOAP method calls to Java method calls. The PayerServlet implements the payer’s user interface. The PayerServlet plays the controller role of the MVC model. It dispatches JSP pages for rendering the WML user interface. The JSP pages play the view role of MVC model. The MerchantServlet adapts the serialized HTTP transport for the Payment Server. The RPC router of the SOAP does basically the same thing – it maps the SOAP messages to procedure calls and Java objects.
44
4 The System Specification Data tier The payment records are stored in the data tier Payment Record Store. The record store is physically a RDBMS. The database is accessed using JDBC from the business logic tier. The queries are written in SQL. The use of a persistent database provides transactional isolation and consistency – the business logic tier don’t need to manage the transactions; it only needs to take care of serving consecutive un-related requests. In this manner the scalability and performance issues are in a way propagated all the way to the data tier – it is the only single point of failure and real bottleneck in the system. All the other tiers scale up flexibly. For instance a network level load balancing solution can be used to distribute load between duplicated (or any number of) Presentation/Controller- and Business Logic tier ‘pipelines’ all of which use the same database. If the database performance becomes an issue in the set-up, an application level data tier distribution mechanism can be devised – e.g. all merchants beginning with letter A-M use one database instance and others use another. The LDAP directory is external to the Mobile Payment System. The mobile registration authority that issues the certificates for the payers manages it. It is possible that the signatures created in the WIM do not contain the certificate that identifies the signer but a URL referencing it in a directory [13][14]. This option has been specified by the WAP Forum partly to decrease the network traffic and partly to give the registration authority a business opportunity to get revenue from the directory queries that are necessary in order to validate the signatures with only links to the certificates. The directory is accessed from the business logic tier through JNDI over LDAP.
45
5 System Implementation and Testing
5 System Implementation and Testing This chapter describes in a low level of detail the implementation of the system described specified in the previous chapter. The testing process and a summary of the results is also presented as they are useful in analyzing the end result of the thesis work in chapter 6 Analysis .
5.1
The Environments, Platforms and Products
This section describes the tools, platforms and products used to implement the Mobile Payment System.
5.1.1 The Development Hardware and Software The development was carried out in Windows 2000 workstation environment, with the Oracle RDBMS running on a Sun Solaris platform. The tools used were Borland JBuilder 4 for Java development and TOAD version 7 for database modelling. The installation of the Mobile Payment System for testing and demonstration purposes was installed on a 700MHz Pentium III machine with 450 MB of RAM running Windows 2000 Professional with SP2. The same Oracle instance was used for both development and testing.
5.1.2 The Java Platform Java Platform, Enterprise Edition version 1.3 (namely SDK 1.3.1) was selected as the platform, since it was the latest final version that is also widely available on a number of server platforms. As the objective of the work was to build a robust server system, SDK 1.3 is well suited, as it provides good performance when run with the Java HotSpot Server VM that increases the performance by some 30% [9]. As the one of the goals of the work was to implement the system in such a manner, that it is compatible with different server platforms, the decision was made not to make use of an application server
46
5 System Implementation and Testing like BEA WebLogic or IBM WebSphere. This choice doesn’t reduce the reliability of the platform significantly as transactional coherence and consistency is handled by the centralised RDBMS. Thus even without a full-scale TP monitor a MTBF of 3 months and a MTTR of 1 hour [1] attainable with a tested and bug free system implementation. The apache.org Tomcat servlet engine was selected as the platform for the servlets. Tomcat is a non-commercial product, but still reliable and robust enough to serve the purpose. Furthermore, it is a standard servlet engine implementation. The implementation of the servlets in the system, doesn’t, however, in any way tie the system to the Tomcat. The servlets in the system are compatible with any standard servlet engine.
5.1.3 The RDBMS and JDBC drivers Oracle 8.1.5 (Oracle 8i) relational database management system was selected as the system database. The choice of the system database product was made between the inexpensive and lightweight mySQL and the robust but expensive Oracle. As the application logic itself runs on a non-reliable platform, that doesn’t provide proper transactional processing capabilities the database has to take care of it. The transaction processing in mySQL couldn’t be considered sufficient [4] which led to the choice of Oracle. The Oracle Thin JDBC drivers were used to make the database connection. The thin driver is a JDBC Type IV driver, which is a 100% Java library. It communicates over Java sockets with the Oracle server unlike the heavier Type II driver. The performance of the thin driver is generally considered as good or almost as good as the Type II OCI driver, which is sufficient also for this application. Furthermore with the thin driver no Oracle client installation on the server machine is necessary, which makes the deployment of the software easier. [17]
5.1.4 Cryptographic Modules As explained earlier, there are two alternative WAP gateway implementation approaches [14]. The WAP gateway can either treat the WAP SignedContent as transparent data or it may transform it to the PKCS #7 SignedData representation. The Mobile
47
5 System Implementation and Testing Payment System supports both formats. As the WAP SignedContent is a proprietary format, it is not directly supported in the Java security API. Neither could any commercial libraries be found that would support it. Thus it had to be implemented making use of the Java security API. The Java SDK doesn’t come with a PKCS #7 implementation either – only an internal, non-documented PKCS7 class exists for use with X.509 certificates and certificate revocation lists. The use of this class for other purposes is strongly discouraged by Sun. As commercial libraries for PKCS #7 are available, it wasn’t considered reasonable to implement one from scratch in the scope of this thesis. The Java Cryptography Extensions allow the easy use of cryptography libraries from different providers through a standard API. The library provider has to implement the library according to the Java Cryptography Architecture [18]. The major security technology providers like RSA and Baltimore Technologies all offer such libraries. Any of them would have been well suited for use in this system. However, the big commercial libraries are very expensive, and since in this case there is only a specific need for the PKCS #7 implementation, a more inexpensive choice would be more feasible. The IAIK (Institute for Applied Information Processing and Communication) of the Graz Univeristy of Technology has implemented a JCE library with support for most PKCSs. As the package has support for the complete PKCS#7 and its licensing price is reasonable, it was chosen as the cryptography library for the PKCS #7 signed data processing. In order to keep the systems internal and external interfaces as standard as possible a choice was also made to only use java.security.cert implementations of certificates and CRLs. This was to make the integration of the system with external systems easier; they are not required to have an installation of e.g. the IAIK package or other libraries not bundled in the Java SDK. Through this arrangement, internally in the system only the signature processing class need be aware of the non-Java SDK libraries.
5.1.5 The WAP Gateway and Terminals During the implementation phase of the system no WAP gateway was used. The Nokia Mobile Internet Toolkit 3.0 that has a built-in gateway simulator was used instead to
48
5 System Implementation and Testing perform module testing. For the functional testing the Nokia Activ Server 2.0.1 was chosen, as it had the necessary support for the WML Script signText encoding. During the system implementation the Nokia Mobile Internet Toolkit 3.0 was used as the WAP terminal emulator. The choice of the product was easy, since it was, at the time, the only commercially available tool with the necessary features and functionality. Functional tests were performed using the Ericsson T68 GSM terminal with a prototype WIM card from Gemplus. The tests were run over GSM circuit switched data as no added value for the tests could be gained through the use of GPRS as the WAP bearer. At the time the functional tests were performed, the Ericsson was the only major vendor supplying terminals with support for the WIM and WMLScript signText. Hence, other terminals than the T68 weren’t tested to confirm the compliance of the system.
5.2
Special Issues in the Implementation
This section presents the decisions made during the system implementation, that have bearing to the eventual system functionality. As usual, in some areas the scope of the system functionality had to restricted to the absolutely relevant features –it wasn’t e.g. feasible to implement all of the options proposed by some standards.
5.2.1 WAP SignedContent The core of the Mobile Payment System in terms of functionality and technical novelty is the support for WAP digital signatures. As explained earlier, a choice was made, to implement the processing logic for the WAP SignedContent directly based on the Java 2 SE classes.
49
5 System Implementation and Testing Only the most relevant options of the WAP SignedContent [14] were implemented. The X.9.62 elliptic curve signatures and X.9.68 certificates aren’t supported. The features supported by the implementation are listed in the Table 8.
Signature Algorithms
RSA/SHA according to PKCS #1
Signer Info Types
1) X.509v3 Certificate 2) RFC 2255 URL to X.509v3 Certificate
Content Types
1) data 2) text
Authenticated Attributes
1) GMT UTC time 2) signer nonce
Table 8 – Payment Authorization Verification Request and Response
5.2.2 The Directory Interface The WAP SignedContent signature has an option to include only references to the signer certificates. The reference in the signature is a URL pointing to a LDAP directory. In order to retrieve the signature a LDAP interface had to be implemented. JNDI (Java Naming and Directory Interface) was used to query the LDAP directories for user certificates. The parsing of the URL representation of the LDAP query presented in the RFC:s 2251-2255 [35][36][37][38][34] had to be implemented by hand, as it is not wholly supported by the JNDI.
5.2.3 Database Connection Pooling As the PayerServer is a multithreaded server application, optimizing the database connection use is a central performance issue – establishment of database connections on demand, e.g. at every request, is very resource consuming and may degrade the performance of the system significantly. Intelligent pooling of database connections was needed to ensure the ACID properties in the transaction processing. Oracle’s pooled Java data source and the Oracle connection cache implementation were used for this purpose. The cache was set in the dynamic mode and the upper limit for the number of
50
5 System Implementation and Testing concurrently active connections was made a parameter that the user of the system can set. In this manner the connection pooling and caching is transparent to the rest of the application code. During the testing phase of the system, it was noticed that the Oracle connection pool tends to get into an unrecoverable state when the individual JDBC connections in the pool time out. Special recovery mechanisms needed to be implemented in order to overcome this.
5.2.4 Implementing the MVC Design Pattern The MVC design pattern allows for a neat encapsulation and separation of application logic and user interface presentation logic. The model part of the design pattern was implemented as the RMI server. The server exposes its interface to the controller servlets. The servlets in turn dispatch JSP pages to render the user interface while controlling the user interaction and navigation flow. The JSP references are parameterized for the controller servlets and can thus be dynamically configured. This MVC implementation approach in J2EE is naturally only one of many. It is, however, a generally accepted one and allows for flexible application maintenance and customization with limited impact on the whole of the system.
5.3
Tests
The system was tested for both functionality and performance. The functional testing focused naturally on verifying the correctness of the system and that it is constructed according to specification. The goal of the performance testing was to verify the adequate throughput of the system and to identify the possible bottlenecks and inefficiencies of the system.
51
5 System Implementation and Testing
5.3.1 Functional Tests The purpose of the functional testing of the system was to gain certainty of the correct operation of the system. Thus the tests carried out focused on testing the system from the usage point of view. The criteria for functionality specified in section 3 Criteria for Design and Implementation were the basis of the functional testing. The functional testing environment is illustrated in the Figure 13. For the purposes of testing the functionality of the system, a web merchant service was set up. This was also done to serve the purpose of demonstrating the integration of the system with a real web merchant system. The merchant service was built by programming a couple of Java servlets that enabled the user to select some products to his shopping cart and request for payment. Once the user has done this, the merchant system submits the payment to the Mobile Payment System, the user authorizes the payment using his WAP terminal. After authorization the user indicates the merchant system the payment is authorized and the merchant system commits the payment.
The Merchant Server
A workstation running a web browser and a WAP terminal emulator
The Corporate Intranet
The Oracle 8i Server
Mobile Payment System
Figure 13 – The Functional Testing Environment
The Test Cases and the Results Below, the test cases for the functional tests are described. The descriptions are only superficial – the tests are explained more concretely in the test results. Each of the below three cases yields several actual cases as different input values and set-ups are
52
5 System Implementation and Testing tested. The tests and the results are summarized in the tables below each of the test cases.
Case #1: Create a payment request. The merchant system should be able to create a payment request with all relevant details about the payment, as described in 4.3.4.
Test Submit a properly formatted payment request. Submit a payment request with an identifier that already exists in the payment record store. Submit a payment request with missing data. Submit a payment in which the total of the line items does not match the total of the payment.
Result The payment request is accepted. Payment request is rejected. The system reports a duplicate payment identifier. If any critical data or combination there of is missing, the request is rejected The payment request is rejected. The system reports a bad payment request.
Case #2: Authorize the payment The payer should be able to connect to the Mobile Payment System to perform the payment authorization. The Mobile Payment System should accept a correctly formatted signature and validate it.
Test Submit a proper signature Submit a random data as signature Submit a signature that is made on content that is not the original payment contract Submit a proper signature. (the payer’s certificate is removed from the trusted domain) Submit a signature with a link to the LDAP directory, from which the payer’s
Result The authorization is accepted The authorization is rejected. The system reports that the signature is not ok, the certificate is not ok and the content is not ok The authorization is rejected. The system reports that the content is not ok. The authorization is rejected. The system reports that the certificate is not ok. The authorization is accepted.
53
5 System Implementation and Testing certificate should be retrieved. Submit a signature with a non-working link to the LDAP directory. Submit a proper signature. (the payer’s certificate is added to the CRL) Submit a signature for a payment id that does not exist in the payment record store. Submit a proper signature after the system has been idle for 24 hours.
The authorization is rejected. The system reports that the certificate is not ok. The authorization is rejected. The system reports that the certificate is not ok. The authorization is rejected. The system reports that payment record was not found. The authorization is accepted.
Case #3: Commit the payment Only as the payer authorizes the payment transaction, the merchant should be able to commit the transaction. Committing the transaction should result in the registration of the payment transaction into the invoicing or account management system.
Test Commit a payment that been properly authorized Commit a payment that has not been authorized
Result The payment is committed successfully The payment is not committed. The Mobile Payment System reports an illegal payment state.
5.3.2 Performance Tests Performance tests were run on the system to form a picture of the throughput that can be achieved. The ultimate goal is to have a measure of the throughput of the system on a specific hardware platform. Having this kind of measures is helpful when planning the deployment of the system to production use. The performance tests were automated. A proper and adjustable load of concurrent transactions cannot be generated manually. As it was not possible to have a test set-up where actual WAP devices generate the transactions automatically into the Mobile Payment System, the WAP end was eliminated from the chain. The tests were run using a custom made HTTP-client to generate requests into the system. To be precise the test
54
5 System Implementation and Testing client simulated the WAP gateway’s function. Eliminating the WAP terminal and the WAP gateway do not compromise the accuracy of the tests – the goal is to test the throughput of the Mobile Payment System, not the WAP terminal’s nor the WAP gateway’s. Furthermore no actual credit verifications or registrations of transactions into an invoicing system were made in the tests. These steps were eliminated, so that only the performance of the Mobile Payment System core could be tested. The tests could of course be repeated with those interfaces in place – then a proper view of the overall performance observed by the users of the system in live installation could be reached. In this case that is, however, not the goal. The test set-up is illustrated in the Figure 14. In a production environment, the servlet engine would run on a different machine than the PayerServer for a better isolation of the business logic tier from the public Internet. In this way the server load would be distributed across two servers instead of having one server run both the servlets and JSPs and the server. The tests will, as a result of the arrangement illustrated in the figure, exhibit a lower performance than that of a typical production environment. This doesn’t, however, impair the results of the tests significantly. The actual performance will only be a bit better than that measured in the tests.
The Corporate Intranet
The Oracle 8i Server
The load generating test client
Mobile Payment System
Figure 14 – The Performance Testing Environment
As the purpose of the tests was to form an understanding of the system’s performance and help in determining the scalability, the number of concurrent users or transactions
55
5 System Implementation and Testing was set as a variable. Respectively, the number of test rounds was adjusted per test case in order to achieve an acceptable relative error. Tests were run with 1, 2, 5, 10, 20, 30, 40 and 50 consecutive clients generating requests to the system. The maximum number of concurrent clients of 50 was chosen to represent a worst-case scenario with a 100 000 daily users, assuming a pessimistically uneven usage distribution for the day. Each of the test clients ran in a loop a set number of times making two requests to the system on each round. The first request was to retrieve the payment contract for signing and the second to submit the signature verification. The response time of the system was measured and reported separately for each request. Statistical analysis was performed on the test results to determine their goodness. If a confidence interval of 95 percent could not be reached with the initially chosen sample the sample population was increased. The Student’s T distribution [39] was used to evaluate the realization of the confidence interval, as the population variance and distribution were unknown. The preliminary results showed that the distribution was not skewed. Based on the central limit theorem, for a large number of samples the sample distribution mean is a normal distribution with the mean equal to the population mean and the standard deviation equal to the population standard deviation divided by the square root of the sample size. [39] The central limit theorem allows making inferences on the mean of any distribution when the sample size is adequately high. The Table 9 illustrates how the variables and final sample sizes were chosen for the tests.
Test 1 2 3 4 5 6 7 8
Number of consecutive clients 1 2 5 10 20 30 40 50
Number of rounds /client 1000 1000 1000 1000 100 100 100 100
Resulting sample population 1000 2000 5000 10000 2000 3000 4000 5000
Table 9 – The variable selections for the tests
56
5 System Implementation and Testing A summary of the test results is shown in Table 10.
Test 1 2 3 4 5 6 7 8
Mean response time ms 276 297 404 564 1077 1544 1988 2613
Standard Deviation ms 54 60 91 144 262 332 362 616
Relative Error 1.2 % 0.9 % 0.6 % 0.5 % 1.1 % 0.8 % 0.6 % 0.7 %
Throughput Requests / s 3.6 6.7 12.4 17.7 18.6 19.4 20.1 19.1
Table 10 – A summary of the test results
In addition to the pragmatic performance tests some tests were performed to form an idea of the proper configuration of the system and the possible performance bottlenecks. These tests were not scrutinized with the statistical methods described above and should only be considered as referential. Below some remarks and observations are presented.
Remarks about the performance tests During the performance tests, the operating system performance monitor was observed. The general observation was made, that with a low number of simultaneous clients the load on the server system CPU was low. With one concurrent client the load stayed steadily at about 15 %, with 5 clients the load increased to about 65 % and with 10 or more clients a constant load of over 90 % was generated. Tests on database connection pools of different sizes were also made. With 50 simultaneous clients, when the database connection pool size was not constrained at all, it became clear, that the system could only make use at maxim about 25 connections at a time. The average number of simultaneously used connections was closer to 10. On the other hand it was noted, that when the database pool size was constrained to 5 connections with 10 concurrent clients the system load dropped from about (90 % of the unconstrained case) to 35 %.
57
5 System Implementation and Testing
Impact of the database access on the overall response times A hypothesis was made that the database accesses cause most of the latency in the responses. For testing purposes a database interface class, that keeps the payment record store in memory, was implemented. Tests with that system were run only with one simultaneous client. The results showed, that the mean response time was 40 ms, which is a dramatic improved on the response time of 276 ms achieved with a proper database implementation. With the memory resident implementation of the payment record store the CPU load reached 100 % during the test run. In other words, most of the time it takes to process one request, is spent waiting for database responses.
58
6 Analysis and Discussion
6 Analysis and Discussion This chapter discusses the solution created in this thesis work. The results are analysed in view of the goals set for the work in section 3 - Criteria. Some of the major limitations and strengths of the solution are also discussed.
6.1
Meeting the Goals
In this section, the results of the thesis are compared to the goals set in chapter 3 Criteria for Design and Implementation. The possible discrepancies are analyzed and scrutinized. In whole, the results are reflected upon and the work is evaluated.
6.1.1 Functional This section analyses the fulfillment of the functional criteria, listed in section 3.1, based on the results of the functional tests. All the functional criteria weren’t addressed in the tests, so their fulfillment is simply explained based on the system architecture, design and implementation. The below numbering reflects that used in listing the functional criteria in section 3.1. 1. The system is based on a digital signature based authorization of payments. The management of the monetary processes is external to the system. 2. The system supports the interaction of the payer, issuer and the merchant. The payer uses his WAP terminal to authorize payments and the merchant has two inter-faces he can choose from. The issuer is interfaced in two ways – the creditability is verified through the authorization interface and the directory containing the payer certificates is interfaced over LDAP. 3. One of the core use cases implemented by the system is the merchant’s registering of new payment requests. 4. The system manages the payments in a RDBMS. The payment status is one of the key attributes of a payment.
59
6 Analysis and Discussion 5. The merchant’s interface provides the status query as one of the services. 6. The merchant’s interface provides committing a payment as one of the services. 7. The invoicing system interface is used by the Mobile Payment System to register the committed payment to an external system. 8. The payer’s WAP user interface enables the retrieval of the payment contract for authorization. Once the payer has created and submitted the authorizing signature, the authorization is verified and ready for committal by the merchant. 9. The system verifies the signatures. 10. The system verifies the validity of the certificate associated with the signature. Optionally also the certificate revocation lists are checked to validate the certificate. 11. When there is a URL pointing to the certificate rather than the actual certificate in the signature, the Mobile Payment System fetches the certificate from the specified URL. 12. The authorization interface is used by the Mobile Payment System to verify the payers credit status from an external system. As obvious, all the functional criteria were met. What comes to the level or goodness of fulfillment, it can be said, that the all the criteria except the ones having to do with the external interfaces for invoicing and credit verification and the signature verification were met fully. The invoicing and credit verification interfaces exist in the system, even though they weren’t implemented to interact with any existing system in the scope of this thesis. The signature verification also comes with some reservations – the currently supported flavours of WIM-signatures are supported fully. Elliptic curve algorithms aren’t supported, although they are specified by WAP forum as part of the standard. As a whole, the functional requirements were met well – no actual deviations from the requirements were made except when it wouldn’t have been reasonable or practical to comply or to try and achieve a perfect solution.
60
6 Analysis and Discussion
6.1.2 Technical The technical requirements, that were set in section 3.2 for the system implementation were met fully. Below, an explanation of how each of the requirements was fulfilled is presented. 1. The system was developed using JDK 1.3.1. The test equipment had JDK version 1.3.0 installed in them. The system was run and tested on both platforms without faults. Both of these JDK versions are on Java 2 level – the first Java 2 version was JDK 1.2. 2. Oracle was used as the sole system database. The precise version of Oracle used during development and testing was 8.1.5, which is already Oracle 8i. 3. The approach to supporting merchant systems taken in the work was to support a generic interfacing technology towards the merchant systems. In order to reach a wide enough audience of merchant systems two interfacing technologies were supported – SOAP and pure HTTP with proprietary message formats. Java based systems may use the proprietary HTTP based interface together with the client side Java API. The rest of the merchant systems will have to use SOAP interface. On most platforms there is a SOAP client implementation available – for those that don’t have it, one can be quite easily implemented. 4. The system is based completely on the WAP 1.2.1 level specifications. Most importantly the WMLCrypto API specification is [14] followed closely, as described earlier in the paper.
6.1.3 Security The security requirements, which were set in section 3.3 for the system implementation were met fully. Verification of the absolute fulfillment of all of the security requirements is difficult, if not impossible. Meeting the criteria is analyzed here by discussing the decisions taken and the ways in which the security threats were mitigated. Below, this discussion is presented for each of the three core security requirements.
61
6 Analysis and Discussion 1. The requirement of preventing unauthorized entities accessing the system and its data is satisfied in two levels – the architectural design and the implementation level. The system architecture is designed so, that it is possible to isolate the system effectively from the public network by protecting it with firewalls with proper port, protocol and address filtering configurations. In the implementation level generally accepted secure protocols and authentication and access control mechanisms have been utilized to meet the requirement. The authentication mechanism for merchant systems, is based on TLS based encryption and authentication that is transparent to the application. This provides a high level of security, providing the key management and distribution is performed in a proper way. Discussion of the key management policies is considered to be outside the scope of this paper. 2. The above-described mechanisms largely address also the second security criteria of only allowing access to the system resources through the specific interfaces. The system architecture is designed so, that the all access to the system data and services passes through all of the architecture layers. Only services exposed in the higher tiers allow access to the lower level service set, i.e. when there is no service on the higher tiers of the architecture, there is no way of accessing the corresponding lower level services. 3. There are two paths of communication towards the Mobile Payment System – the one originating from merchant systems and the one from the WAP device. As said, the first is secured by TLS based encryption. For the second path there are actually two consecutive communication links where different encryption schemes may apply – the link from the WAP terminal to the WAP gateway and the one from the WAP gateway to the Mobile Payment System. The first link is protected using the WTLS class 1 or 2 security protocol. The use of the protocol is transparent to the application and in practice its function is just to provide a secure, encrypted data link. The second link, i.e. from the WAP gateway to the server could be encrypted using TLS. However, a decision was made not to do this. This doesn’t pose a security threat, as the WAP gateway is assumed to be in a secure domain and the communication over this link doesn’t pass over a public network.
62
6 Analysis and Discussion In the eventual production deployment of the system the communication between the Mobile Payment System and the LDAP directory, from which the payer certificates are fetched, may be protected by an SSL based encryption scheme. At the time the system was implemented and tested the LDAP communication took place in clear against the specifically defined security criteria. The encryption will, however be transparent to the system - applying encryption to the link will have none or little impact on the system. In addition to the above directly specified security requirements, there is of course the implied security criterion for the public key infrastructure that the solution is based on. In this thesis the security provided by the MeT based mobile transactions framework was taken as a given – the assumption was made that the key management, certificate issuance and signing processes are inherently secure. Naturally, if any of them were compromised, the basis from the system’s overall security framework would collapse.
6.1.4 Scalability Scalability is one of the most important factors in a system where the numbers of users and the frequency of the usage cannot be determined and fixed beforehand. The approach into evaluating the scalability of the implementation taken was to evaluate two factors: 1. the behavior of the average response time of the system as a function of the number of simultaneous clients 2. the behavior of the through-put of the system as a function of the number of simultaneous clients Based on the test results illustrated in Table 10 the graphs in Figure 15 and Figure 16 were drawn.
63
6 Analysis and Discussion Correlation between response time and load
Average response time (ms)
3000 2500 2000 1500 1000 500 0 0
10
20
30
40
50
Simultaneous clients
Figure 15 – The performance test results – response times On the relevant spectrum of 1 to 50 simultaneous clients the system seems to exhibit a linearly growing average response time. The slope of the curve is starting to steepen between 40 and 50 simultaneous users. This is, however, quite natural – every system reaches the level of load where the performance observed by a single user starts to degrade dramatically. For this system this point seems to be somewhere above but near 50 constant simultaneous users.
Throughput of the Mobile Payment System 25,0
Requests/Second
20,0 15,0 10,0 5,0 0,0 0
10
20
30
40
50
Sim ultaneous clients
Figure 16 – The performance test results – throughput The system throughput exhibits a very scalable behavior – the throughput increases rapidly up to 10 simultaneous users and keeps increasing up-to 40. At fifty simultaneous
64
6 Analysis and Discussion users the system has already reached the saturation point and the throughput is already on the decline. Obviously this behavioristic observation is in line with the one made earlier – the system starts getting jammed at somewhere a bit above 50 simultaneous users. Up to that point the response time growth experienced by a single user is reasonable and linear as a function of load. As a whole, the system fulfils the requirements set for a reasonable scalability. In the tested spectrum of load the system scales well. The system will flexibly support up to 864 000 transactions per day1 on the hardware that was used for the tests. This by far exceeds the 100 000 daily users set as the design criteria.
6.1.5 Performance The performance of the system is experienced by each individual user – it will be an important factor for the overall usability of the system. Based on the test results used for determining the scalability the performance of the system can be analyzed. There are two factors that should be observed for determining on the measure of performance: firstly the individual response time and the maximum throughput of the system. Assuming a level of 10 to 30 simultaneous users as the normal load the system the design criterion of an average response time of 1 to 2 seconds can easily be achieved. This is the response time that a mobile user can expect to experience at best. Of course the network latency will further increase the response time but this has to be just accepted. The minimum individual response time that could be achieved given the hardware and networking architecture that was used in the tests was some 500 ms. This is probably quite near to the optimum, given that the transactions each time involve a number of database queries, insertions and updates. The maximum throughput of the system achieved in the tests was 20.1 requests per second at the mean response time of 1990 ms. As can be seen in Table 10 this throughput was naturally achieved when there were constantly 40 simultaneous users. This level of throughput can be considered as adequate in terms of the criteria set for the system.
65
6 Analysis and Discussion As a whole the performance of the system is good. The performance is almost surprisingly good given the complexity of each individual transaction and the fact that the system is based on a pure Java platform.
6.1.6 Modularity According to the current understanding, the system is structured in a very modular way. However, it is impossible to conclusively prove this. Evidence for this can of course be produced. In this section, some of the ways and instances in which the principles were applied practically are discussed. The criteria cover three different aspects that were aspired for in the work. Firstly the system design should be such that it can be extended easily. Secondly the system’s modular design should provide for easy maintenance. Lastly the modular design should give the possibility to use pre-made or external libraries and other systems to complement the functionality. All of the above aspects were used as the cornerstones of the system design. On a high level, the overall architecture of the system is based on a layered design paradigm – the business logic is separated from the user interface logic which further more is separated from the visual layouts and data presentations. This provides for a highly modular structure and readily maintainable solution. The business logic tier of the system is implemented using a module-based approach. The core server only contains a minimal amount of the program logic. The rest of the logic is encapsulated in classes that can self sufficiently perform the tasks intended for them. Furthermore, the classes that may be exchanged are not bound in programs. E.g. the database access class, authorization class, invoicing system class and the payment contract formatting classes all implement clearly defined interfaces. The interface implementation classes are defined in the system configuration – the actual implementation of each of these interfaces is thus only fixed at the runtime. This gives the possibil-
1
Roughly estimated from the formula: 20 transactions/second* 12 hours/day * 60 minutes/hour * 60 seconds/minute = 864 000 transactions/day
66
6 Analysis and Discussion ity to make new implementations of the interfaces and attach them to the system without the need to touch the rest of the system. Some parts of the system, like the ones that have to do with certificate and signature verification have been isolated from the rest of the system. They are made generic and can thus be used and developed independently of the rest of the system given that the interface is respected. This kind of approach yields for reusable pieces of software that may be used across projects regardless of the specific application area.
6.1.7 Maintainability The maintainability of the system has two dimensions – firstly the day-to-day of maintenance and administration of the system and secondly the maintainability of the programs, i.e. how easily they can be changed, fixed or updated. In terms of the first kind of maintenance, the system administration, the system is verifiably ‘low maintenance’. After the system is started, there aren’t be many occasions when manual intervention is called for. Most of the system administration tasks, like adding new merchants, trusted root certificates etc. may be done on the fly using the standard tools. Only when the configuration of the system changes the system process needs to be restarted. Automatic recovery mechanisms from e.g. database, LDAP and naming service failures have been built in. Furthermore the system records all occurring access into a file-based log to make problem solving easier. There is no exact measure for the latter type of maintainability of the system – it is truly measured only when changes to the system are made. The issue of maintainability was tackled in the design and implementation phases of the work. The design was kept very modular – change needs will in most cases be limited to just certain modules or classes. Most of the central classes of the system can be substituted without need of touching anything else than the text based configuration files. Nothing that was considered dynamic is hard coded into the programs. The dynamic run-time class instantiation mechanisms was used for all of the customizable interfaces – the names of the interface implement is given as parameters in the configuration files. This effectively limits a large portion of the changes to the boundary part of the system leaving the core unaffected.
67
6 Analysis and Discussion
6.2
Maturity of the Solution and the Technology
The solution for securing mobile payments reached in the work is as such mature. It makes use of the industry standard technology for wireless PKI and in it the generally agreed models have been adopted. For a payment system the functionality of the system is, however, quite limited. It lacks some of the features and functionalities of other similar systems presented earlier in this paper. On the other hand the system has some functionality not yet on the market in the other solution suites. The maturity of the system should thus be evaluated in two levels: 1. the maturity of the core of the system, the model adopted and technology used as the basis of the implementation 2. the maturity of the system as a whole and as a mobile payment system among other mobile payment systems On the first level of evaluation the system scores high marks. The system core is implemented using a viable technology and latest innovations have been used. In the core only a minimal set of functionality is fixed – the system is very dynamic and configurable – interface modules can be exchanged without the need of recompilation and parameters are defined in the configuration files. The way the system makes use of the WPKI is in itself novel and even innovative. The technology that is the basis of the system, i.e. the WIM and WMLScript signText are just emerging onto the market so their evolution is only beginning. Clearly there is a lot of room for improvement in the first releases of the handsets having the functionality. Still, a usable solution can already be constructed on top of what there is. On the second level the system is in some respects lacking in functionality – many of the features, like account management and administration tools that are available in commercial packages are missing from the Mobile Payment System. In this sense the system can be seen as quite immature and in need of further development. On the other hand the system is built on an extensible architecture concept – parts can be added and replaced without impact to the rest of the system. This can be seen a high level of ma-
68
6 Analysis and Discussion turity – in many cases there is, in any case, a need for customizations – the system concepts lends itself to that readily. The viability of the system as a solution for mobile payments cannot easily be estimated. It may well be that even if the solution is mature in a lot of senses, the market isn’t – the concepts of mobile payment will probably take a while to be adopted by the large audiences on the consumer market.
69
7 Further Development Needs
7 Further Development Needs The scope that was chosen for the Mobile Payment System in this thesis is limited to essential features and functionality that were considered necessary for providing the basic level of secure payment service. Thus there are a number of features and functionalities that were left out of the first version of the system. This chapter discusses the central areas of the system that should and could be developed further.
7.1
The system data model and actors
Currently the system is built around the concept of a merchant that is practically an entry in one of the system’s database tables. The users aren’t registered – the PKI model, where a third party registration authority has performed the certification has been adopted and embraced consciously. In order to provide a better and friendlier user experience it would, however, be beneficial to have some information about the users available to the system – a concept of a registered user or a user data interface should be adopted. If users were registered into the system a user account concept could also be introduced. To make the account management and registration implementation simple and straight forward the payer and merchant could in the new data model be just roles for the registered entity in the system. This would enable a lot of new desirable functionalities, like peer–to–peer payments.
7.2
Administration tools
The current version of the system doesn’t include any administrative interfaces for the merchants, payers or payment system operators. These functionalities could easily be implemented in order to provide better transparency into the system and to make the day-to-day maintenance and management tasks easier. A web based administration console where the registration information and the transaction history could be viewed and edited would probably be best suited for the purposes of the merchants and registered
70
7 Further Development Needs payers. The payment system operator’s administration console could either be a web based one or a Java based client application.
7.3
Payment initiation by WAP PUSH
The system should be integrated towards a WAP Push Proxy Gateway, like e.g. the Nokia Activ Alert. This would enable sending Service Indication WAP PUSH messages to authenticated payers to initiate the payment process. This would remove the payment reference code entry phase from the payment use case and thus make it considerably faster and easier. It will certainly make sense to integrate the push functionality into the payment server rather than leave making it to the merchants.
7.4
Interfaces
For quicker and easier integration, the system could come with some pre-made interfaces towards the most common billing and account management systems. The relevant systems are, however, hard to decide – probably the most feasible scenario will be to implement the interface on demand and after that bundle them with the complete product. In the interface development a lot of effort needs to be focused on providing a transactionally secure result. Managing the transactions and interaction between systems so, that the possible failure in one system doesn’t compromise the consistency of the other is a central issue. A two-phase commit scheme would also be very useful when more than two parties interact in the transaction (i.e. the merchant, the payment system and the invoicing system). This may however not be technically feasible in most cases. In case an external payer information management scheme is adopted (instead of changing the internal data model) a generic LDAP interface towards a user directory will probably need to be implemented.
71
7 Further Development Needs
7.5
WAP Signed Content
Currently the implementation of the WAP SignedContent is limited to the most common algorithms. In the future at least the ECDSA will need to be supported. Furthermore, as it seems that the WAP gateways will not start performing the translation from WAP Signed Content to the PKCS #7 Signed Data, this translation should be performed in the Mobile Payment System. This will enable for non WAP-aware merchant systems to make the signature verifications in case they don’t decide to trust the Mobile Payment System operator. Also dispute resolution would become easier, as the PKCS #7 Signed Data is a universally recognized signature format.
72
8 Conclusions
8 Conclusions The business to consumer markets of tangible and intangible goods on the Internet haven’t so far met the great expectations set for them. This is mainly due to the fact that there haven’t been established and secure on-line payment methods that would be readily accessible for everybody. This generates a strong demand for electronic payment systems that would satisfy the security, availability and usability needs. In general the only way to properly carry out authentication and authorization in the digital medias is through the use of public key cryptography. In order to make use of public key cryptosystems in a large scale is through setting up a public key infrastructure. There are a number of problems associated with doing this – many PKI deployments have stumbled on the obstacles, the smallest of them not being the usability and user friendliness aspects – the systems should be easy to use and available regardless of time, place and whether you are doing business over the counter at a supermarket or on the Internet. The electronic payment systems are based on roughly four types of paradigms: electronic cash, electronic checks or account transfers, credit cards or micropayments. In general, all of the above except for maybe electronic cash have up to now been lacking standard strong authentication mechanisms that could at the same time address the needs of all user groups. Proprietary mechanisms have been proposed and deployed where e.g. on a SIM Application Toolkit or server side wallet based solution PKI capabilities have been implemented. However, there are many shortcomings in most of these mechanisms either on functional, technical, security, usability or cost of use domains. Industry organizations, the WAP Forum and the MeT Initiative, have specified a generic wireless public key infrastructure, with the goal of enabling secure mobile transactions based on a standard PKI framework. As a result of this work, there will soon be PKI capabilities in all mobile phones – people can authenticate themselves and furthermore authorize transactions by creating digital signatures using a handset and the associated wireless identity module. This creates the possibility of developing payment systems on top of this standards based infrastructure that are readily accessible, inexpensive and provide a consistent user experience.
73
8 Conclusions The goal in this thesis was to implement an electronic payment system where the MeT WPKI framework is utilized for the authorization of payment transactions. The goal was not to implement the complete payment system but to provide the necessary interfaces towards the central functions, like balance and credit management, provided by a traditional account based system. The key task of the system is to co-ordinate the payment transactions between the actors in the scenario – the merchant, the payer and the issuer. The environment in which the system is intended to operate calls for a highly modular, high performance and scalable implementation – these criteria were to be emphasized in the design and implementation. The system architecture for the Mobile Payment System is engineered according to a layered design paradigm – this approach was taken to fulfill the criteria set for security, modularity, maintainability and scalability. The application architecture is built on top of the Java 2 Enterprise Edition framework. The interfaces towards the external actors the merchant and the payer are provided over HTTP. SOAP was used to accommodate different types of merchant system platforms. The MVC design pattern is applied in the design – the business and the database access logic are encapsulated in the Java RMI server which acts as the model, servlets coordinate the user interaction in the controller role and JSPs are used to render the user interface layouts. A relational database is used as the persistent data store. The tests run against the system illustrate that it meets the functional requirements set in for it. The performance and scalability of the system even exceed that set as criteria. Even if meeting the security, maintainability and modularity criteria is hard or impossible to measure in a conclusive manner, based on the current understanding, the system is considered to fulfill the set requirements fully. In some areas, the implementation had to be limited to a minimal set of features since it wouldn’t have been feasible or meaningful to cover all of the possible options in the scope of the thesis. The system is one of the first efforts to harness the MeT WPKI framework for enabling secure authorization of mobile payment transactions. There is naturally a lot of room for improvements in the system, both in terms of functionality and technology. The key areas where the needs for further development are the biggest are the system data model and the administrative tools. In order to make the system more flexible and easier to join as a merchant and user the data model should be adapted to abandon the merchant –
74
8 Conclusions payer role paradigm and create a single member concept. The member could act in both merchant and payer roles, which would enable peer-to-peer payments, which for now haven’t even been possible in many systems. The administrative tools would make the day-to-day administration of the system easier – the possible problem issues and configuration changes could be made easier and the system downtime could be reduced as a result. The mobile payment scene is a fast evolving one. There are a number of market drivers that are forcing the rethinking of the current payment methods; changes in legislation, the growth of on-line commerce and the increase in on-line frauds, just to name a few. In the years to come many new attempts to offer a secure payment infrastructure will emerge. The solution presented in this paper is certainly one that works and fulfills many of the generic criteria for a ‘winner’ in the market. However, the technology that the system is based on is only in its first generation – the WAP 1.2.1 capable handsets and WIM cards, not to mention the PKI needed to accommodate the applications are just emerging. It will always take a while before the attitudes and habits of large audiences of consumers change and become ready for new kind of technical solutions in the daily lives.
75
References
References [1] Anon., Established players gain most out of mobile Internet, Mobile Internet, 2000, Vol. 2, No. 2 [2] Chorafas, D., Transaction Management, Managing Complex Transactions and Sharing Distributed Databases, MacMillan Press Ltd., Great Britain, 1998, 305 pages [3] Durlacher Research Ltd., Mobile Commerce Report, November 1999 [4] IAIK, jce toolkit, 2001, [referenced 2 September 2001] [5] ITU-T, AUTHENTICATION FRAMEWORK, Recommendation X.509, June 1997 [6] MySQL AB, MySQL Manual, 2001, 766 pages, [referenced 5 September 2001] [7] O’Mahony, D. & Peirce, M.& Tewari, H., Electronic Payment Systems for ECommerce, Artech House, United States, 1997, 254 pages [8] RSA Laboratories, PKCS #15 v.1.1: Cryptographic Token Information Syntax Standard, 6 June 2000 [referenced 5 September 2001] [9] RSA Laboratories, Technical Note: PKCS #7: Cryptographic Message Syntax Standard, 1 November 1993 [referenced 5 September 2001] [10] Sun Microsystems, Inc., Java HotSpot Technology, 9 August 2001, [referenced 4 September 2001] [11] Wireless Application Forum, Ltd., Wireless Application Protocol - Identity Module Specification, 18 February 2000 [12] Wireless Application Forum, Ltd., Wireless Application Protocol - Wireless Transport Layer Security Specification, 18 February 2000 [13] Wireless Application Forum, Ltd., Wireless Application Protocol - Public Key Infrastructure Definition, 3 March 2000 [14] Wireless Application Forum, Ltd., WMLScript Crypto Library, 5 November 1999 [15] Wireless Application Forum, Ltd., WAP TLS Profile and Tunneling Specification, 24 April 2001
76
References [16] Wireless Application Forum, Ltd., WAP Certificate and CRL Profiles, 22 May 2001 [17] Wireless Application Forum, Ltd., WAP Forum Releases, 2001, , [referenced 9 September 2001] [18] Oracle Corporation, Ltd., Oracle8i JDBC Developer's Guide and Reference, Release 8.1.5, [referenced 5 September 2001] [19] Sun Microsystems, Inc., Java Cryptography Architecture, 15 August 2001, [referenced 5 September 2001] [20] Gladman, B. & Ellison, C. & Bohm, N., Digital Signatures, Certificates and Electronic Commerce, 8 June 1999, , [referenced 8 September 2001] [21] Schneier, B., Applied Cryptography, 2nd edition, John Wiley & Sons, Inc. United States, 758 pages [22] Diffie, W. & Hellmann, M.E., New Directions in Cryptography, IEEE Transactions on Information Theory, Volume IT-22, Number 6, November 1976 [23] Puhakainen, P., Electronic Commerce: Market Estimates and Security Considerations, Licentiate’s thesis, Helsinki University of Technology, 2000, 121 pages [24] National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards, Publication 180-1, 17 April 1995, [referenced 10 September 2001] [25] Halsall, F., Data Communications, Computer Networks and Open Systems, Fourth Edition, Addison-Wesley, United Kingdom, 1996, 905 pages [26] EMVCo, LLC, EMV ’96, Chip Electronic Commerce Specification, December 1999, [referenced 11 September 2001] [27] SET Secure Electronic Transaction LLC, SET Secure Electronic Transaction Specification, Book 1: Business Description, version 1.0, May 1997 [referenced 7 December 2001] [28] MeT Initiative, Mobile Electronic Transactions [referenced 15 September 2001]
Initiative,
[29] EHPT Sweden Ab., Easy Steps Jalda for Java Applications, release 1.4, 14 May 2001, , [referenced 19 September 2001] [30] EHPT Sweden Ab., EHPT SafeTrader, Product Description, release 1.4 2000, , [referenced 7 December 2001]
77
References [31] Ericsson Corp., Mobile e-Commerce, Mobile e-Pay 2.0 technical description, 2000 [32] Nokia Corporation, Nokia Payment Solution Data Sheet, [referenced 4 September 2001] [33] Gamma, E. & Helm, R. & Johnson, R. & Vlissides, J., Design Patterns, 1995, 1st edition, United States, Addison-Wesley, 395 pages [34] Howes, T. & Smith, M., RFC 2255, The LDAP URL Format, December 1997 [35] Wahl, M. & Kille, S. & Howes, T., RFC 2251, Lightweight Directory Protocol (v3), December 1997 [36] Wahl, M. & Kille, S. & Howes, T., RFC 2252, Lightweight Directory Protocol (v3): Attribute Syntax Definitions, December 1997 [37] Wahl, M. & Kille, S. & Howes, T., RFC 2253, Lightweight Directory Protocol (v3): UTF-8 String Representation of Distinguished Names, December 1997 [38] Howes, T., RFC 2254, The String Representation of LDAP Search Filters, December 1997 [39] Milton, J. & Arnold, J., Introduction to probability and statistics: principles and applications for engineering and the computer sciences, 1995, Third edition, New York, USA. McGraw-Hill International editions
78
