Chapter 1

Introduction
The notion of electronic payments is certainly not a new one. This area has been extensively studied and it dates back as far as the early nineteen eighties when David Chaum rst presented the concept of using blind digital signatures for implementing untraceable electronic payments (see Chaum, 1983). It is continuing to receive signicant industry attention as the number and the sophistication of online threats increases. With substantial amount of money at stake and with prot margins at risk the industry leaders (e.g. Visa and MasterCard) are committing capital and devoting time towards addressing security issues with electronic payments.

Electronic payments is a term that encapsulates a number of technologies and approaches.

It

includes digital tokens that try to replicate the features of physical cash such as anonymity and notational systems that represent money in a more traditional way such as funds deposited in an account. Regardless of the approach chosen, the three main areas of interest have traditionally been anonymity of transaction participants (mainly the customer), the double spending of digital coins and the security of the underlying currency representation, be it digital coins or accounts. Based on the current approach adopted by both Visa and MasterCard (see section 3.4) it is safe to say that this focus has not changed. With the rise of the Internet and the growing popularity of electronic payments a new payment model has emerged. Due to the ever-increasing demand for subscription-based services, direct debit payments have quickly become a preferred method of payment with both consumers and merchants. This growth in direct debit payments is most evident in annual reports published by the Reserve Bank of Australia (RBA, 2005) and Australian Payments Clearing Association (APCA, 2005). More importantly, this type of payment is no longer conned to subscription-based services. Instead it is

now available in most industries where traditionally lump-sum payments were required in the past (e.g. insurance industry). It is no surprise that the direct debit payment model found its way onto the Internet and is now being used as an alternative payment method. Fundamentally, however, direct debit is essentially a paper-based payment format. It revolves around a concept of a direct debit request (DDR) form, which is a signed, legally (if not computationally) binding contract between a customer and a merchant. It is in fact the presence of this legally binding contract that dierentiates direct debit transactions over the traditional electronic payments. The key dierence between the two models is the life span of a typical payment transaction. By choosing a direct debit option, customers are electing to establish a long lasting relationship with a merchant by committing to several payments over a specied period of time. This ongoing relationship simply does not exist within the traditional payment model. The relationship between the customer and the merchant (in relation to payment) does not extend beyond the initial transaction, as the customer is required to pay for goods or services immediately and in full. The ideas and concepts presented in this thesis borrow heavily from the direct debit payment model. As such, it is important to establish a precise denition of a direct debit transaction in the context of this thesis.

Direct debit transactions are used to split a single logical transaction across multiple physical transfers based on the agreement between a customer and a merchant. This agreement is considered legally binding on both sides. It allows customers to defer full payment for goods and services by electing to pay xed or variable amounts over a prearranged period of time. In addition, it allows merchants to debit consumer accounts without customer

intervention as long as this is within the bounds of their agreement.

Traditionally, direct debit solutions have been under the control of the major banks. To oer this

service to its customers, merchants needed to establish an ongoing relationship with their banks with all of the formalities and fees that such a relationship entails. Beside the establishment cost and

operational expenses, merchants were also required to obtained signed direct debit request forms from their customers before they could debit customer accounts. The Internet has redened the well-established rules for direct debit payments. Signed DDR forms applicable to traditional bank accounts have been relegated to the past. More and more merchants are opting to provide only a single form of payment, credit cards, to avoid the complexities of DDR forms. Unlike other account types, collecting and using customer credit card information can be done without a DDR form. This means that the entire direct debit agreement can be established completely

Chapter 1. Introduction

online. This is not the case with any other account type requiring customers to print, sign and return a DDR form to the merchant oine (clearly an undesirable and inecient step for both consumers and merchants). As such, in the present online environment direct debit agreements usually involve only credit cards and are established without any formally documented customer consent. The practice of retaining customer credit card information also empowered merchants with unprecedented ability to conduct ad-hoc transactions mimicking direct debit payments. That is, instead of establishing a formal direct debit channel requiring the participation of the bank or a third party clearinghouse, merchants are able to implement their own in-house solutions that periodically perform single credit card transactions. This increased exibility with relaxed security model makes the electronic direct debit system vulnerable to abuse. Within this thesis, several examples will be used to illustrate the benets of the proposed approach (see Chapter 4). These examples will focus on credit cards, as they are the most widely used and

recognised form of payment. However, it should be noted that the strength of the new approach is in its ability to deliver consistent behaviour across all account types not just credit cards.

1.1 Problem Statement

The migration of the direct debit payment model into a purely electronic environment has been less than ideal. The way it is currently used online has not changed at all from its paper-based roots. As such, it is neither exible nor secure and is open to abuse by both merchants and their customers. Despite the available technology, DDR forms are not signed and therefore provide no cryptographic bindings to customers and merchants. This weakens the security model as merchants may change

the terms of DDR agreements post-fact, or if they so choose, disregard contracts entirely and use customer account details in whatever way is most protable. The Reserve Bank of Australia has

acknowledged these problems as early as 2001 in its annual report (RBA, 2001), however, the changes that it recommended and subsequently introduced are policy driven rather than technological. These issues have also not gone unnoticed by the major stakeholders in this eld. The industry heavyweights such as Visa and MasterCard have for many years inuenced the development of technologies in this area. There is, however, a pattern of band-aid solutions that have consistently emerged from these organisations that while addressing immediate concerns, are ignoring the greater picture. Currently, both Visa and MasterCard have introduced competing technologies for securing credit card transactions online, however, neither are capable of supporting direct debit payments. In fact, both solutions make it impossible to integrate such payments in the future without making major changes

1.1. Problem Statement

to the underlying frameworks that they use (see Chapter 3, section 3.4 for further discussion of these technologies). Clearly, the continuing use of direct debit as an electronic payment method is problematic unless major changes are introduced to restrict merchant abilities to access customer accounts. There are certainly opportunities within this context for security improvements. The major issue that has

hindered the development of electronic payments in this particular area is lack of proper infrastructure to support delegation. Delegation is the key concept that dierentiates this type of payment from the electronic payments that are popular online today. Without this concept implementing a truly robust direct debit payment system would be simply impossible. It is precisely because of delegation that direct debit transactions do not t well into a traditional payment model. The need for customers to relinquish some control of their accounts to merchants in a secure way is completely new. Never before on the Internet was it necessary for merchants to gain control of consumer accounts without any customer intervention. This form of delegation is more common in distributed systems, where authentication credential delegation is essential. Such systems rely on credential delegation to be able to share resources, such as allowing an intermediary server to access a printer on a user's behalf. Introducing delegation or in fact any cryptographic authentication technique into an electronic payment model is problematic, as it heavily relies on the Public Key Infrastructure (PKI) to provide the necessary services, such as customer identity registration and certicate generation. Without a solid PKI framework to support it, electronic payments built using cryptographic delegation may nd it dicult to get o the ground. This has certainly been true in the past. Finally, unlike many other ideas and technologies that are capable of standing on their own, electronic payments are still dependent on the underlying banking infrastructure that has existed for decades. These legacy networks and organisations that support them are naturally risk averse and are therefore extremely reluctant to adopt new concepts and technologies. Due to the high complexity of the issues involved and the extreme diculty and high costs of deploying new concepts and technologies into the market, the pace with which innovation has been introduced into electronic payments has been particularly slow. The frameworks that have been successful at breaching this hurdle are more often than not based on current technologies and practices with all of their limitations rather than being truly innovative. In fact, the most successful of these systems (e.g. PayPal) are nothing more than proxies into current nancial networks.

Chapter 1. Introduction

1.1.1 Research Hypothesis

This thesis aims to solve some of the issues that are aecting the development of an Internet enabled direct debit payment framework. It will achieve this by developing concrete solutions to the problems described previously. Having to deal with so many issues at once in a single dissertation is dicult. Therefore, in order to retain focus the proposed solutions presented in this thesis are better formulated as a single hypothesis. As such, the objective of this thesis can be described as follows:

It is possible to develop a direct debit like payment model using only currently available, standards compliant and industry supported technologies. Using these technologies, it

should be possible to introduce minimalistic but strategic changes to the existing payment processing infrastructure that will enhance user experience and provide improved security that is missing in the current payment architecture. With increased complexity introduced by the enhanced security and improved interoperability a slight performance overhead is to be expected. However, any overheads introduced should be within acceptable tolerance levels for the industry and have a linear rather than exponential impact on performance.

The key element of the above hypothesis that is of particular importance is the emphasis on the currently available and industry supported technologies. Those elements are important as they help to minimise resistance from the nancial industry stakeholders. Changes to existing nancial applications are costly due to a high level of risk associated with them. Using tested technologies helps to minimise the risk and accelerate the implementation process. Past experience has consistently demonstrated that technologies that carry with them heavy nancial burdens are eventually rejected especially when those costs are primarily the responsibility of the merchants (see Chapter 3 for discussion of one such technology). It is the objective of this proposal to ensure that the technology discussed here is accessible to all merchants regardless of their size and operating capital. As such, the question that this thesis aims to answer is whether it is possible to introduce delegation into the existing nancial payment environment in such a way as to have a limited or no impact on the currently established processes. Another important concept presented in the above hypothesis is the performance of the proposed application. Despite enhanced security and increased interoperability, the new payment system should still meet reasonable industry performance benchmarks. Unless the application can scale it is unlikely to be considered by the nancial industry stakeholders regardless of its superior security architecture or improved communication model. A theoretical proposal presented at the Australasian Computer Science Conference by myself (Goldman, 2007) was specically criticised due to a lack of quantitative

1.1. Problem Statement

analysis proving viability of using delegation for electronic payments. Learning from that experience, this dissertation will aim to strengthen its arguments with the detailed analysis of the performance of the prototype application discussed later in this thesis.

1.1.2 Research Goals

There are a number of unresolved issues with using conventional electronic payment applications for establishing direct debit agreements. It is likewise quite dicult to reuse the same applications for securely performing direct debit transactions without sacricing customer control of their own funds. Delegation of payment authority using cryptographic tokens is an appealing option. Potentially it

would allow customers to issue proxy credentials to merchants, which can act as intermediary entities accessing consumer accounts on their behalf. This is a powerful concept as it allows merchants to

gain access to consumer funds without customer intervention but at the same time this access can be easily restricted to specic operations, such as debiting a xed dollar amount until a predened end date. This concept of delegated payment credentials has not been extensively investigated in notational payment systems. Both past and present approaches dene customer-merchant relationship in a

way that precludes delegation of authority. Instead, all eort is made to restrict merchants' access to information that would enable them to gain access to customer accounts. One major goal of this thesis is to question this traditional view of customer-merchant relationship and propose an alternative based solely on delegation. Specically, this dissertation has a number of research goals that it attempts to address. Each

goal is dependent on the successful completion of its predecessor, hence the order of the following list is important:

1. Development of a theoretical model for delegation of payment credentials from customers to merchants (see section 1.1.2.1).

2. Integration of X.509 restricted proxy certicates into the framework designed in step 1 (see section 1.1.2.2).

3. Design and implementation of a payment policy language for restricting the use of delegated payment credentials (see section 1.1.2.3).

4. Development of a reference implementation prototyping customer browser extension, merchant electronic commerce and payment gateway applications (see section 1.1.2.4).

Chapter 1. Introduction

1.1.2.1 Theoretical Delegation Framework

Before developing a concrete solution solving the issues with the current electronic direct debit model a theoretical framework is needed that proves viability of credential delegation in this context. Using delegation as a solution is natural, as it provides the features that are currently lacking in the existing model. That is, enabling the merchants to independently initiate transactions on behalf of their customers. Using cryptographic protocols this process can be properly secured without compromising the safety of customer accounts while at the same time locking the customers into a contract using non-repudiation via cryptographic signatures. Delegation of payment tokens to merchants is a unique concept never before applied to electronic payments. The aim of this goal is to investigate how this concept could be integrated into the

existing payment infrastructure causing minimum disruption but delivering the full set of feature rich capabilities enhancing overall usefulness of this infrastructure. The idea of using proxies for the purpose of accounting (this is a concept very similar to electronic payments only simplied) was rst discussed by Cliord Neuman (Neuman, 1993). This paper did not focus entirely on accounting but rather introduced various examples of practical usage of restricted proxies. In this thesis, this concept will be examined more closely to determine how best to apply it to the problem of securing direct debit payments online. Proxy-based accounting is an important step towards implementing a payment protocol that can support direct debit payments. In general, using the proxy constructs provides a lot of exibility in the way a payment protocol is designed and implemented, regardless of whether direct debit payments are required or not. Since merchants use the credentials they receive from their customers and initiate all payment transactions autonomously the only constraint that is required is reducing the scope of those credentials. In other words restricting the potential actions that the merchants can take.

1.1.2.2 X.509 Restricted Proxy Certicates

The previous goal has established the need for integrating delegation into the electronic payment model in order to facilitate direct debit transactions. Furthermore, it was concluded that this delegation must be restricted to prevent merchants from using customer accounts in ways not originally intended. That is, a mechanism is needed that would cryptographically enforce direct debit agreements established between merchants and their customers. Cliord Neuman (Neuman, 1993) originally used this concept for securing a traditional accounts based payment model using custom delegated restricted proxies. That is, a credential was issued to a service provider, which could use it to withdraw funds from a user account and deposit them into

1.1. Problem Statement

its own. The issued credential contained a set of restrictions that dened what actions the service provider was allowed/not allowed to perform. However, this particular approach did not consider all of the intricacies involved in direct debit transactions, as such the use of delegation was quite limited. In addition, it relied solely on a custom architecture for authorisation and proxy generation services. It is a goal of this dissertation to integrate X.509 restricted proxy certicates into a payment model to facilitate direct debit payments. The X509 proxy certicate standard provides all of the necessary features for a policy based restricted delegation. These types of certicates can be integrated into

existing payment frameworks with minimum eort, as they can be used as alternatives to traditional X.509 certicates, which are considered to be the standard for securing communication channels online. These certicates were originally invented to support delegation of authentication and authorisation credentials within grid environments (this was briey discussed in Tuecke et al., 2004). As part of this research goal, an investigation is required to determine the viability of this approach, as it requires a reasonably mature public key infrastructure to exist. Since customers are required to obtain and maintain a set of cryptographic keys and certicates, it is important to ensure that this can be done with the currently available technology. In addition, customers should be able to use

their certicates within their browser of choice (e.g. Mozilla Firefox) as this is the main interface used for establishing direct debit agreements online.

1.1.2.3 Semantics and Syntax of Payment Policy

The X.509 restricted proxy certicate specication denes a policy attribute that can be used to carry standard or custom restriction predicates that limit the use of delegated credentials. Since no electronic standards exist dening direct debit agreements, it is the aim of this dissertation to design a payment policy language using eXtensible Markup Language (XML) that will allow merchants and customers to dene various rules controlling the use of proxy certicates. Clearly, a payment policy language must be exible enough to be able to capture any possible scenario within the direct debit context. The challenge is to keep this language as simple and intuitive as possible since it must be accessible to customers. Unless customers can read and understand each policy, electronic direct debit agreements will never be considered legally

1 binding.

1 Legal

issues surrounding the use of digital signatures are complex and are best left to the experts. As such, legal

aspects of using digital signatures in a periodical payment framework are considered out of scope of this dissertation.

Chapter 1. Introduction

1.1.2.4 Prototype Payment Application

A prototype application is needed to ensure that the ideas proposed in this thesis will work and scale to realistic load volumes. Using this prototype some conclusions could also be made as to how easy it would be to integrate this approach into existing notational payment frameworks. The goal is to take a similar approach as in (Bellare et al., 1995, 2000) since it allows for a seamless integration with an existing payment infrastructure without high overheads. Another advantage of this design pattern is that it can be easily extended to support additional features if desired without changes to the overall architecture.

1.2 Thesis Statement

This thesis explores the subject of authentication credential delegation in the context of electronic payment systems. This study investigates how credential delegation can improve one particular form of electronic payments commonly known as direct debit. It contributes to the vast body of knowledge in the area of electronic payments by proposing a new concept in payment transaction processing entitled here as periodical payments. It raises and answers fundamental questions about traditional customer-merchant relationship and discusses a possibility of improving it while at the same time strengthening security and enhancing user experience. This thesis takes a fundamentally dierent approach to electronic payments. Instead of treating each payment transaction as a point-to-point transfer of funds, simulating physical cash changing hands, payments are viewed as a series of linked transactions. Just like in the oine direct debit

process, customers are required to sign an agreement, delegating the right to withdraw funds from their accounts to a nominated merchant. The key dierence between this proposal and what is currently provided by direct debit model is the cryptographic binding of the agreement to the customer and the merchant providing traceability, enforceability and non-repudiation. Another signicant advantage of the new approach is its practical use of the payment agreement for enforcing the terms during every single payment transaction. Unlike with the paper-based model where the agreement is only enforceable when legally disputed, or the electronic version where it is not even traceable or binding, the new approach actively assures that each transaction is within the agreed bounds of the policy, eectively preventing fraud. This is made possible by using X.509 restricted

proxy certicates carrying custom payment policies expressed as XML statements. Each certicate becomes a binding artefact that links the customer and the merchant together, which could be used in case of disputes.

1.2. Thesis Statement

1.2.1 Contribution
This thesis makes a number of signicant contributions to the current state of the art in the electronic payments eld. This section summarises each contribution:

The analysis and design of a periodical payment framework based on a direct debit model using the concept of credential delegation. This new technique allows merchants to securely gain access to consumer accounts and initiate transactions without customer intervention. Currently merchants only have two options for implementing direct debit services. Either use an acquirer payment gateway or alternatively manage sensitive customer information (e.g. credit card details) themselves. Neither approach delivers the exibility and security of the periodical payment model discussed here.

The integration of X.509 restricted proxy certicates into a periodical payment model. Using specically certicates based on X.509 specication ensures that current systems that use Secure Socket Layer (SSL) protocol for securing communication channels can be upgraded to use the periodical payment framework without signicant eort.

The design and implementation of a payment policy language for specifying conditions on the use of X.509 restricted proxy certicates. This is the rst time an attempt has been made to translate direct debit agreements into an electronic form, which can be used to enforce direct debit conditions for each transaction. Using such policies ensures that it is no longer possible for merchants to make a mistake (intentional or otherwise) and overcharge their customers by, for example, initiating two transactions per month instead of only one.

The development of a prototype Mozilla Firefox extension designed to capture base64 encoded proxy certicate requests delivered via a custom HTTP request header. This extension generates proxy certicates based on received requests signed using customers' cryptographic keys. The new proxy certicates are returned back to the caller (i.e. response header. merchant) via a custom HTTP

The development of a reference implementation of a merchant web application capable of obtaining signed payment credentials (i.e. X.509 restricted proxy certicates) from customers and using those credentials for initiating payment transactions via a payment gateway web services interface. A custom security provider was implemented to overcome a Java limitation of allowing only one SSL certicate to be set per Java Virtual Machine (JVM). Since the merchant application needs to choose which customer's credential to use for each transaction, the new

10

Chapter 1. Introduction

provider implements a mechanism for dynamically selecting digital certicates and their keys. This feature works even in a multi-threaded environment with each thread capable of using a dierent digital certicate for authentication.

The development of a prototype payment gateway application built using web services as the main (and only) interface. Using web services is a convenient way of minimising the eort This payment

required to integrate existing merchant applications into the new framework.

gateway is congured to allow only SSL trac through and its payment processing module is designed to validate payment policies against payment orders received from merchants. The

payment gateway is designed to work as a proxy between the merchant and the current payment processing infrastructure which will function unchanged.

The collection of empirical data analysing performance characteristics of the relationship between the merchant and the payment gateway. There is a distinct lack of information available on

this subject mainly due to commercial interests. Not having benchmark data made it dicult to analyse the performance of the periodical payment framework, however, the data obtained and the results documented will clearly be of value in the future. It is reasonable to assume

that other electronic payment researchers can benet from the data collected here since many new applications are beginning to follow the same approach. For example, PayPal and Google Checkout are both introducing web services over SSL.

1.3 Thesis Structure

The rest of this thesis is organised as follows. In Chapter 2, a detailed overview of the current state of academic and commercial research in the area of electronic payments is presented. Specic emphasis is placed on notational systems rather than digital coins as it more closely matches the approach adopted in this dissertation. A great deal of attention and focus is dedicated to the discussion of

popular strategies taken by the industry in this area and their inuence on periodical payments. Chapter 3 is dedicated to the analysis of the Secure Electronic Transaction (SET) protocol. This protocol was collaboratively designed by numerous industry leaders including Visa and MasterCard and contains features that are similar in concept to periodical payments. Analysis of its failure to gain acceptance within the industry despite commercial support and strong interest is used to strengthen arguments in favour of the periodical payment framework presented here. In Chapter 4 a theoretical architecture of the periodical payment framework is presented. This chapter discusses all major processes within this framework, such as creation and delegation of proxy

11

1.3. Thesis Structure

certicates and their use to initiate payment transactions. Various issues commonly associated with electronic payments are also discussed such as the double charging problem. In addition, the semantics of the payment policy language to be used for restricting proxy certicates are also discussed in detail in Chapter 4. A novel approach for using payment policies for encoding cancellation instructions is also presented. Using cancellation instructions allows customers to legally terminate periodical payment agreements before ocial end-date. Furthermore, merchants can specify any cancellation fees that may be applicable and have these rules enforced by the payment gateway. Chapter 5 presents concrete implementation details of the prototype application. Both the clientside browser extension, as well as the merchant and payment gateway web applications are discussed. All important aspects of the application as well as the issues encountered during its development and solutions found are presented. Based on the feedback received for my original conference paper (Goldman, 2007), Chapter 6 presents a quantitative analysis of the performance of the periodical payment framework reference implementation. Tests were conducted against three distinct security congurations: 1). No SSL

authentication, 2). Server-side certicate authentication only, and 3). Mutual authentication. Comparing the results from all three congurations this chapter analyses the impact of introducing proxy certicates via SSL mutual authentication and makes conclusions as to its viability in a commercial environment. This thesis concludes with a discussion of anticipated future work and conclusions (Chapter 7) once again summarising the numerous contributions made by this dissertation.

12

Chapter 2

Literature Review
This chapter contains a summary of a comprehensive literature review performed across multiple electronic payment domains and related technologies. It begins with a brief historic overview of the dierent electronic payment schemes proposed and implemented over three decades. It then continues to explore notational payment schemes that were used as the basis for the implementation of the periodical payment framework presented later. This chapter concludes with a review of the security model within grid environments that was used as the foundation for security in periodical payments. Specically, its use of X.509 restricted proxy certicates is examined in great detail as this concept and related technologies will be discussed throughout this dissertation.

2.1 Background
As was mentioned previously in the introduction, the research eld on electronic payments is quite mature. It dates back to 1983 when David Chaum presented his research on using the then newly invented technique for blind digital signatures for implementing an anonymous electronic cash system (see Chaum, 1983). This work was fundamental in sparking the decade long interest in anonymous electronic payments that duplicated physical cash. As a consequence of this work, the focus of early research into electronic payments was directed into developing protocols that would enable untraceable exchange of digital tokens between the token issuer (e.g. 1985). a bank) and the customer (see Chaum,

This approach ensured that during payment transactions, once the exchange of payment

tokens was completed the merchant would be in possession of a digital token that cannot be traced to the customer's identity. Using digital tokens to represent monitory value is dicult because unlike physical cash, tokens

13

2.1. Background

can be easily duplicated and reused. As such, detection and prevention of double spending in digital token schemes was and still is the most dicult problem to solve. There are two dierent approaches of implementing a digital token scheme, on-line and o-line.

On-line schemes oer immediate detection of double-spenders and are therefore a more secure option
that is likely to appeal to existing nancial institutions. However, on-line schemes are less ecient and are not suitable for micro-payments as their ability to process large quantities of low-value transactions is limited. Such schemes require the merchant to immediately contact the token issuer to verify validity of each token it receives from customers before completing each transaction. This solution requires the provider to be constantly on-line and to keep detailed records of either all tokens that have been deposited (e.g. Okamoto & Ohta, 1992) or all tokens that are currently in circulation but not yet

deposited (e.g. Medvinsky & Neuman, 1993).

O-line schemes oer double spending detection only post-fact.

They provide no facility for

prevention of double spending and are therefore may not be as appealing to nancial institutions whose job it will be to pursue double-spenders to recover costs. The technique that is commonly used to enable detection of double-spenders while still preserving anonymity of non-oending customers was originally presented in (Chaum et al., 1988). It works by using a variant of blind digital signatures, which unconditionally protects the customer's identity, as long as the token is only used once. As

soon as the customer spends the same token for the second time, enough information is revealed for the token issuer to trace it back to the customer's account (see Chaum et al., 1988; Ferguson, 1993, 1994; Okamoto & Ohta, 1989, 1992; Brands, 1993, 1995). In (Okamoto & Ohta, 1992), the authors also presented a mechanism for splitting digital tokens to facilitate giving of change. O-line schemes oer the most exibility and eciency but cannot on their own deliver doublespending detection. To deliver on-line double-spending prevention functionality in o-line schemes, the concept of tamper resistant hardware (e.g. smartcards) was introduced (see Even & Goldreich, 1983). Using such hardware guarantees that tokens cannot be retrieved and duplicated without damaging the hardware that stores them. Originally, concerns were raised regarding the amount of information that was possible to extract from tamper resistant devices. Considering that customer identity information was stored on them, extracting information from them would eectively eliminate anonymity and allow device providers to track customer purchases. To overcome this problem, the concept of digital wallets with observers was rst proposed by David Chaum (Chaum, 1992). The idea was to introduce an entity into the device, called the observer, that would maintain customer private information. The device ensures that no personal information is leaked out during communication between the observer and the outside world,

14

Chapter 2. Literature Review

by not letting the observer have any direct contact with the outside (e.g. Brands, 1994; Chaum & Pedersen, 1993; Cramer & Pedersen, 1994). As the name suggests these devices are not tamper proof. It has been demonstrated in the past that tamper resistant hardware can be compromised (see Anderson & Kuhn, 1996, 1998). With

time the sophistication of attacks has risen making them more and more susceptible to compromise. Consequently, measures that do not rely on tamper resistant hardware (i.e. Chaum et al., 1988) are still needed to ensure that double spending does not occur even if sudden weaknesses in the hardware are discovered. Due to the high complexity in developing and integrating digital token-based systems into open network environments, such as the Internet, a dierent approach has been considered for implementing electronic payment mechanisms. Considering that most o-line token-based applications cannot eectively prevent double spending, there is a need for an alternative, ecient on-line mechanism. Therefore, instead of using digital tokens, notational systems have been proposed that mirror conventional banking applications. Unlike digital tokens, however, notational systems are generally not as eective at solving the anonymity problem that makes tokens so attractive. This is due to the fact that account providers need to collect identity information for security, traceability and billing. Those providers that extend credit to their customers also need to accurately identify them to ensure that they can enforce payments on outstanding amounts. In general, notational systems either do not directly approach the anonymity problem at all (e.g. Neuman & Medvinsky, 1995; Sirbu & Tygar, 1995) or only provide partial anonymity (e.g. Bellare et al., 1995, 2000). Partial implementation of anonymity protects customer identity from the merchant but allows the account provider to monitor and record transaction details. As such, the protection oered is not comparable to digital tokens that oer unconditional anonymity to its users. Finally, some work has been done to combine the anonymity aspects of digital tokens with security and traceability of notational systems (see Low et al., 1994, 1996). The idea behind these systems is to use a technique rst discussed by David Chaum in (Chaum, 1981, 1985) that enables two communicating parties to exchange messages without knowledge of each other's identity and address. This technique is tailored to transfer funds between anonymous and non-anonymous customer accounts in an untraceable manner. Once funds are inside the anonymous account, the customer can make

purchases anonymously since even the account provider does not know his identity. Both debit and credit models can be supported. The focus of this thesis is on notational systems that use accounts and debit-credit model to

15

2.2. Overview of Notational Payment Schemes

enable exchange of funds between the customer and the merchant. Such systems enable a more secure, transaction-based approach to funds transfer that can be tailored to provide traceability or anonymity where appropriate. The key advantage of this approach is that cash management responsibilities are assigned to account providers rather than customers making cash management simpler and hence more secure as the funds never leave nancial institutions. Finally, notational systems facilitate

a more straightforward migration from the existing payment infrastructure. In fact, some proposed systems have attempted to re-use the existing infrastructure by providing services that use the current nancial networks for payment clearing (e.g. Bellare et al., 1995, 2000). The rest of this literature review will focus solely on notational payment schemes as the digital tokens cannot possible provide insights necessary for developing a periodical payment framework. Their design is targeted specically at duplicating the model of physical cash changing hands. This by default implies that all funds must be committed at the time of the transaction, which is completely opposite to the approach taken by the periodical payment model where payments can be deferred until later. Notational payment schemes, however, provide the right paradigm for designing an electronic payment mechanism capable of supporting periodical payments although none have been developed so far. It is recognised that whilst none of the systems presented in the next section actually support periodical payments, much can be learnt from their architectures, which could then be enhanced to support the concepts presented in this thesis.

2.2 Overview of Notational Payment Schemes

The term notational system was used in (Sirbu & Tygar, 1995; Camp et al., 1995) to describe payment mechanisms that did not use digital tokens to represent monitory value. The systems that fall within this category represent money as entries in a ledger and the exchange of funds between two parties within such a system corresponds to new ledger entries for both participants. As was stated previously, notational systems avoid the complexities of the double spending problem by never releasing funds to customers. Instead, fund transfers are done on behalf of the customers by their banks. This, however, raises privacy issues, which have become the predominant area of research for these types of systems. In general, both coin and notational systems can be described as point-to-point, that is, the funds are exchanged between two parties within a single transaction. Such approach does not t well into the periodical payments paradigm, which requires delegation of permissions from the customer to the merchant to enable the merchant to transfer funds from the customer's account without his direct

16

Chapter 2. Literature Review

intervention. None of the literature reviewed so far, directly mentions periodical payments as dened in the previous chapter. However, there do exist several interesting proposals that address various other

issues that can be enhanced to support the periodical payment model. In general, there are two types of notational schemes: debit-credit and secure credit card transactions. In this section, some of these systems will be presented. In particular, the focus of this review will be on identifying features that either directly or indirectly solve the periodical payment problem noting that it was not the intention of the authors to do so. Various early account-based proposals focused on delivering ecient mechanisms for electronic payments and as such did not actively address the more usual problems of anonymity. Two such

systems are NetBill (Neuman & Medvinsky, 1995; Yasushi Kawakura, 1999) and NetCheque (Sirbu & Tygar, 1995). The goal of these systems was to reduce the costs per transaction to ensure that they can be used for processing micro-payments.

2.2.1 NetCheque
NetCheque uses a network of distributed accounting services to manage all of the participants in electronic payment transactions. Customers and merchants are required to open an account on one of these accounting services before issuing and accepting electronic cheques. Since the NetCheque protocol does not actively attempt to solve the anonymity problem, the cheques contain both the identity of the customer and the merchant. Communication security is

achieved using symmetric key cryptography using the Kerberos protocol (Kohl et al., 1994; Neuman & Ts'o, 1994). In particular, NetCheque uses a special kind of Kerberos ticket called a proxy as a cheque signature. A Kerberos proxy ticket lets the recipient authenticate itself to an authentication service on the client's behalf (in NetCheque the merchant's accounting service can use it to authorise transfer of funds). Using a Kerberos proxy ticket is an interesting proposal as it allows merchants to authenticate directly to customer's accounting services. Since the proxy can be restricted to a particular network address and for a particular purpose, it could be used to enable periodical payments. There are some critical issues with the NetCheque proposal. Besides the obvious lack of anonymity, the scheme also fails to deliver ecient, real time clearing of cheques. It works well for the basic

scenario, in which both the customer and the merchant have accounts with the same accounting service. In this case, the clearing of the cheques can be performed in real time at a very low cost. However, if the participants belong to dierent accounting services, than cheques cannot be cleared

17

2.2. Overview of Notational Payment Schemes

in real time unless the merchant is willing to accept extra costs. The system can place a hold on the funds but cannot guarantee that the cheque will clear. The scheme relies on the fact that if the cheque bounces, the identity of the customer is known.

2.2.2 NetBill
Unlike NetCheque, NetBill architecture is not distributed. The NetBill server is designed to contain accounts for everyone within the network. It also stipulates that both the customer and the merchant must install NetBill libraries that will enable purchase negotiation and payment transaction management. NetBill accounts are linked to conventional bank accounts. The customer initiates the purchasing process by selecting the desired product and then indicating to its client-side library called a chequebook that a formal price quote is requested. The chequebook communicates directly with the merchant library called a till via an encrypted channel. price quote is received and accepted, the chequebook sends a purchase request message. In addition to payment processing, the NetBill protocol is designed to guarantee delivery of digital merchandise to customers. Hence, the purchasing phase of the protocol also involves encrypting When Once the

merchandise with one-time keys, which are only revealed to the customer upon payment.

the customer receives the merchandise, it is encrypted and cannot be viewed until the payment is processed. By calculating the checksum on the message and sending a signed response, the customer conrms receipt of the as yet unread merchandise and at the same time authorises payment. The nal step in this process, involves the till checking that the checksum is valid (i.e. the encrypted merchandise was not corrupted during transit) and using the signed message as a payment order (and the one-time decryption key) sending it to the NetBill server. The NetBill server checks the signatures on the message to identify both parties (it also checks that the decryption key will actually decrypt the merchandise), debits the customer's account and credits the merchant. The receipt returned to the merchant contains the decryption key, which the merchant must forward to the customer. Similar to NetCheque, this protocol also does not handle anonymity issues directly. While customer identity could be protected from the merchant, the NetBill server can still monitor all transactions and therefore link each customer to his purchases. Furthermore, periodical payments are unlikely to be supported by this protocol as it is heavily driven by the user interaction. Its main purpose is to enable delivery of digital content rather than being used as a charging mechanism for various services, which is where periodical payments are mostly needed.

18

Chapter 2. Literature Review

2.2.3 i-Key Protocol (iKP)

i-Key-Protocol (iKP) (Bellare et al., 1995, 2000) is another noteworthy protocol that delivers account-based, non-anonymous payment processing. Its unique contribution is its compatibility with existing payment clearing mechanisms and its staged approach designed for simplied integration. Unlike other protocols discussed in this section, iKP is in fact a series of three protocols. Each protocol builds on its predecessor and aims to deliver more security features. The designers of this protocol were aware of the importance of ease of integration with existing payment clearing technologies and as such designed these protocols to reuse the clearing capabilities already employed by the banks. To achieve interoperability, iKP uses the familiar concepts of payment gateways that serve as mediators between the merchants and the banks. Since all transactions go through the gateways

before reaching the clearing infrastructure, iKP uses the gateway concept to convert payment requests generated by the protocol into messages that will be understood by the clearing mechanism. The rst of the three protocols, 1KP is the simplest of the three, designed for quick deployment and integration. It relies on traditional authentication techniques to validate customers. Each payment order contains the customer's credit card details and a PIN, encrypted with the public key of the gateway. This ensures that the merchant cannot access private details of the customer. Time stamping prevents the merchant from capturing and reusing encrypted payment orders. Payment authorisations are signed by the gateway, which can be validated by both the customer and the merchant. Clearly, since only the gateway is capable of signing data, non-repudiation of messages originating from either the customer or the merchant is not possible. 2KP proposes the use of server-side certicates (i.e. certicates belonging to the merchant), which oers non-repudiation of messages

originating from the merchant. Furthermore, using server-side certicates gives the customers extra assurance that they are dealing with the legitimate merchant. The nal protocol in the series, 3KP, stipulates the use of certicates by both merchants and customers. This delivers non-repudiation of all requests in the system and allows stronger authentication of the customers (although for backward compatibility the authors envisage the use of PINs will continue). Just like the protocols discussed above, iKP does not completely address the issue of anonymity. In particular, while customer identity can be hidden from the merchant (by encrypting it with the public key of the gateway), the gateway and the overall payment system must have complete access to all customer information in order to process transactions. Therefore, it makes it possible for the payment system to track customer spending habits.

19

2.2. Overview of Notational Payment Schemes

Furthermore, 3KP in particular, is designed to use client side certicates as an enhanced form of customer authentication. This implies that certicates themselves carry a certain degree of trust, which at the moment is not the case. In fact, certicates merely dene an association between the public key and a name. They rarely guarantee that a Certication Authority (CA) has properly

authenticated its holder. Requiring customers to properly manage the security of their certicates is also a major issue (refer to Josang & Tran, 2000; Josang et al., 2000, 2001; Ellison & Schneier, 2000 for further discussion). Regarding support for periodical payments iKP oers this clue:

 The protocol can be extended to support batch processing of payments from the same customer by the merchant, or to guarantee amounts as commonly done, for example, in the case of car rentals (Bellare et al., 1995).

In (Bellare et al., 2000), no further explanation is given. As far as can be determined, batch processing of payments refers to the fact that customers may obtain invoices from merchants but are not obligated to proceed with the purchase at that time. The invoice is considered as an oer, which may be used at a later date to make the actual purchase. This means that the customer may present multiple

invoices from the same merchant at the same time and pay for them all at once. Clearly, this concept does not address the issues discussed in this thesis because it still involves the customer in every transaction. The merchant is not capable of initiating payment transactions independently without customer authorisation. The next two protocols use the concepts originally discussed in (Chaum, 1981) to implement anonymity within a notational payment scheme.

2.2.4 Anonymous Credit Cards

Anonymous credit cards rst discussed in (Low et al., 1994, 1996) made a signicant contribution in presenting a notational system that successfully preserved customer and merchant anonymity using techniques described in (Chaum, 1981, 1985). The design objectives of that system was to combine the privacy of transactions oered by digital cash with the security and accountability of the existing credit card systems. The proposed protocol uses anonymous accounts to separate the customer's identity from his purchases. The system works by allowing the customer to have two accounts with dierent providers, one of them being anonymous. The technique presented by David Chaum (Chaum, 1981) works by allowing customers to transfer funds between regular and anonymous accounts and then using just

20

Chapter 2. Literature Review

the anonymous accounts to make purchases. Since the account is not linked to a customer's identity all purchases are therefore anonymous. To enable this, the concept of double-locked box is used which allows funds to be deposited from one bank account into another without either bank knowing the other. This same principle is used to transfer money between the customer's anonymous account and the merchant account. The authors admit that the system does not provide unconditional anonymity but in fact, ve parties could collude to determine the customer's identity. This protocol constitutes the earliest major piece of work that makes a signicant step forward towards introducing periodical payments to electronic payment schemes. While it does not specically discuss this concept, the mechanisms presented in the two papers provide the basic building blocks for periodical transactions. For example, the authors discuss how the bank that maintains anony-

mous accounts can bill the credit card company that extends credit to the customer on a periodical basis. This is done as an automated process, which does not involve the customer. The customer's involvement is limited to receiving the bill from the credit card company, which the customer must pay. There are of course major dierence between this system and the periodical payment model being presented in this thesis. It fails to deliver true delegation of payment authorisation from a customer to a merchant. Instead it relies on prearranged agreements between two nancial institutions managing customer accounts. As such, for implementing direct debit features it suers the same problems as the conventional systems used today.

2.2.5 Mix-Based Payments

Using the network to separate customer identity from the merchant (and vice versa where appropriate) has also been discussed in (Jakobsson & M'Rahi, 1999). Just like in (Low et al., 1994, 1996), the authors have chosen to use a mix-network (see Chaum, 1981) to enable anonymous communication between transaction participants. Instead of using a single logical node to represent the mix server, this protocol suggests creating a network of bank servers and government entities to full that task. Collectively this service is named a transaction center. To enable this, a threshold scheme is used (see Blakley, 1979; Shamir, 1979;

Desmedt & Frankel, 1989, 1992) with each bank receiving a share of the private key they can use to collectively sign and decrypt payment orders. The customer begins by communicating with the transaction center to initiate a funds transfer to a blinded merchant account. The data is represented as a payment order, which is encrypted using

21

2.2. Overview of Notational Payment Schemes

the public key of the transaction center, and additionally signed by the customer. The transaction center can verify the signature and decrypt the request. It can then debit the customer's account and schedule transfer of funds to the blinded merchant account. Crediting merchant accounts is a batch process that occurs at periodic intervals. As a nal step, the transaction center signs the payment order with its private key so that the customer could provide it to the merchant as proof of payment. Note, at this stage the customer

is known to the transaction center, however, the merchant is not. Also, when transferring funds to merchant accounts during the batch process (at which stage the merchant becomes known to the transaction center), the payment orders can no longer be linked to the originating customer thus achieving transaction anonymity. Like most payment schemes based on the notational paradigm, this protocol delivers solutions to the problem of privacy without the complexities often associated with digital coin schemes. In

addition, this protocol reduces the amount of data that must be stored by customers and merchants making it a candidate for a smart card implementation. Finally, by using the notational paradigm rather than digital coins, it solves the bank robbery attack in which the attacker obtains the private key of the bank (see Jakobsson & Yung, 1996). A signicant drawback of this system is the fact that the customer has to communicate with the transaction center to initiate every transaction. Consequently, this system cannot support the

periodical payments paradigm, which theoretically empowers the merchant to initiate payments on customer's behalf without customer intervention. In fact, this protocol is designed so that the merchant (not the customer) does not actively participate in the transaction (besides supplying the customer with its blinded account). The last two protocols in this section are unique because they introduce a new concept of disposable bank accounts that represent a xed amount and which exist only briey (i.e. spent). until the funds are

2.2.6 Payment Protocols using Disposable Accounts

2.2.6.1 Anonymous Mercantile Protocol
The authors of (Low et al., 1994, 1996) have augmented their original work on anonymous credit cards by presenting a slightly modied version of it that combined anonymous funds transfer from customers to merchants with anonymous delivery of electronic merchandise in the reverse direction. In (Kristol et al., 1994) a protocol is presented that allows a customer to set up a session (i.e. temporary) account with the merchant and then submit multiple requests for merchandise. Whilst

22

Chapter 2. Literature Review

the customer has funds left in his session account, the merchant will continue to deliver data to the customer. Once the funds run out, the customer has the option to top-up his account or terminate the transaction. Clearly this new approach to account management and funds transfer introduces signicant benets to customers who can make multiple purchases from the same merchant without the overhead of performing multiple payments. Besides the convenience factor, the reduction in communication

overhead due to the consolidation of payments for multiple items undoubtedly creates a more ecient system. The authors have also discussed possible extensions to the original protocol to allow customers to leave session accounts active for prolonged periods of time. This would enable customers to make purchases at the same merchant on dierent occasions without performing any additional payments (until the funds in the session account run out). Such accounts would have a default idle or lifetime period set during initialisation that would allow merchants to automatically close them once the enddate has approached. The unspent amount is refunded back to the customer using the same technique as in (Low et al., 1994, 1996).

2.2.6.2 Mini-Cash
A similar approach was also used in (Jakobsson & M'Rahi, 1999) to implement a hybrid system that combines features of digital coins with an account-based paradigm. In this paper, the authors introduced the concept of disposable (one-time) anonymous accounts that are stored by the bank but which actually represent digital coins that belong to a particular customer. In this system, the disposable anonymous accounts provide the same functionality as traditional digital coins discussed in the previous section. Each account corresponds to a xed amount, which can only be spent in its entirety. Once the amount is spent, the account is cancelled. The protocol ensures that the disposable accounts (just like the digital coins) cannot be traced to the identities of their owners. To ensure that only the customer has access to the disposable account it is associated with a public key whose corresponding private key is only known to the customer. Spending a coin in this system means destroying the account and creating a new one whose associated public key belongs to the recipient (i.e. merchant). The main objective of this approach was to reduce the amount of data managed by the customer and the merchant. Its main contribution is the simplication of the coin paradigm, which now only requires participants to manage their own private keys whilst all of the funds storage and transaction

23

2.2. Overview of Notational Payment Schemes

management is transferred to the bank server. This oers the participants signicant saving in storage and thus makes this solution ideal for smart cards. It is also designed to protect the system from the bank robbery attack.

2.2.6.3 Use of disposable accounts for periodical payments

On the surface this approach seems to address the concept of periodical payments as was dened in the previous chapter. However, there are signicant conceptual dierences between the periodical payments discussed in this thesis and the session accounts described by Kristol et al. (1994). One major limitation of the session account concept is the fact that the funds have to be committed before the transaction takes place. This, in fact, contradicts our current view of periodical payments, which allows customers to split a single large payment into multiple smaller ones, distributed across a predened length of time. In most cases, periodical payments are used because the customer does not want to commit to a large payment within a single transaction (e.g. choosing to pay insurance premium by the month rather than paying it all at once at the start of the year). In addition, this protocol does not facilitate setting restrictions on the use of customer accounts by merchants. As such, customers have no control of how, when and by how much their accounts

are credited. Since this protocol does not oer customers these basic protections it means that if the merchant is fraudulent or negligent in maintaining up to date session account information, customers can potentially lose the funds stored in their accounts. Session accounts are not capable of supporting the desired level of granularity for account control; hence, this approach cannot be considered a sucient solution to the problem. Similarly, the disposable accounts described in (Jakobsson & M'Rahi, 1999) also only supercially resemble periodical payments. This protocol while using accounts to represent money should still really be considered as a digital coin system as its approach does not entirely t the account-based paradigm. Conceptually, each transaction in this protocol constitutes a transfer of coins from one party to another without being deposited into the recipient's mainstream account. Just like paper money, this system supports multiple funds exchanges between dierent parties without being deposited into a  real account in between each transaction. Clearly, any approach that attempts to duplicate the features of conventional cash will struggle to support periodical payments, which is a truly account-based concept. This protocol also requires the customer to commit funds before each transaction and therefore cannot delegate control of money to a third party.

24

Chapter 2. Literature Review

2.3 Overview of Electronic Payment Related Technologies

2.3.1 Grid Security Architecture
A signicant amount of research and development towards improving and standardising the X.509 proxy certicate specication (see section 2.3.2) was accomplished through the development of the grid security services. Its major contribution, the Open Grid Services Architecture (OGSA), and in particular, its Grid Security Infrastructure (GSI), has delivered a set of standard tools that use proxy certicates for authentication within a complex, heterogeneous environment. The toolset, known as the Globus Toolkit (GT version 3), delivers a set of APIs, which enable the development of secure services based on strong authentication and delegation of permissions using proxy certicates (see Welch et al., 2003; Kouril, 2005; Tuecke et al., 2004). The concept of grid computing can be dened as a collection of systems and applications that cooperatively manage resources and services across a heterogeneous, distributed network and across dierent administrative domains (Welch et al., 2003). This architecture introduced the concept of

virtual organisation (VO), which is a logical grouping of users that share common computing needs but which are not necessarily located within same physical proximity or within the same administrative domain. The grid architecture presents a very compelling reason for using proxy certicates since it requires its users to authenticate themselves to various services distributed across a wide area network. Furthermore, its sole purpose is to allow users to execute computationally expensive operations that can potentially take hours or days and that require minimal supervision from them. In the context of the grid environment, these tasks are commonly referred to as batch jobs because they are not executed when submitted. Instead they are scheduled and executed when appropriate hosts are found and enough resources have been allocated to execute them. The grid infrastructure supports cross-realm authentication using the gateway paradigm, which is used to translate authentication credentials from the common format (i.e. X.509 certicates) into site specic ones (e.g. Kerberos). To support X.509 certicates, the grid framework assumes the existence of a trusted certication authority, which can issue certicates to grid users. This ensures that such certicates will be authenticated by all services within a grid. Using proxy certicates allows grid users to create new grid identities and delegate some (or all) of their privileges to those identities. This is a highly exible and fast way of delegating credentials to user dened processes that do not involve any external parties (i.e. certication authority). This is an important aspect of a grid architecture since it is likely that new resources will be dynamically

25

2.3. Overview of Electronic Payment Related Technologies

created, which must possess valid credentials to be able to interact with other entities within the grid. Using proxy certicates to enable long running batch jobs is not in itself sucient to ensure high level of security within the grid environment. It is a commonly accepted fact that to be eective and secure, proxy certicate lifetimes should be kept to a minimum. However, at the submission of a batch job, the users rarely know how long that job will take, especially considering that it is up to the grid scheduler to nd the necessary resources and to start the job when it can. In (Kouril, 2005), a MyProxy online credential repository was introduced that allows users to store their digital certicates on a secure server administered by a grid administrator. This repository allows users to remotely access their credentials for the purpose of storing, updating and removing them. Access to these credentials is protected via an authentication mechanism (e.g. the user may need to supply username/password or end-entity certicate with a corresponding proof of possession of private key). In addition, the users may specify access control policies, which limit credential accessibility to proxy clients. To automatically renew credentials that are about to expire (i.e. quarter of lifetime remaining) a credential renewal service is used. During the submission of a batch job to the workload management service (WMS) that is suspected to take a long time (i.e. longer than the proxy certicate lifetime), the user may specify which MyProxy server can be used to renew the proxy certicate provided during the job submission process. The reference to MyProxy server tells the WMS that the user wants the proxy credential to be registered with the renewal service. The registration process involves storing the proxy certicate and the date when it should be renewed. The renewal service periodically checks its database to determine if any of the registered credentials are about to expire and if it nds any, it can contact the MyProxy server to renew them. The

connection to the MyProxy server is encrypted after mutual certicate authentication is performed. However, in addition to providing its own certicate, the renewal service must also prove possession of the proxy certicate being renewed. Once the renewed certicate is returned, the renewal service overwrites the old proxy certicate and updates the next renewal date. Alternatively, if the certicate cannot be renewed at a particular time, the system retries. An additional problem that is relevant to a grid environment is the propagation of the renewed certicates to services that are already using them (i.e. the resources that are executing user tasks). This is handled by another subsystem of the WMS, which needs to nd the resource that is executing the task for which the proxy certicate was changed. Then it needs to forward a new certicate to that resource. It is clear how the use of proxy certicates within a grid environment is applicable in periodical

26

Chapter 2. Literature Review

payments. Periodical payment requirements on delegation and authorisation can be seen as a subset of the overall problem that the grid security infrastructure is trying to solve. The general idea behind the use of restricted proxy certicates to delegate both the issuer's identity and some subset of the issuer's privileges to the bearer is identical. For periodical payments, the resources for which access is granted is always the customer's bank account, while the privileges always refer to the amount of funds that can be transferred and who can do so. Some common issues that are relevant in grids are not relevant in periodical payments simplifying the electronic payment paradigm. For example, dynamic creation of new entities within the network is not an issue since it is always known before each transaction, which parties are involved and once the payment contract is negotiated no changes are necessary or allowed.

2.3.2 X.509 Restricted Proxy Certicates

In principle, the X.509 certicate is a concept, which is applied to authentication and authorisation problems. It is used to bind a public key to a user identity, while the private key is kept secret. Using the private key, the user may prove to other parties that it is the owner of the certicate. It is clear that reliance on the private key as proof of ownership of the certicate can be problematic if the user wishes to delegate some (or all) of its privileges to other parties. Without revealing the private key, this is not possible using the conventional X.509 certicate. The proxy certicate extensions attempt to overcome this problem by providing mechanisms for delegating certicates to other parties without compromising the user's private key. In (Tuecke et al., 2004) a full specication of this mechanism is presented. The main focus of this review is on presenting this concept in the context of periodical payments. There is a minor dierence between a proxy certicate and a restricted proxy certicate that is important to keep in mind during this discussion. The proxy certicate specication denes a mechanism for specifying delegation policies, which limit the privileges that are delegated to a certicate bearer. It is possible to create a proxy certicate that unconditionally delegates all privileges that belong to the user limited only by the lifetime of the proxy certicate itself. For the purpose of this discussion, only restricted proxy certicates shall be considered. Restricted proxy certicates allow issuers to dene restrictions, which are placed on proxy certicates via policies. This enables issuers to dene which subset of their overall permissions are to be transferred to another party, thus subsequently reducing the potential damage that can be caused by credential misuse. Proxy certicates are identical to standard X.509 certicates and as such can be processed by

27

2.3. Overview of Electronic Payment Related Technologies

all existing authentication tools. The dierence is that a certicate may contain an optional proxy certicate information (PCI) extension. certicate is a proxy certicate. The presence of this extension is an indication that the

Existing tools may simply ignore this extension and process the

certicate as if it was an end-entity certicate. It is the PCI that provides the necessary framework for carrying delegation policies within certicates. interest (Tuecke et al., 2004): It contains three elds which are of particular

Policy method identier : This eld contains a unique identier (i.e. OID) that describes the
policy language used by the proxy certicate to dene restrictions. Currently, the specication denes two mandatory policy method identiers that must be understood by all implementations:

 

Id-ppl-inheritAll : Proxy certicates that use this policy method delegate all user privileges
to the recipient.

Id-ppl-independent : Proxy certicates with this method delegate no privileges. This means
that other mechanisms are needed if the user wishes to delegate privileges to the recipient (e.g. attribute certicates).

Policy : This eld is used for carrying the policy specication.

denes the actual syntax/format of the policy.

The policy method identier

Maximum path length : Allows the issuer to specify if the certicate bearer can use the certicate
to delegate user privileges further (i.e. can the bearer create/sign other proxy certicates to be used by additional parties). If the eld is empty, than no restrictions apply. If the value is zero, the certicate cannot be used for further delegation.

It is possible to enhance the certicate validation logic by using this PCI extension with delegation policies. Normally, such logic would include the following steps (Welch et al., 2004): 1. Check that the proxy certicate has a valid PCI extension block. 2. Check that the proxy certicate has a valid principal name (it should be derived from the name of the parent certicate, i.e. the issuer). 3. Check that the number of proxy certicates in the chain does not exceed the maximum path length value declared in the PCI. 4. Determine the set of permissions that are delegated to the bearer by examining the policy specication stored in the PCI policy eld. Checking of the policy would normally be given to an entity, which can interpret the policy dened by the policy method identier within the PCI.

28

Chapter 2. Literature Review

The actual policy language to be used for dening the delegation of permissions is not specied by the proxy certicate specication. As such, there is signicant exibility in choosing the right policy language that can express needed conditions within a particular application (in this case, within the periodical payment environment). There are numerous XML based authorisation languages that are available (e.g. Security Assertion Mark-up Language (OASIS, 2005a) or XML Access Control For

Mark-up Language (OASIS, 2005b)) which can be used as proxy certicate policy languages.

this dissertation, a simple, custom XML based language was designed to demonstrate basic concepts although it is acknowledged that in a real, production environment a more robust specication would most likely be required. There are some problems with using policies encoded in a proxy certicate (see Welch et al., 2004 for a discussion on strength and weakness of each approach). For example, policies contained within a certicate must be dened during the creation of the certicate, which means that no amendments to the list of privileges delegated to the bearer is possible. In addition, policies are not generic constructs but rather may contain application specic assertions. This means that generic authentication mechanisms in use today cannot verify them, which means that they cannot completely validate the proxy certicates. An alternative to using policies encoded in proxy certicates is to use attribute certicates, which are created separately to the proxy certicates. The advantage of this method is that privileges can be granted to the bearer from various sources independent of the creation of the proxy certicate. Changes to attribute assertions can also be done with greater ease, as renewal of proxy certicates is not required. Since proxy certicates are just X.509 certicates, revocation can be handled using certicate revocation lists (CRL). Just like all certicates, proxy certicates contain a unique identier, which can be used to uniquely identify them within a CRL.

2.4 Summary
This chapter presented a number of electronic payment solutions developed over three decades of academic research. Although there are many more electronic payment systems available they

are mostly variants of the schemes discussed here. Despite the number of signicant improvements achieved in this area the issue of periodical payment processing remains unresolved. To nd a possible solution to this particular problem this chapter examined other technologies not directly linked to electronic payments such as security of grid environments. This dissertation aims to combine the

29

2.4. Summary

existing ideas of electronic payments with the new developments in credential delegation technologies to enable secure periodical payments. In the next section, this literature review is expanded to

encapsulate commercial research and development in this area.

30

Chapter 3

Secure Electronic Transaction (SET) Literature and Technical Review

The previous chapter presented an overview of the developments in the electronic payments eld achieved through academic research. While it contains a substantial amount of information regarding various types of systems proposed and implemented over the last three decades, its scope is limited to only those proposals that have been pursued within academic circles. As such, the previous chapter presents an unbalanced view of the research and development achievements within this eld. This

chapter aims to rectify this imbalance by analysing various commercial attempts at solving security issues within electronic payments. Specically, it focuses on Secure Electronic Transaction (SET)

specication, as it was the most radical and inuential commercial protocol of its time. It continues with analysis of its eventual abandonment and presents the current solutions being actively advocated by the industry leaders, such as Visa and MasterCard.

3.1 Background
Traditionally, the nancial industry has been risk averse when introducing new concepts and technologies into its long established processes. Even seemingly small changes to infrastructure are costly and time consuming. As such, at times this industry has lagged behind the technological

developments. However, from time to time attempts are made to break away from the accepted status quo by introducing new and radical changes to current systems. Both Visa and MasterCard, for

example, are currently in the process of implementing and deploying new and competing authentication

31

3.2. SET Overview

technologies aimed at reducing credit card fraud. These technologies will be covered in detail later in this chapter. Before introducing competing products solving credit card fraud issues, both Visa and MasterCard along with several industry leaders worked together in designing a fundamentally new electronic payment protocol for credit card transactions over the Internet. In the late 1990s a Secure Electronic Transaction (SET) specication was developed oering the market a new solution for processing credit card payments. With enormous nancial support and initial strong interest in this technology it seemed that SET was destined to be the next break through in electronic commerce. It has been over a decade since Visa and MasterCard have unveiled their vision by presenting SET. However, despite all their eort this technology did not achieve the necessary traction within the industry to become the globally accepted standard for credit card payment processing. This

technology was abandoned to the extent that even obtaining references to the original specication documents is becoming dicult. No references to this protocol exist on either Visa or MasterCard web sites and the

www.setco.org

site dedicated to it has been disabled.

There is no doubt that SET was and most likely still is the most ambitious and technically advanced specication dealing with electronic payments. Despite its failure there is quite a lot that can be learnt from it. Perhaps, by studying its design and by analysing the reasons for its failure its mistakes can be avoided in the future.

3.2 SET Overview

3.2.1 Registration Phase
Before either cardholders or merchants can participate in SET secured payment transactions, each one must posses a digital certicate, which can uniquely identify them to each other. The registration phase of the SET specication deals with describing the process of obtaining a digital certicate from a certicate authority (CA). A registered CA can be any service provider that issues certicates on behalf of a card brand (e.g. Visa, MasterCard, etc). It can be an independent third party company or it can be cardholder issuers and merchant acquirers.

3.2.1.1 Cardholder Registration

Cardholders are responsible for obtaining their own digital certicates using SET client-side software. This software allows cardholders to establish a secure connection with a Certicate Authority

32

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

Figure 3.1:

Cardholder Registration

(CA), which will issue them a certicate. The cardholder registration process is described in detail in (MasterCard & Visa, 1997a,b).

1. Cardholders' software bootstraps this process by sending the CA an initiate request message, which contains the name of the cardholder and a freshness challenge that the CA needs to return as part of the response message.

2. Once the CA receives an initiate request message, it is responsible for preparing the initiate

response message. This message will contain its certicate as well as the freshness challenge it
received from the cardholder. The message is digitally signed using the CA's public key.

3. Once the initiate response message is received, the cardholder software has all of the information it needs to securely communicate with the CA. However, rst it needs to validate the CA certicate by traversing its trust chain to the root certicate. Presumably the root CA would most likely be the card brand itself. The next message in the process is the registration form request. The registration form is

normally obtained from the cardholder's issuer. A CA needs a credit card number to correctly identify which registration form it needs to return to the cardholder. Since this request message is carrying sensitive information, it is encrypted using a symmetric key, which is generated by the cardholder's software. This key is in turn encrypted using the CA's public key.

4. When the CA receives the registration form request message it will extract the card number and using the rst six to eleven digits identify the cardholder's issuer. If the registration form is available locally, the CA can simply return the registration form back to the cardholder.

33

3.2. SET Overview

Figure 3.2:

Merchant Registration

Alternatively, for example if cardholder's issuer is operating its own CA, the CA returns a

referral response message, which tells the cardholder's software to contact an alternative CA.
5. At this point the cardholder needs to ll out the registration form giving such details as card number, billing address, etc. In addition, the cardholder's software also needs to generate the public/private key pair (if the cardholder does not have one). The public key is going to be

bound to the identity of the cardholder inside the certicate. The certicate request message is encrypted using a symmetric key that the cardholder's software generates. In addition, another symmetric key (also newly generated) is enclosed so that the response generated by the CA (i.e. the certicate) can be encrypted using this key.

6. When the CA receives the certicate request it validates all of the information that is in it (how it does that is out of scope of the SET specication). When generating the certicate, the CA encloses a hash of the card details (i.e. the card number, expiry date and secret value). The link to the certicate can be proven if this information is known but of course it cannot be derived from the hash value. The signed certicate and the secret value is encrypted using the symmetric key generated in the previous step and sent to the cardholder.

3.2.1.2 Merchant Registration

Merchant registration process is simpler than the cardholder registration process. It does not

require the exchange of credit card details reducing the communication overheads by one message. Instead, the merchant receives the registration form as a response to its initiate request message. The merchant registration process is described in detail in (MasterCard & Visa, 1997a,b).

1. Before issuing a certicate to the merchant, the CA needs to identify the merchant's acquirer. Unlike with cardholders that can number in millions, there can only be a relatively small number

34

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

of unique merchants, hence it can identify them by name rather than card numbers. To receive a registration form therefore the merchant must include its name in the initiate request message it sends to the CA. Since the name is not a secret, it can be transmitted to the CA before its certicate is received (i.e. before secure communication channel is established). 2. When the CA receives initiate request message it will nd which acquirer the merchant belongs to and then retrieve the appropriate registration form for it. In addition to the registration

form, the CA will also include its certicate in the response message so that the merchant can securely communicate with it. The response message is digitally signed using the CA's public key. 3. Once the registration form is received, the merchant has all of the information it needs to securely communicate with the CA. However, rst it needs to validate the CA certicate by traversing its trust chain to the root certicate. Presumably the root CA would most likely be the card brand itself. Completing the registration form is the next step in the process. Such information as the

merchant's name, address and unique identier are recorded. It is assumed that before this can be done that the merchant has already established a relationship with an acquirer o-line. In addition, the merchant must also generate two sets of public/private key pairs, one for signature and the other for encryption. All of this information is combined into a certicate request message which is encrypted using a newly generated symmetric key, which itself is encrypted using the CA's public key. The entire message is signed by the new signature key and transmitted to the CA. 4. Once the CA receives, decrypts and validates the signature of the certicate request it needs to validate the information provided by the merchant inside the registration form. The method for doing this is not specied in the SET specication. Provided that the information is correct, the CA will issue a new certicate signed by its public key. The certicate is encrypted using a newly generated symmetric key, which is subsequently encrypted using the merchant's public key (i.e. the encryption not the signature key). The certicate is then sent to the merchant.

3.2.2 Purchase Phase

SET is concerned with payment rather than shopping experience hence this part of the protocol assumes that the cardholder has already chosen the items to buy and has selected the SET payment option. SET process starts with the cardholder requesting a certicate of the payment gateway, which

35

3.2. SET Overview

Figure 3.3:

Purchase, Authorisation and Capture

it needs to securely exchange payment instructions with it without revealing them to the merchant. The purchase phase is described in detail in (MasterCard & Visa, 1997a,b).

1. The cardholder software sends an initiate request message containing the payment card brand that the cardholder is using and the freshness challenge, which it expects to receive back from the merchant.

2. The merchant must include the freshness challenge in its response to the cardholder. It must also identify the appropriate payment gateway certicate corresponding to the card brand that the cardholder requested (presumably each payment gateway will support multiple card brands, hence it will have multiple certicates signed by each one). In addition, the merchant must also forward its own certicate to the cardholder so that it can securely communicate with it.

3. When the cardholder software receives initiate response message, it will check the validity of the merchant and the payment gateway certicates by traversing their trust chains. Assuming that they are valid, the software will generate the order instruction (OI) and the payment instruction (PI) constructs. Both constructs are hashed separately, then the hashes are concatenated, hashed again and the result signed using the cardholder's public key. This creates a dual signature. A new symmetric key is generated and the dual signature and the PI are encrypted. Then, using the payment gateway's public key the symmetric key is encrypted itself. then sent to the merchant as a purchase request message. This information is

36

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

4. When the merchant receives the message it can verify the cardholder's certicate by traversing its trust chain to the root certicate. In addition, it can also validate the dual signature. Note: while the OI information is accessible, the PI is encrypted and can only be decrypted by the payment gateway. In order to verify the signature, the merchant software needs to calculate the hash of the OI and in combination with the hash of the PI it received from the cardholder it can determine whether the signature is authentic. Depending on whether the merchant chooses to process the request in real-time or defer to later (i.e. batch processing), it can either respond to the cardholder straight away or proceed to the payment authorisation phase. Let's assume that payment authorisation is done in real-time before conrming the transaction.

5. Using the payment authorisation request message, the merchant can use the payment gateway to communicate with the issuer to debit customer accounts. This message needs to contain

the payment details (e.g. amount and transaction identier). In addition, the merchant must forward the payment instruction (PI) construct that it received from the cardholder. While the merchant cannot see what's inside it as it is encrypted using the payment gateway's public key, it is needed so that the payment gateway can verify that both the cardholder and the merchant are talking about the same transaction. This message is signed using the merchant's signature public key and encrypted using a newly generated symmetric key, which itself is encrypted using the payment gateway's public key.

6. When the payment gateway receives the payment authorisation request it conrms that the signatures on the merchant portion of the message and the PI signed by the cardholder are valid. Using the hash of the OI (which it cannot read) and calculating the hash of the PI it Once this information is veried

can verify that the dual signature was not tampered with.

the payment gateway can contact the issuer using the existing payment network. The response that the payment gateway receives is converted into a payment authorisation response, which is signed by the payment gateway and returned to the merchant at which point it can notify the cardholder. A special token can be added to the response, which the merchant can use when requesting payment capture. This token was added to improve performance of the capture phase by reducing the amount of authorisation that needs to occur (because the payment has already been authorised).

7. When the cardholder software receives the purchase response message it can verify the merchant signature and display an appropriate message to the cardholder. The message (i.e. status) will depend on how the merchant chooses to process the purchase request. For example, if such

37

3.2. SET Overview

requests are batched the messages that may come through may be of the type  authorisation pending or  submitted for payment , etc.

8. Payment capture does not have to and in most cases will not happen directly after the purchase request phase. SET is designed to allow batch processing of payments. When the merchant does decide to capture payments it received from its customers, it will generate a payment capture

request message, which it will send to the payment gateway. This message must contain the
nal amount and the transaction identier retrieved from the OI construct. Just like all other messages, this one is digitally signed using the merchant's signature public key and encrypted using a newly generated symmetric key, which in turn is encrypted using the payment gateway's public key.

9. Using the information contained inside the payment capture request and the token, the payment gateway can create a request message, which it can forward directly to the issuer via the payment network. Any responses produced are signed using the payment gateway's signature key, encrypted using a newly generated symmetric key and sent to the merchant.

3.2.2.1 Recurring or Instalment Payments

The SET specication (see MasterCard & Visa, 1997b) discusses an interesting approach to payments that is similar to the model presented in this thesis called instalment payments. payments are designed to allow the merchant to charge the customer multiple times. accommodates for partial delivery of goods or services. Instalment This design

It works by allowing the merchant to give

customers an option of paying for its services over several transactions. This option is presented to each cardholder during the purchase phase (i.e. purchase request may contain an additional construct that determines how subsequent transactions are conducted). As discussed previously, when cardholders authorise payments, they include a payment instruction (PI) construct. The intended recipient of the PI construct is the payment gateway. As such,

the merchant cannot read or modify it.

One of the optional attributes of the PI construct is an

InstallRecurData. This construct allows the merchant and the cardholder to specify the terms under which each subsequent instalment will be processed. For example, it contains such information as the frequency of each transaction (in number of days between each authorisation) and the expiry date. Specifying frequency of twenty-eight indicates a monthly payment option. Normally, the merchant can only use a PI received from the cardholder once unless the additional information is provided to let the payment gateway know that the PI is intended for instalment

38

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

payments. When the merchant prepares an authorisation request message using this PI, an additional indicator is used, Subsequent Authorisation Indicator, that lets the payment gateway know that the merchant needs an authentication token for next time. When the payment gateway prepares

a response, it adds an Authentication Token to the message which must be presented next time the merchant initiates a transaction using the same PI. This token would normally contain such information as the transaction identier, purchase amount, number of times payments were performed, etc. When processing the last instalment payment, the payment gateway will not return a valid

authentication token which eectively stops the merchant from initiating any more transactions against a cardholder's account. SET instalment payments are a good rst attempt at introducing delegation into a payment process. However, this solution is neither exible nor extensible and is unlikely to support realistic direct debit scenarios that exist in a commercial environment. The policy language to be presented later in this thesis extends this concept by delivering a complete, extensible solution capable of supporting most common direct debit scenarios.

3.3 Issues
There are various reasons why SET failed as a credit card payment protocol despite being the most ambitious and technically advanced scheme at the time. In this section, the most important issues with this specication are discussed.

3.3.1 Complexity
At approximately one thousand pages, SET specication is not the easiest material to read and comprehend. The sheer volume of information is overwhelming especially when compared with the relative simplicity of the TLS specication (Dierks & Allen, 1999), which currently stands at a mere eighty pages long. Having sifted through the material that is available, including supporting documentation and papers written through independent research, such as (Paulson, 2002; Bella et al., 2002, 2003; Stallings, 2006), one question still remains to be answered: is this complexity necessary or has SET been over engineered? In this section, some of the more interesting decisions in its design will be closely examined. Each phase of the SET protocol presented in the previous section will be examined separately.

39

3.3. Issues

3.3.1.1 Registration Phase

SET specication describes a formal registration process for cardholders and merchants. This

particular part of the specication is by far the most complex component (Bella et al., 2003) in the protocol. It is much more involved than the actual purchase and authorisation phases. While an

automated merchant process seems like a good solution with relatively low complexity and a high probability of successful adoption, it is quite clear that the cardholder registration phase is unlikely to work in practice. In this section, only the cardholder registration process will be analysed. It is obvious why cardholder registration specication was introduced. SET relies heavily on

the client-side certicate authentication and for this to work its designers realised that a standard way of issuing cardholders with certicates was required. cardholder participation when obtaining certicates. The proposed solution mandates active

Each cardholder needs to have an ability to

generate public/private key pairs, which can then be bound to their identities and their credit card numbers within a certicate. This in turn means that each cardholder must be in possession of the necessary software for performing these tasks and the necessary knowledge to operate it. Within the SET specication, a generic Certicate Authority (CA) concept is used as the issuer of all cardholder certicates. A CA can be any organisation (including the cardholder's issuer) that chooses to provide such a service. It is not precisely specied how the user can establish what CA can or should be used. Presumably this is a feature that could have been implemented via the client-side software. Such uncertainty, however, does lead to confusion, since it is not clear how the cardholder would initiate this process for the rst time. This is important because choosing the wrong CA has its problems. When requesting a registration form from a CA, it will establish whether it can obtain issuer registration form or whether it needs to redirect the cardholder to another CA (using a referral response rather than the registration form response). Should the cardholder software receive a referral response, it will return to the beginning of the registration process by contacting the referred CA. Clearly, this is an inecient approach for obtaining a certicate. Since SET Business Description (MasterCard & Visa, 1997a) does stipulate that the cardholder's issuer itself can be a registered CA, it is not clear why the responsibility of issuing all cardholders with certicates (and their corresponding keys) was not given directly to the issuers. Granted there is a theoretical chance that a compromised issuer can expose cardholders' private keys this is highly unlikely. Allowing issuers to provide cardholders with the cryptographic credentials they need o-line (for example when issuing new credit cards or on request), means that cardholders no longer need to be involved in the complex procedure of key generation and certicate registration. Instead, they can

40

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

focus their attention on shopping and payments. For example, Australian Tax Oce (ATO) uses this approach for distributing cryptographic credentials to Australian businesses that register to use its online services. It works by allowing customers to download and install digital certicates from its secured servers, although it does have a substantial o-line overhead for distributing passwords, USB tokens and any additional software required. In the context of card issuers, however, this overhead is minimal because keys and certicates can be distributed using the same procedures as used for provision of credit/debit cards. Given the current state of technology and the already established processes, the certicate registration phase formulated by SET seems redundant. The issuers are providing their customers with already pre-populated hardware tokens that contain all the necessary keys and certicates that they will need. Not providing such credentials when issuing cardholders with authentication tokens (e.g. credit/debit cards) seems impractical and unlikely to be done in practice.

3.3.1.2 Purchase Phase

The purchase phase of the SET protocol is somewhat complicated because of the three-way interaction that occurs between the cardholder, the merchant and the payment gateway. SET requires the cardholder to be directly aware of the payment gateway used by the merchant. The interactions that can occur between these three parties can take several alternative execution paths (Bella et al., 2002) causing unnecessary complexity. The initiation of the protocol is interesting because as is the tradition of the SET specication, the cardholder must start it. Once again this is only possible because of the custom client-side software that must be installed prior to making payments. It is unclear, however, precisely how to bootstrap the initiation process. SET specication assumes that the client software will know at which point to send the initiation request. This is an easy assumption to make, however, in practice, without a standardised approach for establishing a SET session, leads to complications such as interoperability issues discussed later. In fact, SET makes many assumptions regarding the state of the application when the protocol is initiated. 1997a) reads: For example, the SET Business Description (MasterCard & Visa,

The OI does not contain the order data such as the description of goods (the items and quantities) or the terms of the order (such as number of instalment payments). This information is exchanged between the cardholder and merchant software during the shopping phase before the rst SET message.

41

3.3. Issues

Since SET deals exclusively with the payment and not the shopping process, such important facts are left unspecied. However, clearly SET relies on these pre-initialisation steps to be followed, otherwise the whole protocol cannot be bootstrapped. This rst step is only necessary because it needs to facilitate the three-way interaction. That is, the cardholder software needs to obtain the certicate of the payment gateway that the merchant is using. By removing this dependency on the payment gateway, this step can be easily removed

from the specication. The drawback of doing this is that the payment instructions will no longer be hidden from the merchant. However, as will be demonstrated later, the security can be derived from the knowledge of the private key rather than being able to successfully hide credit card details (i.e. knowledge of credit card number does not allow an attacker to make payments, hence hiding it from the merchant is unnecessary). There is an alternative method that could be used to hide credit card details from the merchant. Instead of issuing the cardholder with a single certicate that uniquely identies them to the issuer, each cardholder may be issued with multiple certicates each one representing a unique binding between the cardholder's identity and an account number. Depending on which certicate is used, the payment gateway can determine which account to debit while the merchant remains unaware. There is another advantage of removing the requirements for bootstrapping the SET session via the client software. The necessary standards required in the rst case are no longer needed because it is up to the merchant to decide when to start the protocol. This is the way online payments work today. The merchant presents the cardholder with the payments page, which must be lled in by the cardholder with the credit card details. Submission of this page initiates the process. The use of dual signatures is an excellent idea to be able to hide purchase and payment details from various parties in the transaction. It does, however, complicate the algorithm and makes the purchase phase of the protocol longer. In order for all parties to be able to correctly conrm the details of the transaction (without being able to read all of the information), quite a substantial amount of information is repeated in each message (Bella et al., 2002). By removing the need to hide payment instruction details, a substantial reduction can be achieved with a moderate level of simplication to the overall algorithm (not much on its own but in combination with other improvements is a substantial enhancement). Another interesting part of the specication involves the use of PAN Secret, a random secret that can be used to authenticate cardholders to the payment gateway. In most cases, PAN Secret seems somewhat redundant considering that in most PKI solutions, proof of possession of the private key is sucient in order to authenticate a client presenting a digital certicate.

42

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

PAN Secret does have a place in the protocol in cases when the cardholder does not have a digital certicate. Hashing of the PAN Secret in order to authenticate the cardholder to the payment gateway seems like an acceptable solution in such cases.

3.3.2 Immature Technology

It is true that SET was and probably still is, by far the most advanced specication for securing credit card payments in open networks. At the time of its conception, it was based on bleeding-edge technologies utilising the most advanced cryptographic techniques that even now are not commonly used. For example, SET depends on authentication and authorisation of credit card payments by This form of authentication requires the presence of a large, distributed In other words an

using client certicates.

infrastructure for supporting certicate issuance, revocation and management.

open public key infrastructure (PKI) was assumed to exist that would support the SET standard. Such infrastructure is expensive to build and maintain, and most importantly requires a substantial amount of time and signicant nancial investment to establish. Even now, a decade later, such

infrastructure does not exist despite continuous interest in certicate-based authentication. Its use is limited to Intranet based applications. Client-side authentication as presented in SET also suered from lack of portability. Each SET client machine needed to have installed both the SET client software and a copy of the cardholder's certicate and private key. Eectively, this meant that cardholders needed to install SET software and their certicates on all machines that they were going to use. Clearly this is not a desirable or practical approach. The use of smartcards was recommended as a possible solution to this problem. However, at the time of SET's development, just like now, smartcard support on customer PCs was practically non-existent. In recent years this has changed with the development and widespread

adoption of Universal Serial Bus (USB) standard. Using this technology, USB cryptographic tokens have emerged that combine both the smartcard and a reader in a single device. This eectively solves smartcard integration issue on customer platforms, as USB penetration of the consumer PC market is adequately comprehensive. This thesis relies on this fact as it pursues the same approach of using client side certicates for authentication and delegation. Furthermore, the use of custom client-side software at the time would have been a signicant deterrent. The need for installing a heavyweight application on client machines even now is considered  bad practice . With limited bandwidth available to users at the time it was unacceptable. This was discussed at length in (Wolrath, 1998) with issues relating to shopping cart abandonment associated with complicated shopping experiences being cited as signicant problems faced by retailers. These

43

3.3. Issues

issues are not as prominent now due to improvements in browser technologies that streamlined installation of small client-side applications using browser extension or plug-in frameworks (e.g. Mozilla Firefox framework allows the use of XUL with JavaScript for extending both its user interface and business logic). This thesis makes heavy use of these features for seamlessly extending browsers in order to implement custom business logic for supporting delegation. Requiring minimal user eort and using very little bandwidth this approach is considered appropriate in the current environment.

3.3.3 Performance
Due to its complexity and improved security model SET struggled with performance. Its overuse of digital envelopes at every stage of the process requiring generation of multiple symmetric keys followed by continuous verication of signatures made it unacceptably slow. For example, Wolrath (1998)

described how some vendors reported lag times of up to fty seconds for processing a single cardholder request. The recorded times encapsulated both the initial cardholder request, up to and including

receiving the approval response from the merchant. Such times were produced within controlled test environments so in a real world application it is reasonable to assume that these gures would have been even greater. By comparison, securing transactions using SSL incurs a fraction of the cost in time and is likely to be a more acceptable form of security for the average cardholder. This is an undeniable fact since SSL has been the predominant technology for securing payment transactions since even before SET and it continues to be a popular and in most cases the only form of payment transaction security. While performance is very likely to have been a problem a decade ago, it is also possible that the interface between the client and the merchant also could have played a part in its demise. Reading this market survey (Wolrath, 1998) it quickly becomes apparent that most SET client side applications provided no feedback to the users regarding the progress of payment transactions. Considering the average processing time of up to a minute, the lack of feedback via the user interface would most denitely have created negative customer experience leading to unfavourable customer opinions.

3.3.4 Cost vs Benet

Another implication of the extreme complexity of the SET standard was the high cost it imposed on its implementation and integration into a real electronic commerce application. Being burdened with the majority of the cost of introducing SET into their applications it eectively meant that only relatively large merchants could actually aord to implement it. Having little incentive and facing

enormous costs, most merchants decided not to pursue this expensive option.

44

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

The maintenance and support of these applications was also an issue because the merchant became a critical service provider in the payment process rather than being a proxy between the cardholder and the acquirer. In (Wolrath, 1998) a discussion of a pilot SET project revealed that the diculties of integrating SET into an existing online store application were so severe that only one out of thirty participating companies managed to successfully do it. The fundamental question that needs to be asked about SET is whom is it really beneting the most? It seems that it is in fact the card brands and the banks that stand to gain the most By promoting a safe and secure electronic

out of increased security in the electronic marketplace.

environment the card brands establish themselves as the exclusive supplier of the payment processing service, at the same time increasing brand awareness and gaining market share (Wolrath, 1998). There is no question that the merchants and cardholders stand to benet as well, however, when it comes to justifying cost over benet, it seems that the market has chosen to pursue other, less expensive alternatives. Perhaps if the Internet community quickly adopted the standard, more merchants would have been able to justify the cost of implementing a SET application.

3.3.5 Interoperability
SET is merely a specication that denes the message formats and procedures that a compliant application must follow to conduct secure credit card transactions online. This specication does not cover the entire shopping process; it only deals with the payment part of it. When it came out, various vendors attempted to implement the specication in order to gain that all-important market share. In theory, any compliant SET application should have been able to interact with other SET applications developed by dierent vendors, however, in practice this did not prove to be the case, as was discussed in (Wolrath, 1998). While large companies, such as IBM tried to develop other standards to ensure that SET vendors produced applications that could inter-operate with each other (e.g. Interoperability Reference Guide For SET 1.0), this clearly did not lead to an acceptable, long-term solution.

3.4 Credit Card Security after SET

3.4.1 Visa and MasterCard
It has already been briey mentioned at the start of this chapter (see section 3.1) that both Visa and MasterCard have abandoned SET. Instead they have introduced alternative, competing technologies aimed at solving credit card fraud issues. For Visa this technology is Visa Three Domain

45

3.4. Credit Card Security after SET

(3-D) Secure authentication protocol, while MasterCard implemented a Secure Payment Application (SPA) protocol. Both protocols solve exactly the same problem but using a dierent approach. A good discussion of each protocol along with feature-by-feature comparison is provided by (GPayments, 2002b).

3.4.1.1 Visa Three Domain (3-D) Secure

Visa 3-D Secure model works particularly well in the current browser dominated business environment. It uses browser redirection as the main mechanism by which cardholders are authenticated. Instead of burdening the merchant with the task of obtaining user credentials, their only responsibility is to determine what issuer the cardholder belongs to using Visa Directory service and then redirecting the cardholder's browser to that issuer for the actual authentication. After the authentication step is performed, the cardholder's browser is once again redirected to the merchant web site. This works particularly well for username/password authentication model, as it requires no additional software on the cardholder's machine. For strong authentication (e.g. smartcards), however, this clearly is not appropriate. Visa dictates that additional software must be installed on each cardholder machine for chip type authentication (GPayments, 2002b). There is a disadvantage of using browser redirection as a mechanism for cardholder authentication. In particular, it dictates that each payment transaction requires a new authenticated session, meaning the cardholder must be redirected to the issuer for every transaction and therefore enter username and password multiple times. There is no scope for credential caching or reuse. Figure 3.4 illustrates the initial steps that the cardholder and the merchant must perform to begin a purchase transaction. These steps do not include the authorisation and the clearing process that the merchant must perform post fact (GPayments, 2002a,b):

1. The cardholder must provide the merchant with sucient detail in order to obtain a reference to the cardholder's issuer. Normally, it is the rst several digits of the credit card number.

2. Using the Visa Directory, the merchant can resolve the reference to the issuer and let the Visa Directory determine whether that issuer is capable of providing a 3-D Secure service.

3. Assuming that the issuer is capable of participating in a 3-D Secure transaction, the merchant will redirect the cardholder to its issuer for authentication.

4. When the cardholder's browser is redirected to the issuer, the cardholder must provide the issuer with its customer number and the password. Since the cardholder is communicating directly

46

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

Figure 3.4:

Visa 3-D Secure Payment Initialisation

with the issuer, username and password information is never revealed to a third party (e.g. the merchant). 5. Assuming that authentication credentials are valid, the issuer must create and sign a response message and redirect the cardholder's browser back to the merchant web site.

Once the cardholder is redirected back to the merchant site there is not much that the cardholder must do. Once the submit button is clicked, it is up to the merchant to initiate an authorisation request to the acquirer and follow the steps that are normally done when requesting payment. This process is identical to the steps that current merchant applications must follow to initiate a transaction. Figure 3.5 illustrates this process which is described in detail in (GPayments, 2002a,b):

1. Assuming that the issuer successfully authenticated the cardholder (i.e.

the issuer provided

the cardholder with a valid, signed response message) the merchant proceeds with payment authorisation and capture as per normal. That is, it issues a payment authorisation request to the acquirer. 2. The acquirer must contact the cardholder's issuer directly for it to authorise the payment. The reply received from the issuer is returned to the merchant. 3. The merchant can use the reply from the acquirer to prepare a receipt, which is provided to the cardholder.

47

3.4. Credit Card Security after SET

Figure 3.5:

Visa 3-D Secure Payment Authorisation

3.4.1.2 MasterCard Secure Payment Application (SPA)

The approach that MasterCard is pursuing relies on the use of applets for provision of authentication information received from cardholders. A SPA applet must be installed on every machine that the cardholder intends to use for making online payments. There is a dierence between the SPA and the SET applets. Unlike SET, a SPA applet does not require any customer specic information, hence it can be safely installed and used on even unsecured machines (e.g. Internet cafes, etc). Cardholders do need to enter issuer information before making purchases as it is needed during authentication. Using an applet instead of browser redirects means that customer credentials can be cached locally and reused over multiple payment sessions. It also means that integration with smartcards is easy as all of the software is already installed on the customer's machine. Once shopping is completed the credentials are destroyed and another user can safely reuse the same SPA applet. This is dierent to the approach that Visa has adopted which requires cardholder authentication for every single transaction and does not implement smartcard support by default. Figure 3.6 illustrates the complete set of steps that all participants of the SPA enabled payment transaction must perform in order to capture a cardholder payment (GPayments, 2002b).

1. The MasterCard SPA applet installed on the cardholder's machine is activated when it encounters a SPA compatible page. At this stage, the cardholder is asked for authentication credentials (e.g. username and password).

2. The SPA applet is responsible for securely communicating with the issuer when authenticating the cardholder. Assuming that the credentials entered by the cardholder are correct, the is-

48

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

Figure 3.6:

MasterCard SPA Payment Authorisation and Capture

suer will generate an authentication token which the SPA applet needs to keep and provide to merchants.

3. When the cardholder accepts the terms of the purchase, the SPA applet sends the authentication token to the merchant, which it can use to authorise payments via its acquirer.

4. The merchant sends a payment authorisation request together with the authentication token it received from the cardholder. This request is forwarded to its acquirer, which uses the existing MasterCard network for payment authorisation and clearing.

5. Having the authentication token in its possession means that the acquirer can forward it to the issuer directly (via MasterCard network) saving it additional authentication steps. Whatever response it receives from the issuer is forwarded to the merchant.

6. The merchant informs the cardholder of the status of the transaction by issuing a receipt message.

49

3.4. Credit Card Security after SET

3.4.1.3 Discussion
It seems that both Visa and MasterCard have abandoned the strong-authentication approach to securing credit card payments online in favour of the more traditional username/password methods. However, they have left sucient exibility in their specications to allow for strong, two-factor authentication integration in the future. Both specications are tailored towards providing cardholder authentication at the time of the transaction initiation. This means that it is assumed that the cardholder is present at the time of the transaction and that the cardholder knows the secret that can identify it to the issuer. These

assumptions strongly favour the single transaction model of payment processing and therefore neglect the alternative. That is, allowing for delegation of customer credentials to merchants. In this thesis, a periodical payment model is presented. This model works on the principle that a single physical transaction (i.e. the one that has the cardholder actually present) can be split into several logical transactions. The merchant, directly without any cardholder intervention initiates

all such transactions. This concept was also discussed and implemented in SET via its  instalment payment mechanism. Unfortunately, the current approach to cardholder authentication does not

take into account this particular business model. Visa 3-D Secure, for example, requires the cardholder to be physically present at the time when the transaction is being initiated. The cardholder must present username and password to the issuer before the merchant can request payment authorisation and capture. This model leaves no room (at this stage) for delegating cardholder permissions to the merchant and has no facility for specifying the terms under which periodical payments can be performed. MasterCard SPA works on a similar principle. While its use of the SPA applet allows for reuse of an authentication token, this only works while the cardholder is still online. There is no mechanism for delegating cardholder privileges directly to the merchant so that it can initiate payment transactions without the cardholder.

3.4.2 Single Euro Payments Area (SEPA)

The Single Euro Payments Area (SEPA) is an initiative of the European Commission and the European Central Bank (ECB) to consolidate various national payment schemes into a EU-wide payment network. Its aim is to create a single, integrated euro payments market that does not dierentiate between domestic and international payments. SEPA is backed by the European Commission's Directive on Payment Services (DPS), which provides the legal foundation necessary for the creation of this payment scheme. Unlike other schemes that have been presented so far in this thesis, SEPA initiatives

50

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

Figure 3.7:

SEPA Core Direct Debit Scheme - Collections

are mature and have been actively adopted across the entire EU since 2008. It is expected that by the end of 2010 all EU banks will replace their national payment systems with SEPA compliant systems. While SEPA has been active for a number of years, it is only recently that its work became most relevant to this dissertation. In March 2009 the European Payments Council announced a

SEPA Direct Debit scheme (SDD), which aims to facilitate direct-debit transactions across national boundaries. The SDD consists of two separate schemes:

1. SEPA Core Direct Debit Scheme (CDD), and

2. SEPA Business to Business Direct Debit Scheme

In the following discussion only the rst scheme will be examined, as it is the most relevant to this dissertation. SEPA Core Direct Debit Scheme is a set of guidelines that dictate how direct debit transactions should be handled. It is based on ISO standards and is backed by legislative rules. These guidelines are specied in a SEPA rulebook EPC (2009). The major actors within a SEPA direct debit transaction are a creditor (i.e. merchant), a debtor (i.e. customer), a creditor's bank (i.e. acquirer) and a debtor's bank (i.e. issuer). A Clearing and Settlement Mechanism (CSM) is used as an intermediary between the creditor and the debtor bank for clearing funds. A single direct debit transaction in this scheme is referred to as a collection

Figure 3.7

illustrates the steps for processing of a single collection initiated by the creditor. It works as follows:

1. The creditor noties the debtor that it is about to initiate a collection. This step is optional and is at the discretion of the creditor.

51

3.4. Credit Card Security after SET

2. The creditor initiates a collection by sending a message to its bank. 3. The CSM is responsible for processing collections and making arrangements for settlement. Using a CSM, the creditor bank forwards a collection request to the debtor bank. 4. The debtor bank has control over the debtor accounts. As such, it is responsible for physically debiting the accounts. The debtor bank may reject collections if, for example, the debtor has instructed it to prohibit the use of an account for direct debit. While the above process follows the standard approach for handling direct debit transactions, the role of the SEPA scheme was to establish a set of common rules, practises and standards to facilitate a smoother movement of funds across national borders. The development of the new scheme was

deemed easier and faster than trying to integrate various existing national direct debit schemes into a single direct debit payment system. The way authorisation works within a SEPA compliant direct debit model also does not dier from the current approach used all over the world. A CDD scheme uses a mandate as a direct debit authorisation form. The EPC (2009) provides the following denition of a mandate:

The mandate is the expression of consent and authorisation given by the Debtor to the Creditor to allow such Creditor to initiate Collections for debiting the specied Debtor's account and to allow the Debtor Bank to comply with such instructions in accordance with the Rulebook. An e-Mandate is an electronic document which is created and signed in a secure manner.
The mandate is completed by the debtor and sent to the creditor during the initial, authorisation phase of the direct debit scheme. The creditor and the creditor's bank are responsible for storing this mandate (together with any amendments that apply to it) until it is either cancelled or lapses. It is forwarded to the debtor bank along with each collection and can be used as the basis for checking the validity of collections. It is clear that the SEPA Core Direct Debit scheme has the most resemblance to the work proposed in this dissertation. Not only does it solve the same problem but even the approach that it takes

mirrors the approach used in this thesis. This is promising as it demonstrates the relevance of this dissertation in the current commercial environment. It should be noted, however, that rather than being in competition with one another, the CDD scheme and the proposal made in this dissertation complement each another. The strength of SEPA is in its legislative foundation driven by the European governments and the European Central Bank, and its ISO standards compliance. In addition, because SEPA is restricted to

52

Chapter 3. Secure Electronic Transaction (SET) Literature and Technical Review

EU and the euro, this scheme is more focused as getting everyone on board within a closed environment such as EU is simpler than doing the same globally (which is something that this thesis had to consider). Even though the proposed solution in this thesis does not conform to ISO standards and is not backed by legislative rules it nonetheless oers superior ideas regarding security of direct debit transactions based on automatically enforceable policy (i.e. mandate) assertions. The SEPA CDD scheme at this stage does not handle electronic mandates (e-Mandate) at the same level of complexity as proposed in this thesis. The issuing and signing of e-Mandates is left unspecied in the rulebook

(see page 41 of EPC, 2009). This thesis, on the other hand, makes signicant contributions in this area proposing a robust scheme for both issuing and signing direct debit policies using cryptographic signatures. This scheme is backed by a prototype implementation that demonstrates how this can be achieved in practice. In addition, the content of SEPA mandates (paper or electronic) does not contain the same level of detail as proposed in this dissertation. This means that even once the issuing and signing of e-

Mandates are added to the CDD scheme it still will not be able to match the security oered by the proposed solution in this thesis. Unlike SEPA mandates, the periodical payment policies presented in this dissertation are capable of expressing any direct debit conditions, which makes them more useful in practice. Instead of simply being able to verify customer agreement to a direct debit, this dissertation makes it possible for each individual transaction to be validated against agreed conditions of the policy (e.g. the amount being charged, the date the transaction is being initiated, etc).

3.5 Summary
This chapter provided an overview of the most signicant commercial research and development eorts into electronic payments. It presented a SET standard, which was one of the earliest organised commercial attempts at solving security issues in electronic credit card payment processing applications. In addition to the general overview, a specic component of SET, instalment payments, was closely analysed as it directly competes with the work presented in this dissertation. Since SET has been abandoned, this chapter examined alternative technologies that have superseded it (i.e. Visa 3-D Secure and MasterCard SPA). These competing technologies are both trying to solve the same issues relating to credit card fraud online. The design of Visa 3-D Secure and

MasterCard SPA has a signicant impact on the way periodical payments can be implemented. Despite their ability to use strong, two-factor authentication via digital certicates, both protocols are

53

3.5. Summary

essentially session based. They provide no support for delegation and in fact require the customer to be physically present during every transaction. This is especially true with Visa, which does not even support credential caching. Using the current approach taken by both vendors it is not possible to implement periodical payments since this particular transaction type precludes customer participation after the initial credential exchange. Considering the usefulness of this payment type and its growing popularity (as evident from RBA, 2005; APCA, 2005) it is clear that a niche exists that has so far been overlooked by these major industry leaders. This chapter concludes with an overview of the SEPA Core Direct Debit scheme, which sets out guidelines for processing direct debit transactions across national boundaries within the European Union. Despite its maturity, however, there are areas of this scheme that can be improved. While the proposed solution in this thesis can benet from the standardised messaging introduced in the SEPA CDD rulebook and use its mechanisms for mandate amendments (an area not examined in this dissertation), SEPA could likewise benet from the superior techniques developed here for policy issuing and signing. In addition, the use of digital policies for validating direct debit transactions

proposed here is unique and an area that the SEPA scheme is weak in.

54

Chapter 4

Periodical Payment Framework Theory

This chapter presents the theoretical model for integrating X.509 restricted proxy certicates into an electronic payment application. Major components of this application such as the delegation of payment credentials and their use for initiating payment transactions are analysed. In addition, this chapter introduces a payment policy language specication. Detailed semantics of this language is

presented and a discussion of its possible use in a periodical payment framework follows. Unlike the SET specication that described a complete cardholder and merchant registration process, the periodical payment framework discussed in this chapter deals solely with payments. It assumes that cardholders and merchants will be issued with digital certicates separately, for example, when being issued new accounts such as credit cards. This makes this specication a lot simpler to describe and analyse.

4.1 Periodical Payment Process using X.509 Restricted Proxy Certicates

4.1.1 Overview
The complete periodical payment process is somewhat involved. Unlike the traditional model, which assumes immediate transfer of funds, periodical payments do not. Instead, this process works in a schedule-type framework, whereby the initial (and only) customer-merchant interaction simply

55

4.1. Periodical Payment Process using X.509 Restricted Proxy Certicates

establishes the terms of each scheduled transaction.

Before discussing the details of the periodical

payment framework it is important to understand this fundamental idea. The periodical payment policy is the core of the model. This policy is essentially an agreement, a contract between a customer and a merchant. The merchant promises to provide a customer with a service while the customer agrees to pay for that service on regular basis. This policy is essential to this process because it places restrictions on the delegated credentials that the customer must give the merchant so that all subsequent transactions can be performed without further customer intervention. The important qualities for the policy language that are of particular interest are its simplicity and exibility. It is envisaged that the contents of the payment policy would need to be presented to customers in a human-readable form so that manual validation could be performed. As such,

language simplicity is of the highest importance to ensure that customers can easily, visually inspect each periodical payment contract and understand it. While simplicity is of particular importance, language exibility is also crucial. The policy language must contain sucient expressiveness to describe most common periodical payment scenarios. For

example, when delegating credentials, it is most likely that customers would be interested in the following restrictions:

1. The merchant will only charge the customer account for services provided or to be provided to the customer.

2. The merchant will only charge the agreed xed amount or an amount within a specied range (e.g. anything under $200, etc).

3. The merchant will only charge the customer account once per agreed payment period.

4. The merchant will cease to charge the customer account upon completion of the contract or as soon as the service for which it was established is no longer provided.

5. The merchant will cease to charge the customer account on request, if this forms a part of their agreement.

It is clear how the above assertions could be used by a payment gateway to validate each transaction initiated by the merchant using customer-delegated credentials. Later in this section, it will be demonstrated how each of the above assertions can be easily expressed using an experimental policy assertion language (see section 4.2). For now, lets examine the two stages of the periodical payment process:

56

Chapter 4. Periodical Payment Framework - Theory

Figure 4.1:

X.509 Restricted Proxy Certicate Delegation

1. The delegation of the payment credential including signing of the policy document (see section 4.1.2), and

2. Initiation of a payment transaction, i.e. transfer of funds from a customer to a merchant account (see section 4.1.3)

4.1.2 Delegation Process

The delegation of a restricted proxy certicate is the rst step in the payment process and is the only one that involves the customer. It is based on the X.509 proxy certicate delegation specication dened in (Tuecke et al., 2004). The only major dierence to the original protocol is the enforcement

57

4.1. Periodical Payment Process using X.509 Restricted Proxy Certicates

of the certicate policy (i.e. periodical payment policy in this case), which is normally an optional extension of the certicate. This delegation process is depicted in Figure 4.1 and it works as follows:

1. Once the customer requests a periodical payment option, the merchant generates a new publicprivate key pair.

2. The merchant then creates a payment policy statement.

3. Using the key pair created in step 1, the merchant creates a restricted proxy certicate request. This request must conform to the specication described in (Tuecke et al., 2004). It will also contain the policy created in step 2.

4. The request is sent to the customer for consideration (i.e. the customer must process the request to examine the policy and to sign the certicate).

5. The customer veries that the proxy certicate request is valid. That is, the customer checks that all of its mandatory elds have been correctly set. Normally, the policy document is an optional eld, however, in this framework it is mandatory.

6. The customer must review and verify the terms of the policy document received from the merchant. This step is important as signing the certicate request binds the customer to the policy agreement. At this point, the customer can either try to renegotiate the terms of the policy, reject it or proceed with the next step.

7. The customer creates and signs the proxy certicate and sends it back to the merchant. Once the merchant receives the response, it can use the proxy certicate subject to its policy.

8. As a nal step, the merchant needs to validate the authenticity of the proxy certicate signature. This can be done locally by following the certicate chain to its root. The root certicate will most likely be well known, for example a Visa or a MasterCard certicate. In addition, the

merchant may also choose to check a certicate revocation list (CRL) hosted by its payment gateway or a similar third party service, however, this part is not specically addressed in this dissertation. Due to the nature of periodical payments, the above validation process is not quite sucient to ensure that the merchant obtains a completely usable certicate. Proxy certicates are likely to inherit life spans of their issuers and as such may not be valid for the full periodical payment period. Also, a malicious customer may attempt to circumvent this security protocol by setting

58

Chapter 4. Periodical Payment Framework - Theory

a short proxy certicate validity period. To ensure that this is not possible, the merchant must perform the following, additional checks:

(a) Ensure that the rst periodical payment is scheduled to be after the Not Before date attribute of the proxy certicate, and (b) Ensure that the proxy certicate will not expire until the last periodical payment is made, by checking its Not After date attribute

This additional validation will ensure that once obtained, proxy certicates will be usable for the entire periodical payment contract. Unfortunately, this particular approach is highly inexible and does not reect all possible payment scenarios. It breaks down for long-term contracts or contracts with undened end dates. As such, an additional feature for renewing proxy certicates is also needed (e.g. using a similar mechanism as in European DataGrid project, see Kouril,

2005). However, to limit the scope of this thesis this task is left for the future.

The nal step (step 8) of this process concludes with the merchant obtaining possession of a valid restricted proxy certicate which, when presented to a payment gateway, will enable it to transfer funds from the customer account to its own. The policy contained within this certicate is the artifact that is used by the payment gateway to make its decision whether to allow the transfer to proceed or to reject it. With the exception of the treatment of the policy within the certicate, the above process is exactly the same as the one outlined in (Tuecke et al., 2004).

4.1.3 Payment Process

Once the merchant has the proxy certicate the payment process is simple. The proxy certicate can be used for authentication to the payment gateway using the SSL/TLS protocol. Since the proxy certicate is simply an extended X.509 certicate no modication to the underlying protocol is needed. For this reason Figure 4.2 does not depict the authentication process nor does it demonstrate how the proxy certicate becomes accessible within the payment gateway context. It is merely assumed that it will be present post authentication process. The payment gateway depicted in Figure 4.2 hides complexity which is important to understand before discussing the payment process. The payment gateway is used to connect the merchant and its acquirer. The acquirer maintains a relationship with the merchant, which must be established

o-line before the merchant can use its services. In addition, the acquirer must be associated with one or more card brands (e.g. Visa or MasterCard) before it can process payment transactions. This

59

4.1. Periodical Payment Process using X.509 Restricted Proxy Certicates

Figure 4.2:

Single Payment Transaction Process

association with a credit card network allows the acquirer to validate customer credit card accounts and clear funds. In practice, payment gateway applications are often operated by acquirer organisations directly. However, this need not be the case. As such, the design of the periodical payment framework allows for third party organisations to operate as payment gateways. The Legacy Payment Gateway depicted in Figure 4.2 represents an existing interface between the merchant and its acquirer. Its back-end logic implements the functions that interact with the credit card network for processing payment transactions. To simplify the design of the periodical payment framework the new payment gateway reuses this existing interface instead of replacing it. Once the initial authentication process is completed the payment gateway performs the following tasks:

1. Extract the payment policy from the proxy certicate and determine whether the merchant's payment instruction is valid. That is, whether it conforms to the agreement made between it and its customer. For example, the payment gateway can check that the amount being charged is within agreed range of values. Unless this validation succeeds the payment gateway will reject this transaction.

60

Chapter 4. Periodical Payment Framework - Theory

2. Check a registry of cancellation requests received directly from customers. This is a mechanism by which a customer can asynchronously notify the payment gateway (which will then notify the merchant) of its intention to cancel a periodical payment agreement. The cancellation process is described in more detail in section 4.1.4.

3. Once authorisation process completes, the payment gateway is responsible for transforming the merchant's payment instruction into a format that a legacy payment application can process. This includes any legacy authentication credentials that may be required.

4. Before the payment gateway completes its processing and returns an acknowledgement message back to the merchant there is one nal step that it needs to perform. The process as it has been described so far has a signicant aw. Specically, the payment policy stored within the proxy certicate is not in itself sucient for the payment gateway to conclusively determine whether a transaction is valid. By only comparing it to the current payment instruction received from the merchant it is not possible to detect double charging. That is, the payment gateway can only verify whether the payment instructions match the policy but cannot say with any degree of certainty that the order is unique and has not been already processed previously. For example, how does the payment gateway determine whether it has already processed a transaction this month for a policy dictating a monthly payment period? In this case it cannot using solely the payment policy. As such, a new technique has been designed for solving this issue within the periodical payment framework. It is described in the next section.

4.1.3.1 Solving Double-Charging Problem

Clearly the double-charging problem as presented in the previous section is precisely the reason why a new periodical payment approach is being presented. It is one of the most important issues that the current direct debit model has failed to appropriately address. Using proxy certicates for payment authorisation, however, provides the periodical payment framework with various convenient ways of solving this problem. The simplest solution to this problem is for the payment gateway to record each transaction performed by the merchant. This log of transactions in combination with the certicate policy is sucient to determine whether an individual transaction is valid. The payment gateway must simply ensure that all assertions within the policy are met and that the merchant has not performed a transaction using this certicate in this payment period by checking the transaction logs. This solution, however, demands a great deal of the payment gateway. It is inecient to store records of all executed transactions and requires the payment gate-

61

4.1. Periodical Payment Process using X.509 Restricted Proxy Certicates

way to keep a signicant amount of session information. A closer analysis of this problem and of the payment policy use reveals that such detailed record keeping is not strictly necessary. The logs can be trimmed down to the last performed transaction with all previous records discarded for a particular certicate. The design for the logging mechanism proposed here is based on the concept of revocation, similar to certicate revocation lists (CRL) described in (Housley et al., 2002). Certicate revocation lists would normally be used to revoke the use of a certicate to prevent unauthorised parties gaining access to restricted information and services. However, in this case the whole certicate cannot be revoked simply because the merchant will be unable to initiate any more payment transactions using it. Instead, the payment gateway can use the payment period dened within the policy in combination with the current date to revoke the use of the certicate for the immediate payment period. For

example, given a monthly payment period, after processing a transaction the payment gateway would make an entry in the transaction revocation list (TRL) revoking the use of the presented certicate until the next month. Any attempt to use the same certicate twice within the same month would fail due to this entry in the list. There was one more alternative solution that was briey considered before TRL based approach was chosen. Since the payment policy language (see section 4.2 for details) can handle ne grained date-time restrictions, the use of stricter time-based conditions was examined. In this new approach, instead of merely specifying the allowed transaction dates, a time up to the minute/second condition was required. For example, a policy would dictate that a transaction must occur on the rst working day of every month at precisely nine o'clock. Using the delegated certicate at any other time would result in an error causing the transaction to be rejected. This approach removes all dependencies Each transaction

on the payment gateway to keep session state information between transactions.

could be validated using solely the payment policy making payment gateway servers more ecient. This works well in theory but unfortunately leaves no room for error, requiring merchants to be ultraecient in their payment processing. As such, it is unlikely to work in practice as the level of eciency required is unrealistic and would result in extremely brittle, unmaintainable applications.

4.1.4 Payment Cancellation Process

One important advantage of being able to electronically create and sign periodical payment policies is the ease with which such agreements can be cancelled when things go wrong. There are numerous reasons why policies may need to be cancelled. Due to long-term nature of these types of payments it is only natural to assume that customers may want to terminate agreements when their terms are

62

Chapter 4. Periodical Payment Framework - Theory

Figure 4.3:

Payment Certicate Cancellation Process

no longer suitable (e.g. merchant competitors are oering better deals for the same type of services, etc). The scheme presented in this and the following sections, was specically designed to allow for deliberate, non-malicious cancellation of policies. This is achieved by adding new policy assertions

that dictate when and how customers may cancel their policies and gives merchants the opportunity to declaratively specify any fees and charges that may apply in such cases.

In this section, the protocol for cancelling a policy will be presented followed by a discussion on various factors that aect how the payment gateway must deal with cancellation requests. Figure

4.3 depicts the process of cancelling a periodical payment certicate with its payment policy. There are numerous ways this can be implemented. Unlike the delegation and payment processes, which

are relatively easy to dene, the cancellation process most likely requires scrutiny from both nancial institutions and merchants alike. Figure 4.3 presents just one possible scenario how this can potentially work. The customer-side process can be described as follows:

63

4.1. Periodical Payment Process using X.509 Restricted Proxy Certicates

1. The customer must initiate this process by communicating directly with the payment gateway over an SSL encrypted channel. Its address must be encoded within the payment policy so that customers know how to contact it. This step involves the creation of the cancellation request that will be forwarded to the payment gateway. This request must contain the original, signed proxy certicate. The customer must use a certicate obtained from the issuer for SSL mutual authentication. This certicate must be the same as the one used for creating the merchant's proxy certicate. Having established a mutually authenticated SSL session, the customer proves possession of a private key linking its identity to the certicate. This assures the payment

gateway that it is dealing with a legitimate customer that originally established the periodical payment.

2. Before the payment gateway registers a cancellation request it must ensure that the customer's payment policy allows it. For this dissertation a simple approach was taken to determine this. A payment policy is considered cancellable if it matches the following two criteria:

(a) It declares a sub-policy, known as a cancellation policy, within the main body of the payment policy document, and (b) There is at least one assertion within this sub-policy that allows cancellation of the policy within the current processing period.

3. Even if the customer's request is valid and the policy can be cancelled, the payment gateway cannot do so straight away. Since this request is most likely to be received in a middle of Also, to simplify the

a payment period, the merchant is entitled to one more transaction.

protocol, the payment gateway never directly initiates contact with merchants. It is strictly a one-way relationship. As such, cancelling the certicate at this stage would deny the merchant of collecting any outstanding charges and cancellation fees, where applicable. Therefore, in

this step the payment gateway registers the customer's request in a cancellation registry to be processed next time that certicate is used.

4. Once the customer receives a successful registration acknowledgement message from the payment gateway no more customer intervention is required for the actual cancellation of the certicate to proceed. This will happen automatically once the merchant initiates the next payment transaction.

The merchant process can be described as follows:

64

Chapter 4. Periodical Payment Framework - Theory

1. The payment process from the merchant's perspective begins exactly the same as described in section 4.1.3. At this stage the merchant is unaware that the periodical payment agreement has been cancelled. As such, this rst payment instruction contains only the regular amount due.

2. When the payment request is received from the merchant, the payment gateway must check the validity of the proxy certicate used. One of the tests must include checking the cancellation request registry. A payment request will not be processed for certicates agged as registered for

cancellation. Instead, a notication message is returned to the merchant carrying information

about the customer's cancellation of the periodical payment agreement.

3. When a notication of pending cancellation message is received, the merchant can change the payment instruction to include any cancellation fees that may be applicable. Whatever fees are charged must be within the bounds of the payment policy agreement made between the customer and the merchant. Any attempt to circumvent this will result in a rejected transaction just like with any regular payment.

4. When the payment gateway receives the amended payment order it follows a somewhat similar process to what has already been presented in section 4.1.3. The only dierence is that a single transaction may contain two payment instructions for the regular payment and a cancellation fee. The payment gateway must ensure that both payment instructions conform to the policy agreement and reject the whole transaction if one or both of them fail.

5. Once the payment order has been processed, the payment gateway can nally revoke the proxy certicate. As soon as this occurs the merchant will no longer be able to use it to charge the customer and the periodical payment agreement is nally, permanently ended. The entry in the CRL must remain there for the outstanding duration of the periodical payment contract or the lifespan of the proxy certicate if the payment contract was open-ended. By keeping track of contract and/or certicate expiry the length of the CRL can be thus managed.

The above scheme makes a number of assumptions about how cancellation of periodical payments will be commonly used. These assumptions take the middle ground between exibility, functionality and simplicity of the protocol. For example, this scheme does not support immediate termination of contracts. This means that given a monthly payment period, a customer cannot suspend payments halfway through the month. In this case, this approach favours the merchant as it can collect more revenue before the contract is permanently cancelled. On the other hand, the merchant using this

scheme is not aware that a policy has been cancelled until an attempt to debit a customer is made.

65

4.2. Periodical Payment Policy Language

Attribute
currency amount limit on

Type
String (e.g. AUD, USD) Numeric (Decimal) Numeric (Decimal) CRON Expression

Mandatory
Yes No No Yes

Table 4.1:

XML <pay> element attributes

Furthermore, the merchant must react immediately when it receives a pending cancellation message, hence all its administrative tasks must be easily automated. This may not appeal to some merchants, for example, merchants whose customer retention strategies yield good results.

4.2 Periodical Payment Policy Language

The periodical payment policy used within the proxy certicate is the core of this payment framework. It is used to encode the contractual agreement between the customer and the merchant

and is subsequently used to verify legitimacy of each payment transaction. It is encoded as an XML document within the proxy certicate and generally declares one or more assertions that restrict the use of the certicate and the amount that a merchant can charge a customer. This policy language is dened using an XML Schema which is listed in its entirety in Appendix A. The syntax of the policy language is simple. The

<pay> element encapsulates most of the contrac-

tual information discussed in this thesis. In this one assertion it is possible to encode both the contract boundaries (i.e. begin and end dates) as well as the interval between each transaction. The attributes that can be set on the

<pay>

element are dened in Table 4.1.

The rst three attributes of the

<pay>

element are simple. They are designed for restricting the

amount that merchants can charge their customers. The

amount attribute, if used,

allows a merchant Alternatively, the

to dene a xed value that it can periodically debit from a customer's account.

limit

attribute can be used instead to dene a range of values up to and including the value of this

attribute. Both attributes are optional and if not included eectively give merchants permission to debit any amount from customers' account. The

currency

attribute is self-explanatory.

However,

unlike the previous two it is mandatory. This was done to eliminate any possibility of scams involving foreign currencies. The last attribute,

on, is the most complex.

Its value is represented by a CRON expression. CRON

is a utility commonly used on UNIX-like operating systems for scheduling batch jobs for execution at regular intervals. The exact syntax for this attribute was taken from a popular open source Java job

66

Chapter 4. Periodical Payment Framework - Theory

* seconds * minutes * hours * day of month * month * day of week * year

Table 4.2:

CRON expression format

scheduling service called Quartz (OpenSymphony, 2008). It enhances the original CRON expression syntax making it more ne-grained. For example, it is capable of specifying times up to a second

and allows a range of years to be entered which is something that is missing in the UNIX CRON syntax. Table 4.2 provides a brief description of the seven elds that constitute a valid Quartz CRON expression. A Quartz tutorial for its CronTrigger class (OpenSymphony, 2008) is the best reference for a complete listing of each eld and the types of values that it accepts (alternatively, see Appendix C for a summary). The only disadvantage of the CRON syntax is its complexity. Due to its concise format it is

not human-readable which is something that is of crucial importance within the periodical payment framework. It has already been established in this thesis that manual validation of policies is essential for customer signatures to be meaningful. As such, an ability to convert CRON expressions into a format that can be easily understood by consumers is needed. In the next chapter (section 5.1.2.1), a simple mechanism for converting CRON expressions into text descriptions will be presented that eectively solves this problem (see Figure 5.4). A typical periodical payment policy must contain a single one

<source-account> element and at least

<pay> element.

The

<source-account> element is used to dene the customer's account to which

access is granted. Its content is dependent on the type of account the customer wishes to use and cannot be generalised. For credit cards, this element could potentially contain such information as account name, card number, card verication value and expiry date. For regular Australian bank

accounts it would be the Bank, State, Branch (BSB) code and account number, and so on. To minimise the scope of this thesis, only one type of customer accounts was considered. Based on their popularity and widespread use on the Internet, credit cards were chosen to represent customer accounts within the periodical payment policy in this dissertation. A the

<creditcard>

sub-element of

<source-account> element was dened containing attributes listed in Table 4.3.

These attributes

represent the four most common values collected by merchants from their customers and constitute the minimal set of values required to successfully process payments. All four attributes should be The

self-explanatory as their denition and use directly reects current credit card usage.

expiry

attribute in this scenario will also most likely reect the expiry of the customer's certicate and as such it is added to the

<creditcard>

element for use by legacy applications (abstracted by the new

67

4.2. Periodical Payment Policy Language

Attribute
cardnumber cardholder expiry cvv

Type
Numeric (16 digits) String Date (month & year) Numeric (3 digits)

Mandatory
Yes Yes Yes Yes

Table 4.3:

XML <creditcard> element attributes

payment gateway) only.

It is envisaged that in the future the

<source-account>

element will be

extended to support other account types. For added security both the merchant and the payment gateway are identied within the periodical payment policy using their distinguished names as per their X.509 certicates. The element denes two attributes information.

<payment-policy>

merchant-dn

and

payment-gateway-dn

responsible for storing this

Using these attributes ensures that the merchant cannot change a payment gateway,

for example, to circumvent a cancelled policy because the policy is bound to a particular provider. In addition, binding the policy to a specic merchant ensures that even if a proxy certicate and its private key is compromised it cannot be used to initiate payments by another party. An example in Figure 4.4 denes a simple policy that allows a merchant to debit twenty dollars from a customer's credit card account. The CRON expression in the

on

attribute species precisely

when this transaction(s) can occur. Specically, it states that the merchant may initiate a transaction on the rst working day of every month in 2009. In addition, an optional

<description> element was

used in this policy to identify the service for which payment(s) are made. Its contents are free-text and are only there as a formality for o-line use (e.g. dispute resolution). As was described previously, a customer will receive this policy as part of a proxy certicate request generated by the merchant (see Figure 4.1). It is the customer's responsibility to check the terms of the agreement and if acceptable, sign the request thus creating a proxy certicate which is then returned to the merchant. In this example an implicit assumption is made that all transactions within the specied period will have the same monetary value. constant as well. In fact, it is assumed that the payment schedule will remain

That is, all transactions will be initiated on the rst business day of the month These assumptions are likely to be valid for a majority of cases, however, it is

without exception.

equally likely that merchants would demand some exibility to cope with special cases. For example, a merchant may want to oer its customers a discounted rst payment as incentive for choosing it over its competitors. To facilitate handling of odd transactions, the policy schema was extended to allow multiple

<pay>

elements to be used within a single policy document.

Having two or more

<pay>

assertions

68

Chapter 4. Periodical Payment Framework - Theory

<payment-policy merchant-dn=CN=Merchant,OU=ITEE,O=UNSW,ST=ACT,C=AU payment-gateway-dn=CN=PaymentGateway,OU=ITEE,O=UNSW,ST=ACT,C=AU> <description>payment for merchant services</description> <source-account> <creditcard cardnumber=0000000000000000 cvv=000 cardholder=Grigori Goldman expiry=2010-11 /> </source-account> <pay </payment-policy> currency=aud amount=20 on=* * * 1W * ? 2009 />

Figure 4.4:

Periodical payment policy example

within one policy, however, is problematic because it introduces ambiguity as to which one the payment gateway should validate against during payment processing. A merchant can use this exibility in

dening a periodical payment contract to overcharge its customers. To ensure that this is not possible, part of the policy validation logic also needs changing. When validating a policy, a customer and the payment gateway must check that

<pay>

assertions do not overlap over the same payment period.

Unless this condition is met, the policy should be considered ambiguous and rejected. An example in Figure 4.5 demonstrates the use of multiple transaction. The dierent values of the

<pay>

elements to dene an odd

on

attribute dene non-overlapping periods thus producing a

valid policy. The rst assertion declares a single payment of twenty dollars on the rst business day of January (i.e. rst month) in 2009. This is the discounted rst payment that was used as an example earlier. The second assertion is applicable to the rest of the year, dening payments from February through to December for a higher amount of fty dollars. From this example it is quite clear that regardless of the month during which a transaction is processed, only one of the two dened assertions will be applicable. Extending the payment schema and validation logic to dene multiple

<pay> elements is also useful

was

when solving issues with certicate cancellation. To allow merchants to specify restrictions on how and when customers may terminate their agreements another element introduced as a sub-element of the one or more

<cancellation-policy>

<payment-policy>. on
attribute.

The body of this element must also contain

<pay>

assertions that dene any cancellation fees that are applicable for a given period

as declared by the

<pay>

element's

By declaring multiple

<pay>

assertions within a

<cancellation-policy>
Figure 4.6.

allows merchants to change the amount of fees they charge depending on This is best illustrated by an example in

how long their customers stay committed to a contract.

69

4.2. Periodical Payment Policy Language

<payment-policy merchant-dn=CN=Merchant,OU=ITEE,O=UNSW,ST=ACT,C=AU payment-gateway-dn=CN=PaymentGateway,OU=ITEE,O=UNSW,ST=ACT,C=AU> <description>payment for merchant services</description> <source-account> <creditcard cardnumber=0000000000000000 cvv=000 cardholder=Grigori Goldman expiry=2010-11 /> </source-account> <pay <pay </payment-policy> currency=aud amount=20 on=* * * 1W 1 ? 2009 /> currency=aud amount=50 on=* * * 1W 2-12 ? 2009 />

Figure 4.5:

Periodical payment policy with two assertions example

<payment-policy merchant-dn=CN=Merchant,OU=ITEE,O=UNSW,ST=ACT,C=AU payment-gateway-dn=CN=PaymentGateway,OU=ITEE,O=UNSW,ST=ACT,C=AU> <description>payment for merchant services</description> <source-account> <creditcard cardnumber=0000000000000000 cvv=000 cardholder=Grigori Goldman expiry=2010-11 /> </source-account> <pay currency=aud amount=20 on=* * * 1W * ? 2009 /> <pay <pay currency=aud amount=100 on=* * * * 1-6 ? 2009 /> currency=aud amount=50 on=* * * * 7-12 ? 2009 /> <cancellation-policy url=https://host/axis2/services/PaymentCancellationService>

</cancellation-policy> </payment-policy>

Figure 4.6:

Periodical payment policy with cancellation example

In this policy cancellation example two

<pay> assertions are used to declare two distinct fee struc-

tures, which are dependent on when the customer terminates this agreement. Terminating this policy in the rst six months carries with it a higher fee of one hundred dollars while in the last six months this fee is halved. Furthermore, just like with the previous example (see Figure 4.5) both assertions apply to dierent time periods with no overlap. This is important as the same rules apply for the cancellation policies. Hence any ambiguity within this element causes the entire payment policy to be invalidated and rejected. Also notice the

url

attribute of the

<cancellation-policy>

element. This URL references the

payment gateway web service that can be used by the customer to cancel this periodical payment contract following the process outlined in Figure 4.3.

70

Chapter 4. Periodical Payment Framework - Theory

<payment-policy merchant-dn=CN=Merchant,OU=ITEE,O=UNSW,ST=ACT,C=AU payment-gateway-dn=CN=PaymentGateway,OU=ITEE,O=UNSW,ST=ACT,C=AU> <description>payment for utility services</description> <source-account> <creditcard cardnumber=0000000000000000 cvv=000 cardholder=Grigori Goldman expiry=2010-11 /> </source-account> <pay </payment-policy> currency=aud limit=500 on=* * * 1W */3 ? />

Figure 4.7:

Periodical payment policy with no termination date example

Finally, earlier in this chapter (section 4.1.2) it was discussed that there can potentially be policies that extend beyond the lifespan of the proxy certicates that represent them. situations, direct debit contracts are established for an indenite period. In many real-life

For example, for paying

utility bills (e.g. electricity, gas, telephone) using direct debit it is not possible or practical to dene an end-date. Such contracts are usually established without a termination date and can only be cancelled manually. Within a periodical payment framework these types of payments can be represented as

policies with

<pay>

assertions whose

on

attributes do not dene a year parameter (as this parameter

is optional). Such policies remain active as long as the proxy certicates that hold them are valid. An example in Figure 4.7 denes a periodical payment with an undened termination date. It

declares a quarterly payment of up to ve hundred dollars on the rst working day of every third month. Notice that the year parameter is not specied in the

on

attribute of the

<pay>

element.

As such, this policy will remain valid until the proxy certicate that holds it expires. Once a proxy certicate expires, it cannot be used to initiate more transactions despite the fact that the policy allows it. To x this a proxy certicate renewal service is required. This would allow merchants to renew certicates holding open-ended policies before they expire. However, to limit the scope of this thesis and in recognition that this problem is already being investigated, this task is left for the future (see Future Work section of Chapter 7 for a detailed discussion of possible solutions to this problem).

4.3 Summary
This chapter provided a detailed overview of the theoretical architecture for the periodical payment framework. It examined its three most signicant processes: 1). The delegation of payment credentials from customers to merchants using X.509 restricted proxy certicates, 2). The use of proxy certicates for initiating and processing periodical payments, and 3). The non-malicious customer cancellation of

71

4.3. Summary

existing policies. In addition, the complete language semantics of the policy language was presented with a number of real world examples describing its use. These are all of the components that are needed for constructing a working periodical payment framework. Its implementation will be discussed in the next chapter.

72

Chapter 5

Periodical Payment Framework Implementation

In the previous chapter a detailed overview of the theoretical model for the periodical payment framework was discussed. The aim of this chapter is to present a concrete implementation of that architecture as a working prototype. This solution consists of three distinct tiers:

1. Client-side browser plug-in implemented as a Mozilla Firefox extension/add-on,

2. Merchant payment processing service implemented as a J2EE web application,

3. Acquirer payment gateway web service implemented using the Apache Axis2 framework

From earlier discussions, the major aim during the development of this prototype was ensuring that the technologies utilised were stable, standards compliant and widely available. This was especially important when developing customer-side components, as they would be most aected by the lack of compatibility and support. Server-side components had their own set of unique issues despite the choice of technologies. The main problems encountered were security related as the claimed theoretical compatibility of various mechanisms did not translate into practice (e.g. using X.509 proxies instead of standard certicates). Just like any traditional integration project a signicant amount of time was dedicated to making these technologies work together in this new way.

73

5.1. Mozilla Firefox Browser Extension

5.1 Mozilla Firefox Browser Extension

5.1.1 Design Rationale
Using a browser extension to implement the client-side software needed for enabling proxy certicate delegation is a logical choice. Browser plug-ins and extensions are becoming increasingly common way of distributing custom software to Internet users. This trend is partially motivated by the growing popularity and development of the Mozilla Firefox browser. This browser is built on top of a mature, extensible framework that makes it simple (relatively) to dynamically extend its graphical user interface and behaviour. Other technologies such as standalone, downloadable applications and applets were also considered. However, in the past these technologies have not been popular with the end-users. Java applets in particular are generally considered bad practice within the industry and since the development and popularisation of Asynchronous JavaScript and XML (AJAX) technology the use of applets have become unnecessary for most use cases. Extending the default behaviour of the end-users' browsers at this stage seems like the safest approach with a high probability of success. The process of downloading and installing Firefox extensions in particular is quite streamlined, which will reduce the level of user resistance to this approach. Other browsers such as Microsoft's Internet Explorer, Google Chrome, Opera and Apple's Safari browser are all moving towards a similar open, extensible architecture, which enables third-party developers to extend the core browser functionality with new features.

5.1.2 Design Overview

The entire Firefox graphical user interface has been implemented using XML User Interface Language (XUL). This language allows developers to represent user interface widgets using predened XML elements. Each widget may be assigned one or more JavaScript action listeners, which are designed to capture user activity and perform various functions (e.g. capturing a user's action of clicking a button to trigger opening of a dialog window). Firefox uses a concept of XUL overlays to dynamically change existing XUL screens at run time. This concept can be used to change the look or the behaviour of an existing widget or add a new widget to an existing screen (also known as a master document). An overlay document is an XUL fragment whose contents are injected into the master document at a specied merge point. A merge point can be any Firefox widget that is already dened within the master document, for example, the status bar of the main Firefox window. An overlay must reference the desired merge point within the

74

Chapter 5. Periodical Payment Framework - Implementation

<?xml

version="1.0" encoding="UTF-8"?>

<?xml-stylesheet href="chrome://wdfclient/skin/overlay.css" type="text/css"?> <!DOCTYPE <overlay overlay SYSTEM "chrome://wdfclient/locale/wdfclient.dtd"> id="wdfclient-overlay" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <script type="application/x-javascript" src="overlay.js"/> <statusbarpanel class="statusbarpanel-menu-iconic" image="chrome://wdfclient/skin/wdfclient-icon-small.png"> <menupopup> <menuitem label="&wdfclient.menuitem.open;" oncommand="ProxyCertReqObserver .onMenuItemOpenCommand(event)"/> <menuseparator/> <menuitem label="&wdfclient.menuitem.options;" oncommand="ProxyCertReqObserver .onMenuItemOptionsCommand(event)"/> </menupopup> </statusbarpanel> </statusbar> </overlay>

<statusbar id="status-bar">

Figure 5.1:

XUL Overlay Example

document body using its unique identier. Figure 5.1 demonstrates how an overlay was used to add a panel to an existing Firefox status bar (alternatively, refer to Appendix G for complete examples of XUL use within this dissertation). This panel contains menu items required for manually launching X.509 Proxy Certicate Signing Tool and for opening a conguration dialog window. Notice the value of the

id

attribute of the

statusbar

element (i.e. status-bar). Its value is important as it identies an existing widget within the browser window making this element a merge point. Getting this value wrong creates a completely new status bar widget inside the main window, which is not the desired eect. The concept of overlays is quite powerful as it allows for non-intrusive injection of custom code into an existing application. Additional features are superimposed onto the existing code base without making any changes to it. Overlays and other Firefox technologies, such as Cross Platform Component Object Model (XPCOM) provide many more features but their discussion is out of scope for this thesis. discussion of these technologies refer to Mozilla Developer Center (Mozilla, 2009). For further

75

5.1. Mozilla Firefox Browser Extension

var

ProxyCertReqObserver = { observe: function(oHttp, aTopic, aData) { // //

}

launch proxy cert signing tool if HTTP response contains proxy cert request

Components.classes[@mozilla.org/observer-service;1] .getService(Components.interfaces.nsIObserverService) .addObserver(ProxyCertReqObserver,http-on-examine-response, false);

Figure 5.2:

Observer Service JavaScript Example

5.1.2.1 X.509 Proxy Certicate Signing Tool

Using overlays it was possible to extend a Firefox browser to become periodical payment HTTP response aware. A HTTP response observer is added to the browser's event model at run time to

lter HTTP responses carrying proxy certicate requests from the merchant application. This was done using one of many Firefox XPCOM services accessible via a JavaScript interface. For this task a

nsIObserverService

was used which allows client listeners implementing

nsIObserver

interface to

register to receive notications of various Firefox events. The Proxy Certicate Signing Tool overlay imports which denes a

overlay.js JavaScript (see line 6 of Figure 5.1)

This

ProxyCertReqObserver JavaScript object implementing nsIObserver interface. ProxyCertReqObserver

script also registers the

object using the observer service to receive HTTP

responses. The code extract in Figure 5.2 is an example of how this is implemented in practice. The

ProxyCertReqObserver object must implement an observe method as per the nsIObserver

interface which will be called by the observer service whenever it receives a notication for a topic that this object was registered for. This binding between the observer listener and a topic is made during observer registration using its

addObserver

method. From the above example it is clear that topic which processes

the certicate signing tool observer is bound to a all HTTP responses. Since the

http-on-examine-response

observe

method will be called for all HTTP responses, ltering logic is necessary to

only trigger execution of the certicate signing tool if a response contains a proxy certicate request message (not depicted in Figure 5.2). As such, the

ProxyCertReqObserver observer was implemented

to trigger opening of the proxy certicate signing tool dialog if a HTTP response matched the following conditions:

76

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.3:

HTTP Headers Response Example

1. The HTTP response status code is 401 (i.e. Unauthorized)

2. The HTTP response contains a header attribute tReq

WWW-Authenticate with a value of ProxyCer-

Normally, the standard HTTP response header attribute

WWW-Authenticate dened in (Franks et al.,

In this framework, this same attribute

1999) would be used in cases when accessing a remote protected object fails due to a missing or invalid entry in the HTTP request header attribute

Authorization.

is reused whenever a merchant application wants to request a new proxy certicate from a customer. Figure 5.3 depicts an example of a HTTP browser GET request followed by a HTTP response that contains a proxy certicate request received from a prototype merchant application running on a Jetty web server. The HTTP response matches both conditions presented above and as such will trigger opening of the Proxy Certicate Signing Tool. Notice how the contents of the

X-ProxyCertReq

header attribute contain only HTTP safe cha-

racters. This string is a base64 encoded proxy certicate request that will be decoded into its native binary format later (HTTP cannot transfer binary data necessitating this encoding/decoding step). Base64 decoding of the proxy certicate request occurs during initialisation of the signing tool

77

5.1. Mozilla Firefox Browser Extension

dialog window, as its contents need to be presented to a user.

For the prototype, this logic was While

implemented in Java using Bouncy Castle cryptographic Java API (BouncyCastle, 2009).

calling Java from a Firefox extension is not the most ecient approach, it was sucient to prove feasibility of this concept (see Appendix F for detailed discussion on how to integrate Java code into a Firefox extension implemented mostly in JavaScript). It remains an exercise for the future to change this code to use the preferred Firefox XPCOM services approach instead. At the time of writing there is at least one project that has already implemented necessary services that could be reused here (see Mazumdar & Dwivedi, 2007). Figure 5.4 provides an example of a base64 decoded proxy certicate request received from a test merchant application via a HTTP response header attribute

X-ProxyCertReq.

The most interesting

part of this screen is the Proxy Certicate Policy Info section. It presents the periodical payment policy (refer to section 4.2) in human readable form by parsing the raw XML document stored within the proxy certicate request and building a simple object tree model out of it. A lot more can be done to improve the readability of the policy to make it accessible to regular consumers but even this relatively simple example demonstrates what can be achieved with this policy language. The transformed policy is much easier to read than its raw XML equivalent which is depicted in Figure 5.5. In its native format the CRON expression is extremely exible in expressing various periodical payment scenarios but the same cannot be said for readability of its syntax. Presenting such expressions in their native format to customers is clearly not a good option. Fortunately, the set of allowed values in each CRON eld is restricted to a xed number. The meaning of these values does not change regardless of which eld they are used making translating their symbolic meaning into English phrases easier (see Appendix H for an example of a CRON expression transformer, specically

PolicyTreeView

JavaScript).

It has always been an assumption in this thesis that the nal validation of the periodical payment policy will be a manual process performed by the customer. It is ultimately customers' responsibility whether they choose to accept the terms under which the merchant will provide them with goods and services. This prototype provides a suciently easy to read transformation of the periodical payment policy for most customers to be able to understand each assertion. However, understanding the

meaning of each assertion in isolation is not enough to be able to understand the entire policy. Using multiple

<pay>

assertions within the same policy document adds an extra level of complexity making

comprehension of the policy document somewhat unintuitive. Deeper understanding of assertions and their eect on each other is needed to be able to form a clear picture of the contract. The current prototype does not suciently help with this issue. Its only attempt at policy vali-

78

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.4:

X.509 Proxy Certicate Signing Tool Example

79

5.1. Mozilla Firefox Browser Extension

Figure 5.5:

X.509 Proxy Certicate Signing Tool View XML Policy Example

80

Chapter 5. Periodical Payment Framework - Implementation

dation deals directly with checking the physical structure of the XML ensuring that all mandatory elements and attributes are present and contain valid values. To minimise its reliance on the Java code, this XML transformation and validation logic was implemented in JavaScript. This approach will ensure that migrating to an XPCOM implementation in the future will be easier. The validation logic is currently not using any DTD or XML Schema checking. Instead, all XML elements are checked programmatically with errors for each XML element recorded in a separate data structure so that they can be reported to the user via a status bar label (see Appendix H for the implementation details of the validation logic, specically

PolicyValidator

JavaScript).

For example, Figure 5.6 depicts a signing tool dialog window containing a periodical payment policy with two errors. The rst error is related to a missing element. The second error appearing in the last to a missing

currency

attribute of the second

<pay>

<pay>

element of the cancellation policy is related

on

attribute. This attribute is mandatory as it contains the CRON expression dictating

the conditions under which this assertion is valid. Also, notice how in this case the Sign Proxy Cert button is disabled. This will prevent a user from accidentally signing an invalid policy causing issues further on in the processing chain (i.e. at the payment gateway server which would reject this policy as being invalid). This type of validation is of course helpful at a certain basic level but cannot on its own assure customers complete understanding when they sign policies. Improving customer understanding of

these policies is not something that can be easily automated, however, signicant gains can be achieved by changing the way policy information is presented. It remains an exercise for the future to investigate more intuitive ways of rendering periodical payment policies to enhance general understanding of their overall meaning. It is envisaged that the best approach for this would be to conduct user-group sessions getting feedback directly from customers measuring their understanding of dierent policy representations just like this one. Beside presentation logic, the proxy certicate signing tool implements features for creating and signing proxy certicates using merchant requests and customer signature keys retrieved from a keystore. As was mentioned previously, this prototype add-on does not use any of the Firefox XPCOM services for managing user certicates and keystores. Instead, it must be congured to read a keystore le directly from disk extracting the signature key from it via Java code (i.e.

ProxyCertBuilder

class accessed via JavaScript, refer to Appendix H). Keystores are generally protected by passwords, hence this extension prompts the user for a password before opening the keystore le and extracting a signature key from it. Figure 5.7 demonstrates how this add-on can be congured to read signature keys from a le

81

5.1. Mozilla Firefox Browser Extension

Figure 5.6:

Error Example

82

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.7:

X.509 Proxy Certicate Signing Tool Conguration Example

based keystore. In this example, a Bouncy Castle Keystore (i.e.

*.bks)

le is chosen. Bouncy Castle which this extension also

keystore format is similar to the Sun keystore implementation (i.e. supports. Both formats can be used with the Java

*.jks),

keytool

command line utility.

This conguration dialog window is accessed via the Firefox status bar menu item injected there via an overlay (look for the second declaration of

<menuitem>

in Figure 5.1) or through the Firefox

Add-On manager. Unless congured with a valid keystore this extension will fail to generate proxy certicates when it receives proxy certicate requests from merchants. Once a customer is happy with the terms of the agreement and provided that the policy XML is valid, pressing the Sign Proxy Cert button initiates the nal step in this process. A dialog window prompting the user for a keystore password is opened which must be completed correctly before proxy certicate creation can begin (see Figure 5.8 for an example). There is only a thin layer of

JavaScript code in this step. It is responsible for opening the dialog window, accepting the password string and for passing all of the relevant information to the

ProxyCertBuilder

Java class, such as class denes

the keystore path, its password and the proxy certicate request. a method

ProxyCertBuilder

signProxyCert

implementing the logic for creating and signing a proxy certicate and

encoding it using base64 encoding scheme. It returns the base64 encoded proxy certicate, which is then forwarded to the merchant server via the HTTP method POST. The merchant application is congured to recognise proxy certicate carrying requests from customer machines based on two HTTP request header attributes:

Authorization

and

X-ProxyCert.

Figure 5.9 depicts a sample HTTP request sent by the proxy certicate signing tool extension and the corresponding HTTP response message received from the merchant server.

83

5.1. Mozilla Firefox Browser Extension

Figure 5.8:

Signing Proxy Certicate Example

84

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.9:
The rst attribute, et al., 1999).

HTTP Headers Request Example

Authorization,

is a standard HTTP request attribute dened in (Franks

This attribute is designed for carrying client's authentication information for the

realm of the resource being requested. It is commonly used directly as a result of receiving a 401 (Unauthorized) status code from the server, which is precisely how it is used in this framework as well. In this case, this attribute carries only a single value ProxyCert indicating to the merchant server that a user has accepted the terms of its agreement and has produced a signed proxy certicate. The actual proxy certicate payload, however, is stored in the second request attribute,

X-ProxyCert.

Specically, this custom attribute carries a base64 encoded proxy certicate produced by the certicate signing tool extension. Both attributes have to be correctly initialised for the merchant server to accept this request as a conrmation of the customer's acceptance of its terms. Once the proxy certicate is forwarded to the merchant server, the signing tool returns control to the main Firefox browser window and the user is forwarded to the next page in the merchant's payment workow, for example, a receipt/tax invoice screen. How the merchant uses the proxy certicate from this point is covered in detail in the next section.

85

5.2. Merchant Payment Processing J2EE Web Application

5.2 Merchant Payment Processing J2EE Web Application

5.2.1 Design Rationale
The last signicant attempt at introducing change into electronic commerce environment (i.e. SET, see Chapter 3) has failed due to the lack of support from merchants. It was costly to implement and required signicant infrastructural changes to make it work with existing e-commerce applications. As such, the aim of this merchant web application prototype was to ensure that periodical payments could be integrated into existing merchant applications with as little impact on the current procedures and processes as possible. Noting that some changes are unavoidable the aim was to minimise disruption as much as possible. The choice of Java 2 Enterprise Edition (J2EE) was motivated by its popularity and the numerous features that it provides for injecting additional functionality into applications without requiring any code changes. Specically, this prototype relies heavily on the J2EE interceptor servlet lter design pattern for implementing logic for obtaining proxy certicates from clients. An independent interceptor servlet lter can be congured into any existing Java-based merchant web application adding extra functionality without disrupting the existing merchant workow. Only minor changes are needed

thereafter for the merchant to take advantage of the work that is performed inside the lter (e.g. accessing proxy certicates from a keystore populated by the servlet lter during its authorisation process). More changes are needed to make merchant applications aware of the new payment gateway web service. This part is unfortunately unavoidable due to a lack of standardisation in this area. Current merchant applications use proprietary payment gateway services each one with a unique, proprietary transport and interface layers. Depending on how well the merchant application is designed, changes should only be required in the layer responsible for the payment instruction creation, dispatching and response processing (assuming proper abstraction was used when creating these services).

5.2.2 Design Overview

The merchant web application architecture consists of three distinct components:

1. Proxy Certicate HTTP Filter - responsible for negotiating with the client browser to receive a proxy certicate for use during payment processing.

2. Merchant J2EE Web Application - the core (possibly legacy) business logic of the merchant electronic commerce business.

86

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.10:

Merchant Web Application Architecture

3. Payment Gateway Web Service interface - wrappers around client-side stubs generated from payment gateway Web Services Denition Language (WSDL) for dispatching payment instructions and processing responses.

A high-level architecture of the merchant application is depicted in Figure 5.10. The following is a discussion of each component of this architecture.

5.2.2.1 Proxy Certicate HTTP Filter

The proxy certicate HTTP interceptor servlet lter is the most important component of the merchant's architecture as it is directly responsible for obtaining proxy certicates from clients. The choice of using an intercept lter in a J2EE environment is heavily inuenced by its independence from the application code. In fact, this lter was developed as a standalone component producing a Java Archive (JAR) that was later imported into the merchant web application as a dependency. Figure 5.11 adopted from (Sun, 2002) depicts a core J2EE servlet lter design pattern. This design pattern allows for pre-processing of HTTP requests before they reach their target by passing them through a collection (i.e. chain) of lter objects each one responsible for performing a particular task on it (e.g. logging, authentication, validation, etc). Both lters and the nal target component are (or should be) completely independent of each other and are wired declaratively into the web container via a conguration le (e.g.

web.xml)

rather than programmatically.

Using this design pattern in the context of a periodical payment framework is an attractive option as it allows for an addition of sophisticated business logic (such as obtaining proxy certicates from users) to existing merchant web applications without making any programmatic changes to them. The logic for obtaining a proxy certicate from a customer is completely encapsulated in the servlet lter ensuring that the current applications can continue to function unaware of this added feature (although some changes are required if the merchant applications are to take full advantage of this

87

5.2. Merchant Payment Processing J2EE Web Application

Figure 5.11:
added functionality).

HTTP Interceptor Filter Design Pattern

Figure 5.12 depicts a concrete implementation of the interceptor lter pattern. The message ow presented in this diagram is exactly the same as in Figure 5.10 except with slightly more detail. Specically, the ow of HTTP requests in this part of the framework can be described as follows: 1. Most HTTP requests directed towards the merchant web application are forwarded directly to their destination without going through the

ProxyCertHTTPFilter.

These are standard requests

generated as the user navigates through the merchant web site (1a, 1b). 2.

ProxyCertHTTPFilter

is congured to intercept requests directed towards a specic URL pat-

tern. This protected URL is congured via

web.xml and is expected to be reserved for initiating

the proxy certicate request process. Part of the merchant payment workow is to direct the user to this URL thus indirectly invoking this lter.

(a) The original HTTP request received by the

ProxyCertHTTPFilter

contains no security

information. Its purpose is to initiate this process. At this stage the request is blocked and is not allowed to continue to its destination (i.e. a page or action within the merchant web application). (b) A new proxy certicate request is generated and forwarded back to the client browser via a header attribute

X-ProxyCertReq

within the HTTP response message.

This step

involves creating a new public/private key pair and generating a proxy certicate request (see Section 4.1.2 for more detail).

88

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.12:

Proxy Certicate HTTP Filter

(c) A new proxy certicate generated via the Proxy Certicate Signing Tool is returned via a header attribute

X-ProxyCert

of a HTTP request. This proxy certicate is validated and

stored inside a keystore, which can then be accessed by the merchant web application when making payments. Currently, a le keystore is the only supported option, however, it is possible to extend this implementation to use alternative means of storing proxy certicates, e.g. Lightweight Directory Access Protocol (LDAP). For a production deployment, a proxy certicate store will be a component of the payment scheduling service that will not only store the certicates but will also schedule regular payment jobs according to the periodical payment policy inside each certicate (since there are plenty of job scheduling frameworks available, development of this is out of scope for this thesis).

3. Once a proxy certicate is obtained,

ProxyCertHTTPFilter

relinquishes control of the request

and it is forwarded to either the next lter in the chain (if there are any) and/or to the merchant web application.

4. Subsequent HTTP responses created by the merchant web application go straight to the client.

Earlier in this section it was stipulated that the

ProxyCertHTTPFileter could be declaratively congu-

red into an existing J2EE application without aecting its implementation. Figure 5.13 demonstrates how this was done for the prototype merchant application. The

<filter>

XML element denes the implementation class of the interceptor lter as well Specically, it includes a reference to

as all conguration parameters that it needs to do its job. a policy template le (i.e.

policy-template)

that is used to generate periodical payment policies

89

5.2. Merchant Payment Processing J2EE Web Application

inserted into proxy certicate requests. For the prototype this le contained the entire policy that was inserted into certicate requests unchanged, however, in a production system this le would contain placeholders for various parameters that can only be provided at run time (e.g. prices, contract dates, etc). Furthermore, as a future enhancement, this parameter should be extended to contain a list of templates for the lter to choose from based on usage context. The second parameter,

keystore, references a properties le found on the class path that denes a

keystore le and a keystore password that this lter will use to store proxy certicates it receives from clients together with their corresponding private keys. This part of the lter can also be extended if other keystore data sources are to be used instead of a simple le keystore. The following is an

example of a keystore properties le used for the prototype merchant web application:

KEY_STORE_TYPE=JKS KEY_STORE_FILE=C:\dev\keystore.jks KEY_STORE_PASSWORD=password

The next XML element in Figure 5.13,

<filter-mapping>, denes the URL pattern to match when

deciding whether to apply this lter or not (this task is performed by the servlet container, e.g. Jetty, Apache Tomcat, etc). The prototype merchant web application was designed to direct a customer to a URL containing a proxy keyword (e.g.

http://localhost/merchant/proxy/authenticated.jsp)
The resource at the end

whenever it wanted to obtain a new proxy certicate from a customer.

of this URL is protected in a sense that the user will only get to it if a valid proxy certicate is provided. As such, from this example, the contents of

authenticated.jsp

will only be returned to

the customer's browser if it gets past the lter, which will only happen if a proxy certicate is created and is successfully stored within the keystore le on the merchant's server. Complete reference implementation of the

ProxyCertHTTPFilter class is provided in Appendix I.

5.2.2.2 Merchant J2EE Web Application

The components of the periodical payment framework were designed with a specic goal of reducing the overhead required to integrate it into an existing electronic commerce application. Using an interceptor lter only partially achieves this goal, as changes are still needed for the merchant application to take advantage of the added functionality. Instead of calling a legacy payment gateway using its proprietary communication protocol and data structures, the merchant application must be changed to utilise the new payment gateway web services interface. The data structures required for calling this web service are also dierent and must be constructed by the merchant application as well. Fortunately, these changes should be conned to a single area of the merchant code and should not be

90

Chapter 5. Periodical Payment Framework - Implementation

<filter> <filter-name>ProxyCertHttpFilter</filter-name> <filter-class>au.gov.adfa.unsw.filter.ProxyCertHttpFilter</filter-class> <init-param> <param-name>policy-template</param-name> <param-value>policy.xml</param-name> </init-param> <init-param> <param-name>keystore</param-name> <param-value>keystore.properties</param-value> </init-param> </filter> <filter-mapping> <filter-name>ProxyCertHttpFilter</filter-name> <url-pattern>/proxy/*</url-pattern> </filter-mapping>

Figure 5.13:

Proxy Certicate HTTP Filter Conguration Example

dicult or expensive to change (although the amount of subsequent testing required is signicant). Alternatively, due to unique properties of periodical payments a new standalone service can be written (this can even be a generic, vendor product) that works independently of the merchant web application. Its purpose would be to schedule payment tasks and process them when required. This service can be congured into

ProxyCertHTTPFilter as a keystore data source.

This approach would

have a minimal (if any) impact on current merchant applications. As a proof of concept, the merchant web application used for this dissertation followed the rst approach and implemented all of the business logic necessary for processing periodical payments internally. Most of this logic was encapsulated in the

PaymentPorcessingService class, which served PaymentProcessingServiceStub) class. WSDL2Java utility

as a wrapper for the payment gateway web services stub (i.e.

This stub class was auto-generated directly from the payment gateway WSDL using

(this is a utility class developed by the Apache Axis2 that can generate web services client classes from a remote WSDL, e.g.

http://localhost/axis2/services/PaymentProcessingService?wsdl). processPayment,
the merchant payments processing servlet used

Using its sole public method,

PaymentProcessingService

to initiate transactions by creating instances of

PaymentInstruction

classes containing information about a single payment (e.g. amount, account to and from, description,

91

5.2. Merchant Payment Processing J2EE Web Application

Figure 5.14:
etc). The returned object,

Payment Processing Service Class Diagram

PaymentReceipt, would indicate a success or failure of this operation.

The

design of this part of the application is depicted in Figure 5.14. The

PaymentProcessingServiceSub

abstracts the communication layer between the merchant

application and the payment gateway. It relies on the standard Java implementation of HTTP (and SSL) to handle the physical communication between the two servers. Unfortunately, the default implementation of SSL (i.e.

javax.net.ssl.X509KeyManager and javax.net.ssl.SSLSocketFactory)

as developed by Sun has two signicant limitations:

1. It assumes that all HTTPS requests to a single, unique host will be authenticated using the same certicate from one (and only one) keystore. This eectively prevents the merchant from authenticating to the payment gateway using a proxy certicate of its choosing (i.e. based on which customer is being charged).

2. To enhance performance, it caches SSL sessions so that when establishing new physical connections to the same host it could reuse them without going through another SSL handshake. This is problematic, as the merchant must always go through the SSL handshake so that it could present the certicate relevant to the currently executing payment transaction.

Java provides an elegant mechanism for making new security providers accessible to Java applications without making programmatic changes to them. As such, it was possible to overcome these limitations by replacing the default security provider used by the merchant application with a custom implemen-

92

Chapter 5. Periodical Payment Framework - Implementation

tation that was aware of the need to create new SSL sessions per each SSL connection and using a certicate chosen by the application instead of selecting one automatically based on the public key type and the list of certicate issuer authorities recognised by the payment gateway (i.e. the standard approach, see Sun, 2008). The implementation of the security provider together with instructions on how to congure it, is described in Appendix D.

5.2.2.3 Payment Gateway Web Service Interface

As was already mentioned in section 5.2.2.2 the payment gateway web services interface is exposed to the merchant application via a wrapper class generated using the

PaymentProcessingService.

The stub classes auto-

WSDL2Java

Apache Axis2 utility include the following:

PaymentProcessingServiceStub

- This class encapsulates the necessary logic for marshaling

Java objects into a Simple Object Access Protocol (SOAP) request (represented by an inner class

ProcessPayment)

and transmitting them over a HTTP channel to the payment gateway.

It is also responsible for receiving responses from the payment gateway web service wrapped in a

ProcessPaymentResponse

class.

PaymentProcessingServiceStub.PaymentInstruction

- This inner class represents a simple

Java bean object that encapsulates payment order instructions from the merchant to the payment gateway. It contains such attributes as: to and from account numbers, amount, and transaction description.

PaymentProcessingServiceStub.PaymentReceipt - This inner class is also a simple Java bean

object. Its role is to carry information back from the payment gateway to the merchant, such as the success or failure of the payment transaction.

The WSDL from which the above classes are generated is included in Appendix B. This part of the periodical payment framework followed a standard approach for implementing web services and as such did not pose any conceptual or technical problems. For this prototype the web services denition was simplied to reduce the complexity of the implementation so that more time could be dedicated to other issues such as security. It is envisaged that for a production system, however, this complexity would have to be introduced back in to handle the various intricacies of real life situations.

93

5.3. Acquirer Payment Gateway Web Service

5.3 Acquirer Payment Gateway Web Service

5.3.1 Design Rationale
Using web services as an interface to the payment gateway application is a convenient choice. It is the most widely accepted technology for enhancing interoperability between disparate applications. This is especially important in the current electronic commerce environment in which there are a multitude of applications all developed using dierent programming languages. Considering that

most modern languages provide some support for web services it is therefore possible to get existing applications interacting with this payment gateway for a relatively low cost. So far, web services have been used in numerous commercial applications where decoupling of components and interface exibility is of particular importance. Unlike existing payment gateway

interfaces, web services abstract the client from the physical implementation of the service, which means that merchants will no longer require proprietary libraries supplied by the payment gateway providers to process transactions. They can build their own using the WSDL accessed directly from the payment gateway site. In recent years the term RESTful web services have gained popularity. These types of web services are based on an architectural style called Representational State Transfer (REST). Roy Fielding rst used this term in his Ph.D. dissertation (Fielding, 2000). Its aim is to simplify the web services stack by favouring common Web conventions over W3C-style standards. By minimising the feature stack (e.g. SOAP) these types of services are more ecient than using the traditional approach. However, as a starting point, this dissertation follows the traditional model of web service development leaving REST as a performance enhancement task for the future (if required).

5.3.2 Design Overview

For this dissertation, the Apache Axis2 open source engine was selected to provide the web services feature stack required. Axis2 has a mature, ecient architecture that is highly congurable. Web

services running on the Axis2 platform can be declaratively congured using XML les. The payment gateway presented in this thesis relies on this architecture to congure a security handler, which acts independently of the main payment gateway web service business logic. This design pattern enables separation of security related behaviour from the core business logic of processing payments ensuring loose coupling between various components of this application. As such, making changes to one of the components has no eect on the other. In fact, at one point for testing purposes, the proxy certicate validation was disabled with the payment processing service still functioning as per normal.

94

Chapter 5. Periodical Payment Framework - Implementation

Figure 5.15:

Payment Gateway Web Services High Level Architecture

Figure 5.15 depicts a high level architecture of the payment gateway web service deployed using the Axis2 engine. The focus of this diagram is on the components that had to be designed and implemented for this thesis. As such, a lot of the detail involved in actually conguring a fully functional web service is not included. In particular, the ins and outs of the InFlow and the OutFlow phases have been combined into two components: In Flow Modules and Out Flow Modules. In actual fact, each

of these components represent a sequence of phases that the SOAP request goes through before it reaches either the payment processing service (for the InFlow) or the merchant application (for the OutFlow). The only exception to this style was for the Proxy Certicate Policy Handler component. This component belongs in the InFlow security phase, however, since it was implemented as part of this dissertation it is depicted on its own instead of being bundled into the In Flow Modules component. To see how the proxy certicate policy handler ts into the overall Axis2 conguration and to get a better overview of the various phases that are available within the Axis2 engine refer to Figure 5.16. This gure depicts a fragment of a large conguration le used for initialising an instance of the Axis2 engine. Specically, it demonstrates some of the available phases and provides an example of how

the proxy certicate policy handler is congured into the Axis2 engine via its security phase. Notice how at this stage the actual web service implementing the payment processing logic is not congured. These two components are independent. This particular approach implies that the policy handler

will apply to any web service running within this particular instance of the Axis2 engine, as will be discussed later when the implementation class for this handler is presented (see Figure 5.18). Getting back to Figure 5.15, the process that it depicts can be described as follows:

95

5.3. Acquirer Payment Gateway Web Service

<phaseOrder type="InFlow"> <phase name="Transport"> <handler name="RequestURIBasedDispatcher" class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher"> <order phase="Transport"/>

</handler> <handler name="SOAPActionBasedDispatcher" class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher"> <order phase="Transport"/> </handler> </phase> <phase name="Addressing"> <handler name="AddressingBasedDispatcher" class="org.apache.axis2.dispatchers.AddressingBasedDispatcher"> <order phase="Addressing"/>

</handler> </phase> <phase name="Security"> <handler name="ProxyCertPolicyHandler" class="au.gov.adfa.unsw.ws.axis2.handlers.ProxyCertPolicyHandler"> <order phase="Security"/>

</handler> </phase> <phase <phase </phase> ... </phaseOrder> <phaseOrder type="OutFlow"> ... <phase <phase </phaseOrder> name="MessageOut"/> name="Security"/> name="PreDispatch"/> name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"> ...

Figure 5.16:

Fragment of axi2.xml conguration le

96

Chapter 5. Periodical Payment Framework - Implementation

1. The payment gateway web service was designed to be accessible via a HTTPS (i.e. HTTP over SSL) protocol. It relies on the fact that the merchant making the request will authenticate itself using a proxy certicate. By choosing to use HTTPS the merchant is forced to provide an X.509 certicate by the Apache Tomcat web server congured for mutual authentication. In this step, a HTTPS request carrying a SOAP message is sent over a secured channel and is received by the Tomcat SSL connector congured as per Figure 5.17. Notice the connector attribute

clientAuth=true.

This attribute tells the connector to request an X.509 certicate The received certicate is authenticated and the

from the caller during the SSL handshake.

request is allowed to proceed to its target (in this case a web service running within the Axis2 engine). Notice how Axis2 is just another web application deployed into the Tomcat container. Its resources (i.e. web services) are accessed in the same way as actions in any standard J2EE application. For example, the gateway's payment processing service is accessible via this URL:

https://localhost:9443/axis2/services/PaymentProcessingService

Also, note that the default HTTP connector does not have to be disabled to secure this web service. Any attempt to access the payment processing service via HTTP will fail validation

within the proxy certicate policy handler (step 3) when it tries to match the parameters of the payment instruction against the non-existent proxy certicate policy.

<Connector port="9443" SSLEnabled="true" minSpareThreads="200" maxSpareThreads="250" maxThreads="400" scheme="https" clientAuth="true" sslProtocol="TLS" secure="true" keystoreFile="conf/localhost.jks" keystorePass="password" truststoreFile="conf/localhost.jks" truststorePass="password"/>

Figure 5.17:

Tomcat SSL Connector Conguration (server.xml)

2. After the SSL handshake is completed the SOAP request is allowed to go through to the Axis2 engine. Once within the Axis2 realm this SOAP request is unwrapped from the HTTP request carrying it and processed using the various pre-processing handlers congured as per example in Figure 5.16. These handlers are an important component of the Axis2 engine architecture as they translate the raw SOAP request into an object model that can be easily manipulated in Java. For example, notice how the original HTTP request is converted into a

MessageContext

class used in step 3. This same technique is used when the framework eventually invokes the

97

5.3. Acquirer Payment Gateway Web Service

PaymentProcessingService PaymentInstruction

web service in step 4. At that point a

class

is used as an input parameter instead of its SOAP equivalent.

3. Once Axis2 engine reaches the security phase of the request pre-processing workow it will invoke the

ProxyCertPolicyHandler instance using its invoke method (see Figure 5.18). Handler

This class is

a custom implementation of a

interface responsible for validating the request against

the proxy certicate policy. In particular, this class assumes that if a

PaymentInstruction

is

found within the request than a corresponding proxy certicate with a valid policy must also be present (i.e. it assumes that the caller of the payment service authenticated using a proxy certicate). Considering that other web services may coexist within the same Axis2 engine not requiring policy validation this handler only performs its function if a object exists. In general, the functions that the be summarised as follows:

PaymentInstruction
class performs can

ProxyCertPolicyHandler

(a) Retrieve a (see

PaymentInstruction

instance from the

MessageContext

if it exists

getPaymentInstruction

method in Figure 5.18). exists retrieve an X.509 certicate chain used to

(b) Provided that a

PaymentInstruction

authenticate the caller to the web service. This information is available from the raw HTTP request accessible via the

MessageContext instance (see getCertificateChain method in

Figure 5.18). The rst certicate in the chain should always be the policy carrying proxy certicate. (c) The nal step in this process is to compare the payment instructions received from the merchant against the actual payment policy encoded inside the proxy certicate. Both the payment instruction as well as the actual date of the transaction (i.e. the current invocation date) must have a corresponding assertion within the policy allowing this transaction. For example, if a merchant attempts to debit $50 from a customer account there must be a

<pay>

assertion within the policy with either

amount=50
neither

or

limit=<number greater
or

than or equals to 50>

or empty assertion (i.e.

amount

limit

values are

specied). This same method must also ensure that this is a unique transaction and that the merchant is not attempting to double charge a customer using the transaction revocation list (TRL) rst described in section 4.1.3.1.

4. Eventually the Axis2 engine will invoke the

PaymentProcessingService using its processPayment

method (see Figure 5.19). For the prototype, this web service was built using the POJO (Plain

98

Chapter 5. Periodical Payment Framework - Implementation

public ...

class ProxyCertPolicyHandler extends AbstractHandler { public InvocationResponse invoke(MessageContext msgCtx) throws AxisFault { PaymentInstruction pi = getPaymentInstruction(msgCtx); if (pi != null) { X509Certificate[] chain = getCertificateChain(msgCtx); ProxyCertInfo certInfo = getProxyCertInfo(chain[0]); validate(pi, certInfo.getProxyPolicy());
}

return
}

InvocationResponse.CONTINUE;

private

PaymentInstruction getPaymentInstruction(MessageContext msgCtx) try { OMElement methodElement = msgCtx.getEnvelope().getBody() .getFirstElement(); Object[] params = BeanUtil.deserialize(methodElement, new Class[] { PaymentInstruction.class }, msgCtx .getAxisService().getObjectSupplier()); return (PaymentInstruction) params[0]; } catch (AxisFault af) { return null;
}

private

X509Certificate[] getCertificateChain(MessageContext msgCtx) { HttpServletRequest req = (HttpServletRequest) msgCtx .getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST); return (X509Certificate[]) req .getAttribute("javax.servlet.request.X509Certificate"); ProxyCertInfo getProxyCertInfo(X509Certificate cert) { // extract and return ProxyCertInfo from X.509 certificate void validate(PaymentInstruction paymentInstruction, ProxyPolicy proxyPolicy) { // compare proxy policy vs payment instruction, // e.g. proxyPolicy.amount == paymentInstruction.amount

private
}

private

}
}

Figure 5.18:

ProxyCertPolicyHandler class

99

5.3. Acquirer Payment Gateway Web Service

public

class PaymentProcessingService { ... public PaymentReceipt processPayment(PaymentInstruction paymentInstruction) { // call legacy payment gateway and get response PaymentReceipt paymentReceipt = new PaymentReceipt(); paymentReceipt.setId(generatePaymentReceiptId()); paymentReceipt.setPaymentGatewayId(PAYMENT_GATEWAY_ID); paymentReceipt.setPaymentInstruction(paymentInstruction); return paymentReceipt;

...
}

Figure 5.19:

PaymentProcessingService class

Old Java Object) approach. That is, the business logic for this web service was developed rst as a simple Java bean which was then converted into a SOAP web service through Axis2 conguration: engine:

services.xml

(see Figure 5.20). The

services.xml conguration le tells the Axis2

(a) Which

MessageReceiver

to use for making actual invocations on the web services impleIt is responsible for determining the

mentation class (i.e.

PaymentProcessingService).

required method to invoke through Java reection and then deserialising the input parameters from the SOAP message into Java objects. It is also responsible for serialising the output of the web service back to SOAP. (b) Which Java class to use as a web service implementation (see

<parameter name=ServiceClass>

in Figure 5.20). A message receiver uses this information to instantiate the required class and to invoke methods on it.

The actual business logic inside the

PaymentProcessingService class is somewhat limited.

For

testing purposes no integration with any existing legacy payment gateway was possible as such its only function is to generate a receipt message and return it back to the merchant. Notice how dening a web service using the POJO approach relieves the developer from having to construct a WSDL manually. The Axis2 engine generates the WSDL automatically whenever it is requested via a special URL query parameter:

wsdl.

For example, in step 1 the following

URL was used to access the payment gateway web service:

https://localhost:9443/axis2/services/PaymentProcessingService
100

Chapter 5. Periodical Payment Framework - Implementation

<service name="PaymentProcessingService" scope="application"> <description>Payment Gateway: Payment Processing Service</description> <messageReceivers> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver" /> </messageReceivers> <parameter name="ServiceClass"> au.gov.adfa.unsw.ws.service.PaymentProcessingService </parameter> </service>

Figure 5.20:

Axis2 Web Service Conguration (services.xml)

A similar URL can be used to retrieve just the WSDL for this service:

http://localhost:9090/axis2/services/PaymentProcessingService?wsdl
Note that beside the

wsdl

parameter the protocol has been changed as well. Instead of using

HTTPS, an unauthenticated request is made via HTTP. This is possible because (as was discussed in step 1) the HTTP connector was left enabled allowing unauthenticated access to some server resources.

5. As with the incoming messages, the outgoing responses wrapping the return value of the

processPayment

method (i.e.

PaymentReceipt)

go through various phases of the Axis2 en-

gine (see Figure 5.16). Just like with the InFlow security phase, a similar approach could be taken to inject additional functionality into the OutFlow security phase. For example, adding entries to the TRL could be done at this point. The logic for doing this is quite simple:

(a) Retrieve a

PaymentReceipt

instance from the

MessageContext

if it exists and check that

the transaction was successful. Only if it was, proceed to the next step. (b) Following the technique from Figure 5.18 extract the X.509 proxy certicate from the request and obtain a policy statement from it. (c) Add (or update) entry in the global TRL revoking the use of the proxy certicate for the period specied within its policy. For example, consider the following restriction:

on=* * * 1W * ?

2009

(i.e. on the 1st work day of every month in 2009)

101

5.3. Acquirer Payment Gateway Web Service

An entry in the TRL for the month of March would specify:

revoke=* * * 1W MAR ? 2009

(i.e. revoke the use of the certicate on the 1st work day of March in 2009)

This will eectively prevent the merchant from using the proxy certicate until the next month thus ensuring that the customer will only be charged once per payment period.

6. Leaving the connes of the Axis2 engine, the SOAP message is wrapped within the HTTP response and transferred to the merchant where a similar process of SOAP de-serialisation is performed to convert it into a Java object model.

Step 1 makes an assumption that the Tomcat server hosting the payment gateway application will be able to authenticate merchant requests based on provided proxy certicates during the SSL handshake. The SSL handshake process is generic and allows X.509 proxy certicates to be used instead of the standard X.509 certicates since both are structurally similar. However, the underlying Java implementation of the certicate chain validation logic as provided by Sun (i.e. class) does not support proxy certicates. Tomcat server are always rejected. The default certicate chain validation implementation makes the following assumptions about client certicates used for authentication:

javax.net.ssl.X509TrustManager

As such, proxy certicate authenticated requests to the

1. The end-entity certicate must be the rst and only end-entity certicate within the certicate chain, and

2. The end-entity certicate must be signed by a certicate authority (CA).

Unfortunately, proxy certicates break both of these conditions as they contain two end-entity certicates: the proxy and the certicate that signed it (i.e. issuer of the proxy certicate). One way to x this is to change customer certicates. By adding a CA basic constraint to their content each customer certicate becomes a CA certicate. Proxy certicates created using these modied customer certicates will adhere to the above rules making the default chain validation logic work (see Appendix E for an example). This technique was successfully used during the testing of the prototype. Whilst changing certicates is sucient for testing, this approach is inadequate as a long-term solution. As such, an alternative approach is hereby proposed. A similar problem has already been discussed in the context of the merchant application in the previous section. The solution in that case was to extend the default behaviour of the security

102

Chapter 5. Periodical Payment Framework - Implementation

X509KeyManager

provider, specically the

class.

The same approach is also needed here as well. class that needs customising. The

However, instead of the key manager, it is the

X509TrustManager

default certicate validation logic can be replaced with proxy certicate aware code. There are plenty of open source and commercial Java libraries that can validate proxy certicate chains (e.g. Grid

Security Infrastructure of the Globus toolkit). Alternatively, even writing this logic from scratch is not an issue as this process is well document in the X.509 Proxy Certicate specication (Tuecke et al., 2004). A possible implementation of the D (see section D.1.2).

X509TrustManager and related classes is described in Appendix

5.4 Summary
This chapter presented an overview of the implementation of the three major components of the periodical payment framework: 1). Firefox plug-in implementing Proxy Certicate Signing Tool, 2). Merchant J2EE web application, and 3). Acquirer payment gateway web service. All three components were developed using existing technologies and integrated together via a common transport protocol: HTTP. Beside the traditional implementation issues encountered during any multi-tiered application integration project, some problems were also discovered with the default Sun implementation of JSSE. Specically, issues with SSL session caching were found on the merchant side which caused problems for initiating multiple, uniquely authenticated SSL connections to a remote host (i.e. payment gateway) within a multi-threaded environment. Also, the default logic for selecting the right certicate from a keystore was also limited and did not allow the merchant to select a certicate based on the identity of the customer on whose behalf a payment transaction was initiated. As such, a lot of eort in implementing the merchant prototype was expanded on solving these issues via a custom security provider. Similar JSSE implementation issues were encountered at the payment gateway. While it was

possible for the merchant to use proxy certicates for authentication, the default JSSE implementation on the payment gateway web server considered such certicates invalid. Using a similar approach as the merchant web server, a custom security provider was needed that would implement a dierent certicate chain validation logic that would recognise proxy certicates as valid. Even though some tweaking of the various components were necessary, most of the implementation of these three components followed a standard process. All three were implemented using current,

103

5.4. Summary

standards compliant and industry supported technologies conforming to the industry best-practice. Its development was in line with the research hypothesis presented in Chapter 1 conrming that this solution is practical. The remaining thesis objective, the framework performance, will be discussed in detail in the next chapter.

104

Chapter 6

Performance Analysis
This chapter presents a detailed analysis of the performance of the periodical payment prototype discussed in the previous chapter. The focus of this analysis is on the impact of introducing SSL Some discussion on

mutual authentication using restricted proxy certicates into the framework.

using web services as a communication layer is also presented, although it is not the main focus here. The real challenge in analysing an online electronic payment application is in nding benchmark data to compare it with. Unfortunately, the current state of research in this eld is such that nding this information is dicult. None of the commercial companies that are active in this area publish their performance gures. As such, the data presented here and the conclusions made further on

are based on estimates of the likely transaction volumes that a payment gateway may reasonably be expected to process. These estimates have been derived through observation only and have been used solely as a starting point.

6.1 Test Methodology and Scope

A quantitative approach was chosen for testing the periodical payment prototype. This approach is the most logical choice given the lack of benchmark statistics to compare results with. Having

little reference data to start with, the aim of this exercise was to collect enough empirical data to make reasonable conclusions regarding its overall performance. It is reasonable to assume that other electronic payment applications can benet from the data collected here since many new applications are beginning to follow the same approach. For example, PayPal and Google Checkout are both

introducing web services over SSL although neither use mutual authentication. The testable architecture of the periodical payment system consists of three distinct tiers:

105

6.1. Test Methodology and Scope

1. The client side browser plug-in,

2. The merchant payment processing server, and

3. The acquirer payment gateway web service.

The major focus of this chapter is on the performance of the communication mechanism between the merchant server and the payment gateway. This part of the framework is considered to be more critical than the relatively low volume interactions between the client browser and the merchant server. This exchange is, of course, equally important; however, due to its infrequent use its performance is less likely to cause issues and impact its acceptance. The performance of the browser plug-in itself is less signicant as it is only used once during the credential delegation phase and is not involved in subsequent payment transaction processing. Considering that currently payment transactions over the Internet can, at times, take up to a minute, it is reasonable to assume that comparable performance for this application would be acceptable. Realistically, however, this extension is likely to perform in fraction of this time even on older platforms. For example, during testing it was observed that creating proxy certicates took approximately thirty seconds. This includes running JavaScript to extract HTTP request header parameters, launching

the JVM from within the Firefox extension, executing the Java code, returning control back to the calling JavaScript and nally sending a HTTP response message back to the merchant server. The performance can be improved by redeveloping this extension using a native XPCOM/C++ language. As such, the performance characteristics of the browser plug-in are not analysed in this thesis. When analysing the performance characteristics of the payment gateway service the key question that is of crucial importance is its overall capacity. That is, how many requests can the payment per second, per minute, etc). It is

gateway web service process for any given time interval (e.g.

important to include as part of this analysis not only the payment processing business logic (which in this case will be quite light) but also the SOAP message marshalling and un-marshalling process. It should be noted, however, that these individual components of the web service architecture are not by themselves of interest. It is in fact the combined eect of each component that will be analysed. In other words, performance data will not be collected for each individual sub-component of the web service. Instead, the overall time for processing a request will be recorded from the time the message arrives at the server to the time the response is returned. To be able to accurately measure the true impact of adding mutual authentication with restricted proxy certicates to the framework the same tests were executed with no SSL and with SSL serverside certicate authentication only. The test conguration with no SSL authentication is quite useful

106

Chapter 6. Performance Analysis

for establishing a baseline/benchmark to compare other results with. On the other hand, server-side certicate authentication test is needed since this form of authentication is prevalent on the Internet today. Comparing the results of these tests against the proposed solution should make it easy to

determine whether using certicate delegation for client-side authentication is a viable approach for solving the periodical payment problem. To eliminate the complexity of the real merchant server, which was implemented as a web application, it was necessary to develop a mock merchant server to simulate processing of payment transactions. Having this mock server simplies both the execution of tests and the collection of data. It removes unnecessary overheads added by the web container. In addition, using a mock server makes it a lot easier to recongure it to either use client-side certicates or not. Making this simplication does not impact the analysis presented later in this chapter since the measurements collected specically targeted the communication layer between the merchant and the payment gateway with the SSL protocol being the signicant focus of the discussion. Eliminating the additional overheads of the merchant application server meant that the extraction of useful measurements was easier. As was stated previously, the main objective of this testing exercise is to obtain information that could be used to determine whether this application would be able to cope with realistic transaction volumes. As such, each test run must simulate execution of multiple concurrent transactions. Even though the number of concurrent transactions in the test environment cannot be scaled to a realistic number, the results obtained can be used as a starting point with the rest of the data extrapolated to depict a realistic load. According to research hypothesis presented in Chapter 1 the performance impact on the server is expected to be linear (at least that is the desired behaviour). As such, a

linear extrapolation technique could be used to predict the behaviour of the server in a production environment.

6.2 Test Conguration

6.2.1 Computer and Network Conguration
The test environment was congured using a desktop computer running the payment gateway application and a Toshiba notebook executing the merchant software (see Table 6.1 for complete test hardware specication). Ethernet connection. These computers were networked directly with each other using 100Mbps

107

6.2. Test Conguration

PC
Merchant Payment Gateway

CPU
AMD Athlon 64 (3000+) 2.0 GHz Intel Pentium M 1.5GHz

RAM
1GB 512MB

OS
Windows XP Professional Windows XP Home

Table 6.1:

Test Machine Conguration

NAME
Java Apache Tomcat Apache Axis2

VERSION
1.6.0_02-ea 6.0.14 1.3

Table 6.2:

Software for Merchant and Payment Gateway Applications

6.2.2 Software Requirements

Table 6.2 presents the most important software packages used to execute both the merchant service and the payment gateway application. The Apache Tomcat servlet container and the Axis2 web

services engine are particularly important as they were used as containers for the payment gateway's payment processing web service.

6.2.3 Merchant Service Conguration

The mock merchant service performed the following actions during a test run:

Spawned 100 or 120 or 140 or 160 threads, each thread representing a payment gateway user (i.e. a unique merchant server that uses it as its acquirer),

Each merchant thread invoked the payment gateway web service 100 times simulating processing of its users' periodical payments,

All responses were validated to make sure that they are correct,

Execution times were logged to a log le. Note: the times recorded include obtaining a reference to the web service (done for every call), constructing the SOAP message, sending the message to the payment gateway, receiving a response and un-marshalling the response into a Java object.

Validating the response was not included in the calculation.

When testing SSL mutual authentication, each test was initialised with a set of pre-generated unique proxy certicates (16000 certicates in total) needed for client authentication. Unique certicates

were needed to ensure that the merchant or the payment gateway could not cache credentials and

108

Chapter 6. Performance Analysis

reuse them across multiple sessions.

Each certicate contained a unique distinguished name and a

policy whose amount value was also dierent to other policies within the test set. As discussed in section 5.2.2.2, a custom SSL socket factory was required to replace the standard factory provided by Sun. Normally, the behaviour of the standard socket factory of caching SSL

sessions is useful as it improves performance by reducing the number of times the SSL handshake is performed. Unfortunately, this feature breaks the periodical payment principles, as the merchant must use a dierent certicate for each individual connection to the server. As such, the new socket factory was needed to override the SSL session caching behaviour delivering a unique SSL session per socket connection. The use of a custom SSL socket factory was only needed when using mutual authentication. For other tests, the standard SSL socket factory implementation was sucient. When using the standard socket factory, the use of client-side certicates was disabled.

6.2.4 Payment Gateway Application Server Conguration

The payment gateway web service was instrumented to record the time when a message was rst received by the Axis2 engine to the time a response message was sent back to the mock merchant service. In total, up to 16000 incoming messages were expected, depending on which test was executed (i.e. 100 service requests times the number of threads: 100 or 120 or 140 or 160). In addition, the performance of the custom proxy certicate validation logic was separately logged, as this was the only signicant piece of functionality developed for this application with the rest being the framework code provided by Axis2 as standard. This code is also a likely candidate for containing performance problems as it requires processing of an X.509 proxy certicate, extracting the policy from it, parsing the policy using an XML parser and performing validation of the payment instructions against the policy rules. It should be noted that the payment gateway delegates SSL certicate authentication to the web server. An Apache Tomcat servlet container was used to host the payment gateway application. All tests described

Tomcat provides a variety of exible mechanisms for conguring SSL engines. below were executed using Tomcat's default SSL conguration. Socket Extension (JSSE) provider implementation.

That is, it uses Sun's Java Secure

While there are alternative providers for SSL

with faster implementations, JSSE was selected as a starting point to determine a benchmark to work from. It is recognised that for improved performance and scalability an alternative approach would be required. For example Apache Portable Runtime (APR) could be used to integrate OpenSSL (a much faster SSL library) with the server instead of the default Sun implementation. Alternatively, an SSL

109

6.3. Discussion of Test Results

hardware accelerator could be used to gain even further improvements in performance by performing all cryptographic operations solely in hardware. Tomcat was recongured for tests not requiring SSL by disabling its SSL connector. All information passing between the merchant and the payment gateway in these tests was in plain text. These tests were required to determine what eect authentication and channel encryption had on performance. Finally, Tomcat was recongured once more to enable server-side certicate authentication only. In these tests the communication between the merchant and the payment gateway was encrypted but the payment instructions were executed unveried (i.e. there were no payment policies to verify them against). This approach mimics the authentication paradigm currently used online for most payments.

6.3 Discussion of Test Results

6.3.1 Test Results and Analysis
In this section the test conditions and subsequent results are discussed in more detail. It includes three sections that describe the three payment gateway congurations under which the tests were executed. In particular, the following congurations were used:

1. Payment gateway service was congured with SSL disabled. Communication between the payment gateway service and the merchant was in plain text with no security at all. In addition, payment instructions received from the merchant were processed without validation (section 6.3.1.1).

2. Payment gateway service was recongured to allow the merchant application to execute web service methods using server-side certicate authentication only. Just like in the previous test conguration no validation of payment instructions was undertaken, however, all communication between the merchant and the payment gateway was encrypted (section 6.3.1.2).

3. Payment gateway service was recongured once more to require client-side certicates for authentication. This eectively forced the merchant to provide a proxy certicate when executing a payment transaction. In addition, the payment gateway was also able to validate payment

instructions using the policies retrieved from client certicates (section 6.3.1.3).

To validate consistency of test results and to ascertain payment gateway performance under load, each test was executed four times. Under each test conguration the payment gateway was subjected to loads of 100, 120, 140, and 160 concurrent connections producing in total 10000, 12000, 14000 and

110

Chapter 6. Performance Analysis

16000 requests. Unfortunately, it was not possible to broaden the spectrum of tests by increasing the number of concurrent threads (or the number of requests per thread) due to the limitations imposed by the hardware. Any attempts to increase the load on the payment gateway caused crashes of the JVM (on both the merchant and/or the payment gateway machines). It remains an exercise for the future to re-run these tests using more capable hardware, that better reects that likely to be used by merchants and payment gateways. For example, it is reasonable to expect payment gateway operators to run cluster servers with multi-CPU machines and large memory considering the expected number of transactions that they may be required to process per day. Alternatively, even upgrading the test PC to a newer model would be a step forward given the specications of modern machines with dual-core CPUs and memory of upto four gigabytes. Given such capable hardware, it is reasonable to expect better performance gures from the periodical payment framework.

6.3.1.1 SSL Disabled

It is reasonable to assume that adding SSL to the periodical payment framework will have a signicant impact on its performance regardless of whether it uses server-side only or mutual authentication. Not only is the cryptographic key exchange required before communication begins but also all sent messages must be encrypted. Before the impact of SSL on performance can be measured, however, a baseline needs to be established. This test conguration was designed to establish a benchmark for the performance of the periodical payment prototype unencumbered by the complexities of the SSL handshake and encryption. The outcome of running these tests in this server conguration is predictable. It is not surprising that increasing the load on the server by raising the number of concurrent threads communicating with it will have a detrimental impact on its performance. As the load on the payment gateway server increases, it takes marginally longer to execute each request. At this stage it is not important which part of the Axis2 web services framework is causing the most impact. That will be examined later in this chapter. For now, it is sucient to simply quantify the impact on performance by measuring the dierence in execution times between each test run.

Linear Correlation of Test Results

Due to the limited resources available for testing, linear correlation test must be made to ensure that increasing the load on the payment gateway does not exponentially reduce its capacity to process requests. Proving linear correlation is important in determining the likely behaviour of the payment gateway server under a more realistic load without actually replicating a real production environ-

111

6.3. Discussion of Test Results

Figure 6.1:

SSL Disabled: Average request processing time

ment. Considering that performance degradation is unavoidable, a linear impact on performance is an acceptable outcome. In conjunction with a linearity test, the gradient (i.e. slope) of the trend line must also be examined. The trend line gradient determines the rate with which performance degrades as the server is overloaded. The steeper the slope the greater the impact on the server. This information will provide an important insight later on when comparing the results of all three test congurations. It would be considered an ideal outcome if the trend line exhibits a gradual incline across all three test scenarios. Figure 6.1 demonstrates the impact on performance of the payment gateway server by plotting the average processing times for 100, 120, 140 and 160 simultaneous connections (i.e. merchant threads). Drawing a trend line across the graph gives a good, visual indication that performance degrades linearly as the number of connections rises. Linearity of the trend line can be substantiated using

the Pearson's Product Moment Correlation Coecient (PMCC). In this case, the PMCC of 0.9975 conrms an almost perfect linear relationship between the number of simultaneous connections and the server's performance. The equation used to derive this trend line,

y = 12.62x 93.1,

reveals that

each additional thread adds approximately 12 milliseconds to the total processing time of each request (for an in depth explanation of the PMCC test see McClave & Sincich, 2006). At this point it is dicult to judge the gradient of the trend line since there is nothing to compare it with. This will be done later in this chapter when the results of all three test congurations will

112

Chapter 6. Performance Analysis

Figure 6.2:
be compared.

SSL Disabled: Distribution of total request processing time

On their own, the results seem somewhat excessive considering the relatively small For example, the dierence in average processing This is a

increases in the number of concurrent threads.

times between 140 and 160 simultaneous connections is approximately 300 milliseconds.

signicant increase. It can only be attributed to either the internal implementation issues with the Axis2 web service framework or simply reaching the physical limitation of the test machines.

Volatility of Test Results

There is a signicant number of unique requests that are generated for each test. At its peak, the payment gateway server is forced to process 160 simultaneous requests (16000 in total). With such large number of requests it is important to determine how ecient the server is at processing each one. In theory, the time it takes to process a single request should not vary greatly. The greater the dispersion (i.e. spread) of the data, the more volatile the performance of the payment gateway server. Analysing distributions between all four sets of test results should yield a clear indication of how volatile the performance is under increasing load. It is to be expected that as the load on the server increases, the dispersion of the data grows as well. Ideally, the rate with which this occurs is slow proving that the server is stable and capable of handling the increasing load.

113

6.3. Discussion of Test Results

The box plot diagram in Figure 6.2 compares distributions between the four tests. As predicted it reveals that as the number of threads grows, the spread of the data does as well. Even within

the same test results set, the execution times between requests are volatile. These observations are substantiated by the inter-quartile range (IQR) gures. Containing 50% of all requests, the size of the IQR gives a good indication as to the actual spread of the data. For example, the mean for the initial test case with 100 threads, is 1170 milliseconds. However, there are plenty of requests within this IQR that were processed much faster (around 500 milliseconds as per the 25th percentile) or much slower (just under 2 seconds as per the 75th percentile). Other test sets follow a similar pattern as well. Of course, as with any large sampling of data some points will appear to be unreasonably distant from the mean. These points are depicted in Figure 6.2 as outliers. The upper outliers demonstrate the extreme scenarios in which the server took an abnormally long time to process requests. As will be explained later, these observations help to identify instances when the server redirects its resources to other tasks that are indirectly aecting request processing (e.g. allocation of memory, initialisation of threads, etc). The lower outliers likewise provide insight into how the server behaves when it is at its best. The reasons for these observations are also discussed later revealing what happens when the load on the server drops. The statistical distribution in Figure 6.2 represents an ever increasing positive skew. With each additional thread the volatility of the server increases as the execution times are spread over a larger time frame. This has the eect of attening the distribution curve as the server is overloaded. The reasons for such high levels of variance are dicult to isolate. explanations. For example: There are several possible

JVM garbage collection can explain some of the variation in performance of individual requests. This may equally apply to both the payment gateway and the merchant service.

Merchant service may also experience performance degradation as the number of threads it needs to execute concurrently increases. This is a likely scenario since this service was deployed on a machine with limited RAM and CPU resources.

Consistency of Test Executions

So far it has been established that increasing the number of simultaneous connections to the payment gateway has a linear correlation to its ability to process requests. Furthermore, as it is

loaded, processing of individual requests within a consistent time frame is also aected producing the high volatility described in the previous section. What is needed is proof that within a single test run

114

Chapter 6. Performance Analysis

Figure 6.3:

SSL Disabled: Average processing time by segments of 1000 requests

the payment gateway remains stable. Proving stability of the server under a constant load mitigates the volatility of data at the individual request level, making volatility less signicant at the application layer (i.e. less likely to cause problems in a real production environment). A timeline chart in Figure 6.3 depicts average request processing times grouped by 1000 requests. By excluding the rst and the last point of each line, for the moment, it is clear that within each series, the payment gateway behaves in a consistent and stable manner. This means that under a

constant load the server is capable of processing requests quickly enough without overlling request queues, which would eventually cause poor performance as the queue backlog increases. Clearly, as the number of threads grows so do the request processing times, as the server has to simultaneously handle more requests. This coincidentally, supports the previous point on increased volatility as evident through the standard deviation trend in Figure 6.1 and the distribution of Figure 6.2. However, despite lowering of performance as extra threads are added, the stability of the server is never impacted. The rst and the last points in each series in Figure 6.3 are signicantly dierent to the majority of points plotted on the chart. This variation at those particular points is not surprising and can be easily explained. For example, at the start it is expected that the system would take longer to process requests due to the sudden inux of incoming requests. This additional time can be attributed to

memory and thread pool allocation and other initialisation procedures. Naturally, once these once-o tasks are completed the performance stabilises.

115

6.3. Discussion of Test Results

Alternatively, the last point in each series is signicantly lower than the others.

This can be

explained by the decrease in the load on the server as the merchant service completes its payments processing cycle. This point is further skewed as the number of requests nears parity with the number of concurrent threads. Since there are no new requests coming in, the last bundle of requests will be signicantly quicker. As each request is completed, the remaining requests should be faster since all of payment gateway buers, memory and other resources become available and the load on the machine drops.

6.3.1.2 SSL with Server-Side Certicate Authentication only

SSL specication denes the use of server certicates as mandatory and client certicates as optional. This means that it is only servers that are required to present their certicates in order to establish SSL sessions with client applications. Due to the immature state of public key infrastructure this is the way SSL has been used over the Internet since its inception. It is rare to nd use of client certicates in the public domain. This test conguration aims to mimic the current use of SSL on the Internet. As such, the payment gateway was congured to use its certicate for establishing SSL sessions with the merchant service. The merchant service, however, was not required to present its certicate during the SSL handshake. As such, all merchant requests under this test conguration were processed unauthenticated. Payment instructions received from the merchant threads could not be validated as well because there were no policy-carrying proxy certicates to verify them against. This is not an issue as it was discovered

that, against expectation, validation of payment instructions was disproportionally faster than the overall request processing measurements. For example, on average, validation was adding less than 40 milliseconds to each request while the total request processing time was measured in seconds. It is expected that the behaviour of the payment gateway using this conguration should not deviate from the pattern established in the previous section. Linear performance degradation with increasing dispersion as the number of threads grows is considered acceptable. Slightly elevated

performance gures are to be expected since the merchant and the payment gateway are required to exchange cryptographic keys and then encrypt all requests and responses. The question is, what is the impact of adding these extra steps to the periodical payment process?

Linear Correlation of Test Results

Linear correlation between the number of threads simultaneously connecting to the payment gateway and its performance has already been established in the previous section. This test aims to verify

116

Chapter 6. Performance Analysis

Figure 6.4:

SSL: Average request processing time

that adding the SSL handshake and the encryption of the communication link does not adversely aect this correlation. That is, while the impact on performance is expected, it should still be linearly related to the number of simultaneous connections. The gradient of the trend line, however, is more dicult to predict. Due to a more complicated processing life cycle it is possible for the performance to degrade faster. This would be reected by a steeper trend line and higher execution times of each request, per each additional thread. The

dierence between the rate of increase under this test conguration and the previous one should just be that extra processing time required by SSL. This can be proved by isolating and measuring the performance of the SSL component of the protocol thus establishing its contribution towards the total request processing times. The average request processing times for all four tests within this test conguration are plotted in Figure 6.4. As predicted, the behaviour of the payment gateway server is unchanged in relation to its ability to process requests as the number of concurrent threads grows. The trend line pro-

vides a reasonable, visual, indication that this correlation is linear. Just like under the previous test conguration, the Pearson's Product Moment Correlation Coecient (PMCC) of 0.9877 once again conrms a strong linear correlation between the number of simultaneous connections and the server's performance decay. The equation used to derive the trend line can be used to quantify the impact that additional

117

6.3. Discussion of Test Results

Figure 6.5:

SSL: SSL handshake average processing time

simultaneous connections have on the payment gateway server. This equation,

y = 27.64x 354.7,

reveals that each additional thread is adding 27 milliseconds to the execution time of each request. This value more than doubles the observed measurements from the previous test conguration that recorded 12 milliseconds per additional thread (see Figure 6.1). This has the eect of increasing the gradient of the trend line on the graph. In the context of this thesis, the measurements for the rate of increase in request processing times are not as important as determining what contribution the SSL handshake makes to these gures. The proposed solution is hinged on SSL behaving in a consistent and stable manner without adversely impacting the performance of the payment gateway. Considering that the SSL protocol contains

expensive operations that require substantial allocation of system resources it is reasonable to assume that some of the responsibility for the increased rate of decay can be attributed to it. Figure 6.5 presents average times for completing an SSL handshake. Just like the total mea-

surements, there is a strong indication of linear correlation between the number of simultaneous connections and the time it takes to establish an SSL session for each one. The PMCC value of 0.9879 corroborates these ndings. The equation of the trend line,

y = 16.37x + 579.4,

demonstrates that 16 milliseconds are added

to the SSL handshake for each addition thread.

Removing this gure from the total value of 27

milliseconds leaves only 11 milliseconds remaining, which is almost identical to the previous test

118

Chapter 6. Performance Analysis

conguration result of 12 milliseconds. This indicates that SSL is in fact a major contributor impacting performance as the number concurrent threads grows. It is adding over 50% to the processing times per each additional thread. However, this is not as signicant as it appears. Considering that the request processing times are measured in seconds (e.g. 2.5 seconds for the initial test with 100 threads), adding 16 milliseconds to these times is unlikely to be of signicant concern in a real production environment.

Volatility of Test Results

Increasing the amount of work that the payment gateway has to perform for each request can signicantly impact its ability to process requests in a consistent manner. Checking the dispersion of the data to measure volatility can increase condence in the results of this analysis. That is, the less volatile the data the easier it is to make reasonable conclusions about the performance of the payment gateway. On the other hand, increased spread introduces a higher degree of doubt making it more dicult to make concrete conclusions. The previous section has already conrmed that there is some volatility in the way the payment gateway processes requests. Analysing the distribution of the performance data for this test conguration should ideally provide good indication of how well the server is coping with the increased load (as before) and how much of the overall volatility can be attributed to SSL. The dispersion of the SSL handshake processing times is of particular importance as it is directly relevant to the solution proposed in this dissertation. It is no coincidence that this section focuses on increasing load and SSL authentication as primary variables for analysing variance. The analysis so far points to a strong relationship between the number of concurrent threads, the authentication method and the performance of the payment gateway. This relationship is best quantied using multiple regression analysis (McClave & Sincich, 2006). The results of a multiple regression test comparing the data from the previous section (i.e. no authentication) and this one (i.e. server certicate authentication) are presented in Appendix J (see Table J.1). These results conrm that at 99% condence interval both predictor variables (i.e. the authentication method and the number of concurrent threads) are inuencing the criterion variable (i.e. request

execution time). In other words, varying either variable has a direct impact on performance of the payment gateway. As such, examining dispersion of the data in relation to these predictor variables should yield meaningful results. Figure 6.6 plots the distribution of total request processing times on a box plot diagram. By

comparing the IQR of all fours tests against the results of the previous test conguration (see Figure 6.2) it is clear that the spread of the data has decreased. This means that during this test run the

119

6.3. Discussion of Test Results

Figure 6.6:

SSL: Distribution of total request processing time

payment gateway was more consistent in processing individual requests than before. For example, for the initial test with 100 threads, 50% of all requests were processed between 2293 (1st quartile) and 2644 (3rd quartile) milliseconds, the dierence of only 351 milliseconds. This is smaller than before with values ranging from 440 and 1752 milliseconds, the dierence of 1312 milliseconds. On average, the IQR dierence across the four tests was only 814 milliseconds versus 1858 milliseconds obtained during the previous test run. The reduced dispersion of the results is further substantiated by the standard deviation measurements depicted in Figure 6.4. Standard deviation for non-SSL tests was much higher than what was observed here thus conrming the tighter grouping of data around the mean. This distribution still remains positively skewed, it is just not as at as it was before. The reduction in dispersion of the data helps to conrm that the payment gateway is capable of handling increased load. The next step is to check whether the distribution of SSL handshake

processing times follow the same pattern. Figure 6.7 plots this distribution on a box plot diagram. The dierence between this distribution and the total is marginal with the IQR dierence of only 773 versus 814 milliseconds. overall dispersion. This means that the SSL handshake is contributing equally to the

This is important as it helps to conrm that this part of the application is not

adversely aecting server's ability to process requests. That is, the server is capable of processing SSL

120

Chapter 6. Performance Analysis

Figure 6.7:

SSL: Distribution of SSL handshake processing time

handshakes in the same consistent and stable manner as it processes the requests themselves.

Consistency of Test Executions

Linear correlation and volatility analysis provide only a high-level overview of the behaviour of the payment gateway server under load. Its ability to process requests within a consistent time frame within each test run (i.e. its stability) is also important. Due to the involvement of the SSL handshake, the results of these tests can be analysed in the context of:

1. Server's ability to establish SSL sessions with the merchant service, within one test run and under increasing load, and

2. Server's ability to process payment requests sent over an encrypted communication channel, within one test run and under increasing load.

Furthermore, close scrutiny is required to quantify what contribution SSL handshake is making towards the total request processing time. So far, it has been established that it does have inuence over the server's ability to handle increasing loads. However, the question is what is its inuence in the context of a single test run or even in the context of an individual request?

121

6.3. Discussion of Test Results

Figure 6.8:

SSL: Average processing time by segments of 1000 requests

A timeline chart in Figure 6.8 depicts average request processing times grouped by 1000 requests. It is not surprising that it exhibits the same characteristics as results from the previous test conguration (see Figure 6.3). It proves that for a single test run, the behaviour of the payment gateway is stable as it is capable of processing requests within a consistent time frame. For example, for the initial test with 100 threads, the variation between individual points is less than 100 milliseconds (excluding the rst and the last points as before). Other tests follow the same trend proving that any volatility in the data described previously is manageable. This is important as it demonstrates that given a constant load the payment gateway server is capable of handling its workload without losing eciency over time. Isolating the SSL handshake process from the above diagram reveals the same consistent behaviour (see Figure 6.9). Within each series it is clear that the performance of the SSL handshake is stable. The variation from point to point is relatively low. As before, increasing the number of concurrent threads leads to performance degradation. As more resources become unavailable new handshakes

have to compete for them with other threads. By comparing these diagrams it is quite obvious that SSL plays a signicant role in the overall request processing time. Figure 6.10 attempts to quantify this contribution by plotting the times

spent establishing SSL contexts as a percentage of the total request processing time. This diagram proves that SSL is the biggest contributor, with 70 to 90 percent of the total time spent on SSL

122

Chapter 6. Performance Analysis

Figure 6.9:

SSL: Average SSL handshake by segments of 1000 requests

handshake. However, notice what eect increasing the number of simultaneous connections has on SSL's contribution to the total time. Instead of remaining at the same level or rising it is actually falling as the server is overloaded. This means that there is something else beside SSL that is impacting on the server's performance. One likely candidate is the Axis2 web services engine. It is the biggest and the most complicated component of the periodical payment framework and so far has been treated as a black box. Alternatively, some of the responsibility can be attributed to the lack of physical resources (e.g. RAM), however, it is less likely to be the root cause in this case. At this stage, analysing Axis2 framework to accurately determine its contribution is outside of the scope of this thesis.

6.3.1.3 SSL with Mutual Authentication

The tests executed leading up to this section have been necessary to establish a baseline of measurements so that the tests here could be appropriately analysed. Mutual authentication is the basis of the periodical payment framework without which the entire solution does not work. Proving that adding client certicate authentication does not adversely aect the performance of the payment gateway server is paramount. Clearly, some impact on performance is to be expected due to the increased workload of exchanging and validating client certicates. However, it is expected that the behaviour of the system will continue to follow the established trend. That is, linear decay in performance with stable and consistent processing times under a constant load. Volatility of the server remains the

123

6.3. Discussion of Test Results

Figure 6.10:

SSL: SSL handshake percentage of total time

only unpredictable factor, however, by isolating the SSL handshake (the only part of interest in the context of this discussion) reasonable conclusions can still be made as to the eectiveness of using mutual authentication as a solution for the periodical payment problem. For this test, a merchant service used pre-generated proxy certicates to authenticate itself to the payment gateway web service. The contents of the payment policy used within each proxy certicate are depicted in Figure 6.11. This policy is approximately 500 bytes long depending on the value of the amount attribute. Just like the distinguished name (DN) of the proxy certicate, the value of the amount attribute is also unique to ensure that policies are not cached (i.e. the  {0} placeholder was dynamically replaced with a value during certicate creation). Also, because each policy is dierent any attempt by the merchant service to reuse a certicate (e.g. due to thread synchronisation issues) is immediately detectable. This feature assures the correctness of the data collected from these tests. The time-based constraint of the payment policy is not relevant in this case because it gives the merchant permissions to debit customer accounts at any time. This was done to ensure that tests can be re-run without requiring changes to the proxy certicates used for authentication.

124

Chapter 6. Performance Analysis

<?xml

version="1.0" encoding="UTF-8"?>

<payment-policy xmlns="policy.unsw.adfa.gov.au" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="policy.xsd"

merchant-dn=CN=Merchant,OU=ITEE,O=UNSW,ST=ACT,C=AU payment-gateway-dn=CN=PaymentGateway,OU=ITEE,O=UNSW,ST=ACT,C=AU>

<source-account>
<creditcard cardnumber=0000000000000000 cvv=000 cardholder=Grigori Goldman expiry=2010-11 />

</source-account> <pay </payment-policy> currency="aud" amount="{0}" on="0 0 * * * ?"/>

Figure 6.11:

SSL (Mutual): Test Proxy Certicate Payment Policy

Linear Correlation of Test Results

Using previous results discussed in the preceding two sections as a guide it is possible to make some assumptions regarding how the system will behave under this test conguration. For example, it can be expected that the impact on performance of the payment gateway will continue to exhibit increasing linear behaviour. It is also likely that adding a new step to the SSL handshake (i.e. authentication of the proxy certicate) will escalate the  rate of increase as the number of threads grows. These expectations are conrmed in Figure 6.12. The trend line provides a visual indication of linear correlation, which is conrmed by Pearson's Product Moment Correlation Coecient (PMCC) of 0.9895. Based on these ndings, it is reasonable to conclude that adding client certicates into the process does not have a signicant impact on linear correlation between the number of simultaneous connections and the performance of the payment gateway. That is, it is conrmed that impact on performance remains linear rather than becoming exponential when using mutual authentication. By examining the slope of the trend line, however, it is obvious that the rate with which the performance degrades, as the number of threads increases is higher than what it was before. equation used to derive this trend line, The

y = 87.78x3561.9, reveals the extent to which this slope diers

from the others. This time each additional thread adds approximately 87 milliseconds to individual request processing times where is before it was only 27 milliseconds. This execution time dierence is signicant. The only change between this test scenario and the previous one was the introduction of mutual authentication. Unless it can be established that SSL with mutual authentication does not

125

6.3. Discussion of Test Results

Figure 6.12:

SSL (Mutual): Average request processing time

cause this decline in performance, questions may have to be raised as to its suitability as a solution. Figure 6.13 plots the trend line of the SSL mutual authentication handshake. Based on the average measurements and the slope of the line it is evident that its contribution to the total rate of increase is marginal. The trend line slope is much atter than in Figure 6.12 which can further be substantiated using its equation,

y = 10.745x + 3407.4,

which reveals that SSL processing times are rising by a mere

10 milliseconds per additional thread leaving 77 milliseconds unaccounted. This means that SSL is not contributing as much to the general decline in performance as Figure 6.12 suggests. In fact, SSL is the more stable component of the application leaving unrelated components, such as the Axis2 web service engine as the likely culprit.

Volatility of Test Results

Discussion on linear correlation has highlighted the importance of analysing distribution of test results. It is clear that dispersion of data over a large time frame has increased the rate with which performance degrades unrelated to the actual changes made between this test conguration and the others. That is, this volatility is disrupting the pattern established by the two previous tests making it harder to make concrete conclusions regarding the behaviour of the payment gateway. In the previous section it has already been established that there is a measurable relationship between the number of concurrent threads accessing the payment gateway, the authentication method

126

Chapter 6. Performance Analysis

Figure 6.13:

SSL (Mutual): SSL handshake average processing time

used to gain access to the payment service and the performance of each request. A similar analysis comparing server certicate versus mutual authentication likewise conrms previous ndings. Appendix J presents the results of a multiple regression test performing this comparison (see Table J.2). As before, it is possible to establish with 99% condence interval that both predictor variables are aecting the processing time of requests. As such, it is reasonable to assume that each variable will contribute to the dispersion of the data analysed in this section. Figure 6.14 plots the distribution of total request processing times on a box plot diagram. The results of all four tests reveal an elevated dispersion with an average IQR dierence of 1562 milliseconds. This is higher than the previous test conguration with IQR of 814 milliseconds but it is still not as high as the original, baseline test whose IQR value was 1858 milliseconds. This information is signicant as it implies that the dispersion of the data within the IQR cannot possible be causing the steep increase in performance decay observed during the linear correlation analysis. The answer as to why the server was much slower in processing requests for this test can be obtained by examining the 99th percentile of the data (including the outliers). There is a substantial number of requests that were processed much slower than the majority of other requests within this result set. For example, for the last test with 160 threads some outliers took over 30 seconds to process while the mean was only 10.5 seconds. Such high processing times adversely aect the averages, which are used to calculate the trend line. When these gures were subsequently used for evaluating the

127

6.3. Discussion of Test Results

Figure 6.14:

SSL (Mutual): Distribution of total request processing time

rate with which performance decays the resulting slope was aected appearing much steeper than anticipated. Due to such high volatility, especially within the 75th percentile, it is important to check how the SSL handshake behaves under these conditions. Figure 6.15 plots the SSL handshake distribution on a box plot diagram. The number of outliers, especially within the later test runs, clearly demonstrates how close its distribution follows the totals in the previous diagram. The IQR values are also very similar with an average IQR of 1139 milliseconds matching closely the totals IQR average of 1562 milliseconds. This means that the payment gateway server is equally inconsistent in processing SSL handshakes as it is in processing payment requests. This analysis is crucial as it suggests that increasing simultaneous connections with mutual authentication leads to higher volatility. As was mentioned previously, this is most likely caused by

the physical limitations of the test hardware used. Clearly, because the server has to perform more tasks such as validation of proxy certicates and payment policies it is causing escalating delays for some requests leading to a higher number of outliers. In practical terms, however, this is unlikely to be of signicant importance in a real production environment as this can be mitigated using better hardware (e.g. multi-core CPUs, larget RAM, cluster servers, etc). The important consideration is

128

Chapter 6. Performance Analysis

Figure 6.15:

SSL (Mutual): Distribution of SSL handshake processing time

the server's ability to handle majority of requests consistently.

Consistency of Test Executions

There is not much dierence between SSL handshake with mutual exchange of certicates and the one from the previous section in which only the payment gateway used a certicate. The additional step that is required should not, in principle, aect the server's ability to process requests under a constant load. So far, the focus of this section has been on the server's behaviour under increasing load, which revealed some unusual departure from the established trend. The aim of analysis in this section is to:

1. Conrm the server's ability to handle constant load in a stable and consistent manner, and

2. Quantify the contribution that SSL handshake is making to the total request processing time.

Ideally, the behaviour of the payment gateway under this test conguration should match results obtained from the previous test. It is expected that the actual measurements will be elevated but the trend should be comparable.

129

6.3. Discussion of Test Results

Figure 6.16:

SSL (Mutual): Average processing time by segments of 1000 requests

A timeline chart in Figure 6.16 depicts request processing times grouped by 1000 requests.

It

conrms that within a single test run the payment gateway server is capable of processing requests without losing its eciency over time. demonstrated in Figure 6.8. This matches the results of the previous test scenario as

The dierence is the amount of time that it takes to process each

request. Unlike the previous measurements of 2.5 to 4.5 seconds, for these tests this range is wider starting from 4.9 to 10.8 seconds. With such relatively high processing times it is important to measure the performance of the SSL handshake. It is a crucial component of the application whose performance will dictate whether this solution is viable. A timeline chart in Figure 6.17 plots the SSL handshake processing times grouped by 1000 requests. It conrms that not only the payment gateway is capable of processing SSL handshakes under a constant load but that it can do so even under an increasing load. Ignoring the rst and last points for reasons already discussed, it is clear that all four test series remain consistent throughout their entire test runs. Not only that but they stay relatively close to each other as well regardless of the increases in the number of simultaneous connections. For example, the dierence in processing times for 100 versus 160 threads for any give point is approximately 0.5 seconds or less. This gure diminishes the less threads are used. This proves that in relation to mutual authentication, the

payment gateway is capable of handling both constant and increasing loads without losing eciency over time.

130

Chapter 6. Performance Analysis

Figure 6.17:

SSL (Mutual): Average SSL handshake by segments of 1000 requests

The times dedicated to SSL handshake, however, are signicantly lower than what is spent overall on processing requests. This is the crucial dierence between this test and the previous one which showed much smaller gap between the two processes. As before, plotting the dierence between these activities can help identify the reasons for this discrepancy. Figure 6.18 quanties the contribution made by the SSL handshake towards the total request processing time measured as a percentage of the total time. This diagram reveals that as the number of concurrent threads grows the eect of the SSL handshake diminishes. That is, while for 100

concurrent threads, on average 80% was spent performing the SSL handshake, this number drops to around 50% for 160 concurrent threads. According to Figure 6.17 the SSL handshake is stable

regardless of the number of threads used, taking approximately 4.5 seconds to execute. As such, it is reasonable to assume that something else is contributing to this dierence (e.g. Axis2 engine). This will be analysed further in the next section when the results of all three test congurations will be compared.

6.3.2 Test Analysis Summary

The analyses of test results presented so far have examined the performance of the payment gateway under dierent test congurations in isolation from each other. The purpose of this section is to bring all of those results together so that a more detailed comparison could be made between each one.

131

6.3. Discussion of Test Results

Figure 6.18:

SSL (Mutual): SSL handshake percentage of total time

Specically, the aim of this analysis is to conrm whether using mutual authentication with proxy certicates is a viable solution for the periodical payment problem. Figure 6.19 depicts a bar chart plotting the average request processing times for all three test congurations. When compared like this, it is clear that the last test representing mutual authentication with proxy certicates adds a substantial overhead as compared to the other two. The payment gateway takes approximately twice as long to execute requests that use proxy certicates for authentication than the ones with only server certicates. So far, the only analysis that has been presented used multiple regression to establish the relationship between the number of concurrent threads accessing the payment gateway, the authentication method and the server's performance (see Appendix J). The results of the initial analysis indicated that the SSL handshake step is unlikely to be the sole contributor to this observed doubling of processing time gures. These initial results must be validated here if this solution is to be considered viable. The next diagram in Figure 6.20 isolates just the SSL handshake measurements from the total request processing times and plots them on a bar chart. In this diagram, the dierence between It does not reect

the mutual and the standard SSL handshake processing times are much closer.

the behaviour demonstrated in Figure 6.19 which showed a distinct doubling in processing times. In

132

Chapter 6. Performance Analysis

Figure 6.19:

Average request processing time

this diagram the dierence is more manageable which does not rise with the number of concurrent threads. In actual fact, the dierence between the two test congurations decreases as the number of simultaneous connections grows. For example, for the initial test case with 100 concurrent threads the dierence between the two congurations is 2.2 seconds. This number drops to 1.8 seconds for 160 concurrent threads. This indicates that regardless of the load on the server, the performance of the SSL handshake remains stable. As such, it can be concluded that the extreme measurements depicted in Figure 6.19 are contributed by other elements within the system unrelated to SSL. For example, Axis2 framework used for implementing web services is likely to add signicant amount of overhead as the load increases since it is doing most of the heavy lifting in processing SOAP requests and sending responses. To consolidate these ndings the distribution of each test result set can be compared. Figure 6.21 plots all of the request processing times for each test on a box plot diagram. This diagram once again conrms that the tests using mutual authentication take longer to process individual requests. While the dispersion of the data within the IQR for the mutual authentication tests is comparable with the baseline tests (1562 versus 1858 milliseconds), it is the performance of requests within the 75th percentile and the number of outliers that makes the biggest dierence. For example, the number of outliers is signicantly higher than for non-mutual SSL, each one taking up to three times as long to execute. This causes the average for the entire set to rise thus making the server appear slower.

133

6.3. Discussion of Test Results

Figure 6.20:

SSL handshake average request processing time

These ndings are important as they help to identify the reasons why mutual authentication measurements are so high. However, in the context of this dissertation, what is required is proof

that at least the SSL handshake component of the application is stable. Once this is conrmed then the possible contributors for this dispersion can be discussed. To that end, Figure 6.22 plots the

distribution of SSL handshakes for both test congurations that used SSL on a box plot diagram. By isolating this part of the application from the rest it is much easier to make conclusions as to its ability to handle increasing load in the context of SSL. This diagram shows a much smaller gap between both the averages and the dispersion of the data. The high number of outliers for mutual SSL is still a problem causing elevated mean values within this test conguration. However, both distributions follow a similar pattern with average IQR dierences being much smaller than in Figure 6.21 (1.1 seconds for mutual SSL versus 773 milliseconds). This proves that the SSL component is behaving consistently with volatility rising slowly as the number of concurrent threads grows. These ndings support earlier hypothesis that the increased volatility can be partially attributed to unrelated to SSL components such as the Axis2 web services framework. As this component provides all of the boiler-plate code required to implement a standards compliant web services stack, it is logical to attribute some of this performance decay to its internal processes Due to the limited scope of this thesis, isolating the components of the Axis2 engine that is causing issues is left as an exercise for the future.

134

Chapter 6. Performance Analysis

Figure 6.21:

Distribution of total request processing time

Figure 6.22:

Distribution of SSL handshake processing time

135

6.4. Summary

6.4 Summary
This chapter provides evidence to support claims made in this thesis that mutual authentication using proxy certicates is a viable solution to the periodical payment problem. It conrmed that the payment gateway is capable of handling both constant and increasing loads without losing eciency. Also, proof of linear correlation between the number of simultaneous connections and the server's ability to process requests was established. These ndings were used to make assumptions as to

server's ability to process an even greater number of simultaneous connections given better hardware. That is, linear correlation analysis proved that adding mutual authentication does not exponentially increase the request processing times that would otherwise cause irreparable damage given enough concurrent threads. Some issues were discovered with the choice of the web services engine used, which contributed to a higher than normal dispersion causing increased volatility in behaviour of the payment gateway. Introducing mutual authentication has aggravated this situation causing higher than anticipated increases in processing times. However, despite the high volatility, the SSL component of the application has consistently performed as per expectations. The performance impact that was directly contributed by SSL is manageable and unlikely to cause problems in a realistic, production environment. Dierences of fewer than two seconds between standard and mutual SSL are insignicant considering the various options that are still available. For example, instead of using the default Sun JSSE provider implementation that is quite slow, it can be replaced with Apache Portable Runtime (APR) making calls directly to OpenSSL. This enterprise strength implementation is likely to improve performance of SSL handshake processing. Alternatively, in many commercial applications, SSL is implemented in hardware. These SSL hardware accelerators are specically designed for improved performance in environments that rely heavily on SSL authentication. As such, it is reasonable to conclude that the approach proposed in this

dissertation of using proxy certicates for mutual authentication in a periodical payment environment is viable.

136

Chapter 7

Conclusion
This dissertation makes a signicant and original contribution in the area of electronic commerce. It presented a unique solution to the problem of periodical payments. This problem exists in the

current electronic commerce environment and is not being suciently addressed within the industry despite its popularity. In this thesis, a theoretical periodical payment framework was presented that covered all aspects of the problem oering an elegant and original solution for securely managing periodical payments by leveraging of existing, standards compliant and industry supported technologies. This, rst of its kind, framework denes communication protocols between all participants in a generic and extensible way that can be easily translated into a commercial environment with minimal eort and disruption to existing processes. No other payment framework so far, either academic or commercial, has managed to oer a solution that would not only solve this type of a problem but do it in a way that would be acceptable within a realistic, commercial environment. The theoretical model presented here was also implemented as a demonstration of its viability. The payment systems of the past relied on sophisticated, custom architectures that required complete infrastructural changes to be useful. As such, most have failed despite industry interest and support (e.g. SET). In this dissertation a dierent approach was taken. A unique solution was implemented using minor extensions to existing technologies that can be seamlessly integrated with the existing nancial infrastructure. The working prototype backed up by extensive load testing, followed by a comprehensive performance analysis oer plenty of reasons for optimism in the future of this approach. To summarise, this dissertation makes the following contributions to the eld of electronic payments within an e-commerce environment:

137

7.1. Contribution

Application of X.509 restricted proxy certicates in order to solve payment credential delegation problem from customers to merchants.

Design and implementation of a proxy certicate exchange protocol that allows merchants to obtain delegated credentials from customers via HTTP.

Design of a proxy certicate cancellation protocol that allows customers (for the rst time) to automatically cancel payment agreements without merchant intervention.

Design of a periodical payment policy language that allows the setting of restrictions controlling how and when merchants can use proxy certicates to make payments or customers to cancel payment contracts.

A complete, end-to-end framework implementation using Mozilla Firefox extension architecture to develop customer-side user interface, J2EE for merchant server implementation and acquirer payment gateway web services interface accessible via HTTPS (using X.509 restricted proxy certicates for authentication).

The next section will briey describe each of the above contributions highlighting their signicance, followed by future work and nal remarks.

7.1 Contribution
7.1.1 Periodical Payment Framework
The periodical payment framework consists of a series of protocols that denes the communication standards between all participants. At the core of this framework are the X.509 restricted proxy

certicates that provide the necessary authentication and authorisation tokens for securely processing periodical payment transactions. Each proxy certicate carries a periodical payment policy document that encodes the conditions for each payment within a specied time period. This approach is unique as it delivers ne-grained control of delegated payment credentials that goes beyond the current direct debit model. Using delegation of privileges controlled through policies allows this framework to verify the legitimacy of each transaction at the time of its execution instead of relying on the post-payment process to resolve disputes, as is the case now. The following are the four most important contributions made by this framework.

138

Chapter 7. Conclusion

7.1.1.1 Proxy Certicate Exchange Protocols

A protocol for obtaining proxy certicates from remote users simply does not exist. Systems that are currently using this technology (e.g. Globus Grid) rely on users to manually issue proxy certicates to recipients of their choosing. Whenever proxy certicate requests are used, they are usually manually downloaded as base64 encoded text and imported into standalone applications that decode them and allow users to issue proxy certicates. This approach works well in closed environments where all

users are expected to understand this technology and be familiar with how it works. However, it is unrealistic to expect regular Internet consumers to go through the same process. Most will simply not understand the concepts and be unwilling to adopt this technology. This dissertation makes a rst attempt at streamlining the proxy certicate delegation process by automating the delivery of proxy certicate requests and abstracting some of the complexities of the proxy certicate creation. The idea is, instead of making it a standalone process that is outside of the shopping workow, this step is added to the customers shopping experience. The certicate requests are never presented to users in their raw form but rather transformed into human-readable format and presented via a browser plug-in during page navigation. By keeping the user interface simple and intuitive with unnecessary certicate content hidden, it is possible to introduce this technology to the general Internet community without necessarily going through the process of educating users about PKI.

7.1.1.2 Payment Processing Protocol

One of the reasons that X.509 proxy certicates are an attractive option for implementing delegation is because they can be used with existing software built to handle standard X.509 certicates. The payment protocol presented in this thesis used this to its advantage to greatly simplify the payment process. By relying on well-established and tested technologies it was possible to integrate a sophisticated authentication and authorisation service into the framework without much eort. This is likely to appeal to merchants and payment gateway providers who have committed substantial amounts of capital towards software and hardware dedicated to SSL processing. In addition, this dissertation proposed an original approach to solving the classic double charging problem. A concept of Transaction Revocation Lists (TRL) was presented that allows payment gateways to revoke the use of a certicate for a given time period (based on the contents of the payment policy) without revoking the entire proxy certicate. Unfortunately, this requires the payment gateway to maintain state information regarding past transactions. However, the amount of state stored is manageable as only the last transaction is of interest with all older transactions discarded. This

139

7.1. Contribution

approach ensures that payment gateways are not needlessly burdened with maintaining complex state information keeping this part of the framework relatively simple.

7.1.1.3 Proxy Certicate Cancellation Protocol

The fact is that cancelling direct debits once they are established is dicult. this process rests in the hands of the merchants. The control over

Usually, it is not in their best interest to allow

customers to terminate contracts before they expire due to the loss of potential income. As such, a lot of merchants make it dicult for customers to cancel agreements often requiring multiple telephone calls to accomplish this seemingly simple task. Closing accounts linked to direct debits is also dicult often leaving customers with little recourse during disputes. This dissertation presented a payment cancellation protocol that allows customers to independently request termination of contracts directly from the payment gateway. Using X.509 proxy certicates with payment policies makes the process of cancelling payment agreements simple. Merchants can still control this process by specifying the rules under which contracts can be terminated inside payment policies. However, they cannot manipulate this process to their advantage once the policies have been signed. While payment cancellation is not the most challenging or the most sophisticated part of this dissertation, it is nevertheless one of the most important. Beside security, an ability to easily cancel contracts is a feature that has long been desired by consumers. The protocol presented in this thesis delivers this feature using a exible and extensible architecture that can be easily tailored to suite the needs of both consumers and merchants.

7.1.1.4 Periodical Payment Policy Language

Direct debit forms of the present are simply incapable of supporting payments within an electronic commerce environment. There are no electronic standards that dictate how direct debit agreements should be formulated online. As such, they are either not used, as in the case of credit cards, or

require customers to download, sign and fax/mail them separately. In either case these approaches are insecure and highly inexible. In this thesis, a payment policy language was introduced which uses XML to describe conditions of periodical payments. These policies are designed to replace the traditional direct debit request forms for electronic payments. The use of X.509 proxy certicates in combination with payment policies

enabled the creation of all of the sophisticated protocols described in this thesis, for example, the payment cancellation protocol. Most importantly, it made it possible for each payment transaction

140

Chapter 7. Conclusion

to be instantly and automatically validated against its policy making it impossible for merchants to overcharge customers. The syntax of the periodical payment policy language is simple yet expressive. Using a variety of examples, this dissertation demonstrated how this language could be used to encode conditions into periodical payment contracts. Despite its simplicity it was demonstrated that the syntax is versatile and is capable of representing a variety of realistic conditions that are commonly found in direct debit payments. Furthermore, because the syntax was relatively non-verbose transforming it into a human-readable form was also not an issue. This was extremely important as this dissertation placed high value on policy signatures. Demonstrating that consumers would be able to understand policies before they signed them makes the use of digital signatures in this context a viable solution.

7.1.2 Periodical Payment Framework Implementation

To demonstrate that the periodical payment framework can work in practice and to measure its performance, this dissertation presented a concrete implementation of each component of its architecture. This prototype shows that it is indeed possible to integrate X.509 proxy certicates across all three tiers, i.e. the consumer browser application, the merchant electronic commerce application, and the payment gateway web services application. Furthermore, by using this prototype it was also possible to demonstrate what impact strong authentication and encryption has on payment processing. The measurements obtained from the

performance analysis of this framework are important not only because they provided evidence of solid performance but also because they can be used as a benchmark in the future. Availability of such data certainly would have helped this dissertation so it stands to reason that it may be of use to researchers in this eld.

7.1.2.1 User Interface using Mozilla Firefox Extension

Mozilla Firefox was chosen as a platform for developing the customer-side component of this framework due to its open, extensible architecture. However, most (if not all) modern browsers are capable of supporting third-party extensions via plug-in interfaces. As such, the success achieved with the Firefox extension in this dissertation is possible to replicate with other browsers as well, although the eort required might be greater. The X.509 Proxy Certicate Signing Tool achieves two important goals of this thesis: 1. It seamlessly integrates into the customers shopping experience by tracking HTTP responses received from the merchant application and automatically launching the signing tool window

141

7.1. Contribution

when a proxy certicate request is detected within a HTTP response header. This simple feature improves the user experience by alleviating the need for customers to understand the purpose of the proxy certicate request and how to process it (i.e. convert the request into a signed proxy certicate).

2. Using simple JavaScript DOM functions, the signing tool transforms the dicult to read XML policies with their even harder to understand CRON expressions into a format that is human readable. While more work is still needed to improve the user experience, this simple prototype has demonstrated the ease with which policies can be transformed into a format accessible to general Internet users. This is a signicant achievement as it shows that digital signatures can be meaningfully applied to electronic content by demonstrating that customers will understand the documents they sign.

7.1.2.2 Merchant Electronic Commerce Application

This dissertation had to deal with the issue that unlike most new technologies, the periodical payment framework had to t neatly into the existing, overcrowded electronic commerce environment. Considering that merchants already have operational payment solutions, the major goal of this thesis was to investigate ways of integrating periodical payments into existing applications. The implementation of a prototype merchant application established that this is possible and would require only minimal disruption during integration into an operational environment. Using servlet lters it was demonstrated how the entire proxy certicate exchange process could be integrated into a J2EE merchant application without any changes to its code-base. This is a signicant example as it suggests that this technology could be applied to current applications eciently and cost eectively. As a result of this development eort, signicant discoveries were also made regarding how to integrate X.509 proxy certicate authentication into J2EE merchant applications. Problems with the existing Sun JSSE provider implementation were identied that lead to development of a custom extension to the SSL key manager. This extension allows merchants to choose certicates during

the SSL handshake based on periodical payment instructions rather than using a generic certicate selection algorithm. In addition, issues with SSL session caching were also solved, allowing a single, multi-threaded application to establish SSL sessions with the same remote host using dierent proxy certicates. These solutions made the end-to-end integration of all three tiers of the periodical payment framework possible. Even though some changes to standard technologies were necessary, those changes are isolated to a specic component of the technology stack and can be integrated into existing ap-

142

Chapter 7. Conclusion

plications declaratively.

Most importantly, because no code changes are needed to take advantage

of the improved SSL session management this solution is likely to appeal to merchants with existing payment processing infrastructure.

7.1.2.3 Acquirer Payment Gateway using Web Services

This dissertation envisaged the communication between the merchant server and the acquirer payment gateway to be based on a web service. Web services technology delivers loose coupling

between communication participants while enhancing interoperability via a generic service denition language (i.e. WSDL). In this thesis, a prototype payment gateway was implemented using Apache Axis2 web services engine. During development, issues with the default Sun JSSE trust manager implementation were discovered that prevented the payment gateway from validating X.509 proxy certicates. Considering that this is the most important part of the framework, a custom extension to the default trust manager was subsequently proposed. Just like the custom key manager of the merchant, the new trust manager can be declaratively congured into an existing application. It then takes over the responsibility of validating proxy certicates. The acquirer payment gateway is the only component of the periodical payment framework whose performance is crucial to the success of this approach as a whole. Designed to be accessible by multiple merchant applications simultaneously, the payment gateway can become a bottleneck unless it can eciently process incoming payment transactions. As such, this thesis presented a comprehensive It demonstrated

analysis of its performance providing evidence to support the proposed solution.

that introducing mutual authentication using proxy certicates does have an adverse impact on its performance. However, this dissertation proved linear correlation between the number of simultaneous connections to the payment gateway and its performance. This nding is signicant as it conrms that such performance issues are manageable with better hardware, which would not have been the case if the performance degraded exponentially rather than linearly. Furthermore, during the performance analysis, the impact of the SSL handshake and encryption was isolated from the overall request processing measurements. This analysis demonstrated that

both under constant and increasing loads the behaviour of the server remained consistent and stable. Even though there was a dierence of approximately 2 seconds between the standard and the mutual authentication, this dierence is manageable. While this dissertation used the standard Sun JSSE

provider implementation, which is quite slow, there are other much faster implementations that would reduce SSL handshakes to production acceptable performance times.

143

7.2. Future Work

Overall, the prototype acquirer payment gateway performed well under both constant and increasing loads. It demonstrated that using mutual authentication with proxy certicates is a viable approach that can work in a realistic production environment. All identied performance issues were mostly caused by the lack of hardware resources rather than any underlying problems with the architecture.

7.2 Future Work

This dissertation placed heavy emphasis on web services because currently this technology is leading the way for interoperability between disparate applications. This is unlikely to change in

the near future. As such, the issue of performance is best addressed by evaluating alternative web service implementations. Focusing primarily on performance, the aim of future work should be to

compare the Apache Axis2 engine to other frameworks oering the same features. It is quite likely that by switching to another web services provider performance gains can be achieved without any code changes. Alternatively, the entire concept of using web services within the electronic commerce context can also be examined. While web services deliver interoperability, do their extensive performance By taking a dierent approach to web service implementation, such as

overhead justify their use?

representational state transfer (REST) architectural style, it is possible to simplify this part of the periodical payment framework improving performance while reducing complexity. Some performance improvements are also needed for the SSL handshake. There are various options available to make this part of the framework much faster than what it is now. At present, Apache Tomcat servlet container running the payment gateway application is congured using Sun JSSE provider implementation. This is a pure Java implementation of SSL and its performance is not

ideal. By integrating an alternative library developed using a native API it is possible to dramatically decrease the time taken by the SSL handshake. One such approach is to congure OpenSSL, open source SSL library, into Apache Tomcat using its Apache Portable Runtime (APR) mechanism. The best option for truly testing SSL in a production-like environment would be to congure an SSL hardware accelerator. A hardware accelerator is a special-purpose device designed to perform These devices are

the SSL handshake in hardware thus delivering the best possible performance.

commonly used by organisations with high Internet trac that rely on SSL for authentication. Testing the periodical payment framework with a hardware accelerator would provide the most convincing measurements of how it will behave in an operational environment.

144

Chapter 7. Conclusion

Improvements are also needed to the consumer platform. While it was out-of-scope for this thesis, the issue of customer credential storage must be eventually addressed. At the moment, X.509 Proxy Certicate Signing Tool extension is loading a customer's keystore from a le located in a Firefox accessible directory. This is sucient for testing but would hardly be acceptable in a nal product. In the past credential storage was an insurmountable issue. While smartcard technology has been around for many years, even most modern computers now are not equipped with smartcard readers needed to make this technology available for general Internet use. This, however, is no longer a

problem. Alternative technologies exist right now that make smartcard use a reality. One such technology is USB tokens. A USB token combines both the smartcard and a smartcard reader in a single device. The advantage of using USB tokens is that USB standard is extremely This means that even

popular having been supported by hardware manufacturers for many years.

relatively old computers running older operating systems will support this standard. In the future, USB tokens should be integrated into the Firefox extension presented in this thesis thus providing complete, end-to-end implementation of the periodical payment framework. In the mean time, there are commercial products available on the market right now that make client certicate management easier. For example, SecureAuth for Cisco VPN product provides a user selfservice interface for creating X.509 certicates (see Heary, 2008). It uses an out-of-band channel, such as mobile phone short message service (SMS) for authenticating users before issuing them certicates. This technology can be easily adopted for use within the periodical payment framework. This would not be an ideal solution, as it would require customers to obtain a certicate for every machine they intend to use and the certicate lifespan would have to be extremely short to prevent theft. However, as a short-term solution, that is immediately available, it cannot be ignored. As such, some investigation is required to test its suitability within a periodical payment context. Another potentially promising technology that requires further research is using Subscriber Identity Module (SIM) cards commonly found in mobile phones as cryptographic tokens. SIM cards are essentially smartcards that are capable of storing customer cryptographic credentials. By integra-

ting mobile phones into the periodical payment framework it is possible to leverage of the existing technology and infrastructure providing an alternative avenue for electronic commerce. Finally, some improvements are still needed to the framework itself. As was briey mentioned in Chapter 4 proxy certicates may sometimes expire before periodical payment contracts for which they have been issued. This is clearly an issue that must be addressed before the various stakeholders in this eld seriously consider this solution. As such, the process of renewing proxy certicates once they have been issued to merchants is an area that must be addressed in the near future.

145

7.3. Final Remarks

Fortunately, this issue has already been tackled by the Globus team responsible for the grid security architecture discussed in Chapter 2. The periodical payment framework can be extended to include a renewal service similar to MyProxy presented by Kouril (2005). MyProxy works by storing customer digital certicates (and private keys) on secure remote servers which allow holders of customer issued proxy certicates to perform a limited set of functions using them. For example, MyProxy exposes a publicly accessible service that uses customer private keys to renew proxy certicates. Unfortunately, a service like MyProxy makes the use of authentication tokens (e.g. smartcards) dicult. To make use of smartcards an alternative approach is needed. For example, proxy certicates can be obtained from the payment gateway rather than from the customers. The merchant would

obtain a signed copy of a payment policy from a customer and then request an authentication token (i.e. a proxy certicate) from the payment gateway using the signed policy as proof that the customer agreed to the contract. Using this approach will ensure that life spans of proxy certicates can be eciently managed.

7.3 Final Remarks

Digital payments within electronic commerce is an area that has seen a great deal of research and development over many years. Periodical payments, however, remain one eld that has not beneted from this work. The growing popularity of this type of payment, o-line and on the Internet, demonstrate that this topic is still relevant in the current electronic commerce environment. The periodical payment framework presented in this dissertation delivers a solution to an existing problem aecting users of the direct debit payment model. This framework resolves issues of past implementations by leveraging of the currently available, standards compliant and industry-supported technologies. the same time it does not compromise on either security or performance. Periodical payment framework represents an important change in direction for electronic commerce payments. Periodical payments ll the security and usability gap that the present direct debit model is incapable of doing due to its paper driven design. Neither can the existing solutions oer value due to their fundamental focus that place anonymity and non-relinquishing of control as priority. It is clear that existing approaches to electronic commerce by industry leaders, such as Visa and MasterCard are not directly addressing this particular payment format either. In fact, current attempts rely At

on customers' physical presence during payment transactions thus precluding even the possibility of delegation. With the growing popularity of direct debit payments there is a clear need for a more

secure way of conducting such transactions over the Internet.

146

Chapter 7. Conclusion

This thesis demonstrated that a periodical payment framework, built using web services and secured by SSL with X.509 restricted proxy certicates, is a viable solution to this problem. While using SSL with mutual authentication does impact performance, it was demonstrated that this increase is insignicant when measured against the benets that it provides. In addition, this dissertation has validated the choice of X.509 restricted proxy certicates for authentication and authorisation. It was demonstrated how these certicates in combination with Using

payment policies, can be used to replace the traditional direct debit request (DDR) forms.

digital signatures it is possible to place same signicance on signed payment policies as on the current DDR forms. Most importantly, having digitised merchant-customer contracts, it is now possible, for the rst time, to verify the legitimacy of each payment transaction before processing. This eectively eliminates the current problems of overcharging. Furthermore, it was demonstrated how payment policies can be tailored to support periodical payment cancellation. This is an important feature that would not only improve usability but might actually serve as a catalyst for further customer acceptance of this type of payments over the Internet. While it is dicult to predict the future of payment technologies, it is almost guaranteed that at least some of the ideas presented in this thesis will eventually be introduced into current payment solutions. The strong demand for periodical payments with growing consumer awareness of security issues will most denitely drive its development in the future.

147

7.3. Final Remarks

148

Bibliography
Anderson, R. J., & Kuhn, M. G. (1996). Tamper resistance: a cautionary note. In WOEC'96:

Proceedings of the 2nd conference on Proceedings of the Second USENIX Workshop on Electronic Commerce , (pp. 11). Berkeley, CA, USA: USENIX Association.
Anderson, R. J., & Kuhn, M. G. (1998). Low cost attacks on tamper resistant devices. In Proceedings

of the 5th International Workshop on Security Protocols , (pp. 125136). London, UK: SpringerVerlag.

Apache (2008). Jakarta commons httpclient. URL

http://hc.apache.org/httpclient-3.x/

APCA (2005). A growing role to meet members' needs. Tech. rep., Australian Payments Clearing Association, Sydney, Australia.

Bella, G., Paulson, L. C., & Massacci, F. (2002). The verication of an industrial payment protocol: the set purchase phase. In CCS '02: Proceedings of the 9th ACM conference on Computer and

communications security , (pp. 1220). New York, NY, USA: ACM.

Bella, G., Paulson, L. C., & Massacci, F. (2003). Verifying the set registration protocols.

IEEE

Journal on Selected Areas in Communications , 21 , 7787.

Bellare, M., Garay, J. A., Hauser, R., Herzberg, A., Krawczyk, H., Steiner, M., Tsudik, G., Herreweghen, E. V., & Waidner, M. (2000). Design, implementation, and deployment of the ikp secure electronic payment system. IEEE Journal on Selected Areas in Communications , 18 , 611627.

Bellare, M., Garay, J. A., Hauser, R., Herzberg, A., Krawczyk, H., Steiner, M., Tsudik, G., & Waidner, M. (1995). ikp: a family of secure electronic payment protocols. In WOEC'95: Proceedings of the

1st conference on USENIX Workshop on Electronic Commerce , (pp. 77). Berkeley, CA, USA:
USENIX Association.

149

BIBLIOGRAPHY

Blakley, G. R. (1979). Safeguarding cryptographic keys. In AFIPS National Computer Conference . BouncyCastle (2009). The legion of the bouncy castle. URL

http://www.bouncycastle.org/

Brands, S. (1993). An ecient o-line electronic cash system based on the representation problem. Tech. rep. Brands, S. (1994). Untraceable o-line cash in wallet with observers. In CRYPTO '93: Proceedings

of the 13th annual international cryptology conference on Advances in cryptology , (pp. 302318).
New York, NY, USA: Springer-Verlag New York, Inc. Brands, S. (1995). Electronic cash on the internet. In SNDSS '95: Proceedings of the 1995 Symposium

on Network and Distributed System Security (SNDSS'95) , (pp. 6484). Washington, DC, USA:
IEEE Computer Society. Camp, L. J., Sirbu, M., & Tygar, J. D. (1995). Token and notational money in electronic commerce. In WOEC'95: Proceedings of the 1st conference on USENIX Workshop on Electronic Commerce , (pp. 11). Berkeley, CA, USA: USENIX Association. Chaum, D. (1992). Achieving electronic privacy. Scientic American , (pp. 96101). Chaum, D., Fiat, A., & Naor, M. (1988). Untraceable electronic cash. In CRYPTO '88: 8th Annual

International Cryptology Conference , (pp. 319327).

Chaum, D., & Pedersen, T. P. (1993). Wallet databases with observers. In CRYPTO '92: Proceedings

of the 12th Annual International Cryptology Conference on Advances in Cryptology , (pp. 89105).
London, UK: Springer-Verlag. Chaum, D. L. (1981). Untraceable electronic mail, return addresses, and digital pseudonyms. Com-

munications of the ACM , 24 (2), 8490.

Chaum, D. L. (1983). Blind signatures for untraceable payments. In D. Chaum, R. Rivest, & A. Sherman (Eds.) Advances in Cryptology Proceedings of Crypto 82 , (pp. 199203). Chaum, D. L. (1985). Security without identication: transaction systems to make big brother

obsolete. Communications of the ACM , 28 (10), 10301044. Cramer, R. J. F., & Pedersen, T. P. (1994). Improved privacy in wallets with observers. In EURO-

CRYPT '93: Workshop on the theory and application of cryptographic techniques on Advances in cryptology , (pp. 329343). Secaucus, NJ, USA: Springer-Verlag New York, Inc.

150

BIBLIOGRAPHY

Desmedt, Y. G., & Frankel, Y. (1989). Threshold cryptosystems. In CRYPTO '89: Proceedings on

Advances in cryptology , (pp. 307315). New York, NY, USA: Springer-Verlag New York, Inc.
Desmedt, Y. G., & Frankel, Y. (1992). Shared generation of authenticators and signatures (extended abstract). In CRYPTO '91: Proceedings of the 11th Annual International Cryptology Conference

on Advances in Cryptology , (pp. 457469). London, UK: Springer-Verlag.

Dierks, T., & Allen, C. (1999). The tls protocol version 1.0. URL

http://www.ietf.org/rfc/rfc2246.txt
Ten risks of pki: What you're not being told about public key

Ellison, C., & Schneier, B. (2000).

infrastructure. Computer Security Journal , 16 , 17.

EPC (2009). Sepa core direct debit scheme rulebook v3.4. URL

http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_

id=302
Even, S., & Goldreich, O. (1983). Electronic wallet. In CRYPTO '83: Proceedings on Advances in

Cryptology , (pp. 383386).

Ferguson, N. (1993). Single term o-line coins. (pp. 318328). Springer-Verlag. In CRYPTO '93:

Ferguson, N. (1994).

Extensions of single-term coins.

Proceedings of the 13th

Annual International Cryptology Conference on Advances in Cryptology , (pp. 292301). London,

UK: Springer-Verlag. Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures . Ph.D. thesis, UNIVERSITY OF CALIFORNIA, IRVINE. URL

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., & Stewart, L. (1999). Http authentication: Basic and digest access authentication. URL

http://www.ietf.org/rfc/rfc2617.txt
Periodical payment model using restricted proxy certicates. In ACSC '07:

Goldman, G. (2007).

Proceedings of the thirtieth Australasian conference on Computer science , (pp. 131139). Darlinghurst, Australia, Australia: Australian Computer Society, Inc.

GPayments (2002a). Veried by visa overview: The 3-d secure authentication standard. Tech. rep., GPayments Pty Ltd.

151

BIBLIOGRAPHY

GPayments (2002b).

Visa 3-d secure vs. mastercard spa:

A comparison of online authentication

standards. Tech. rep., GPayments Pty Ltd.

Heary, J. (2008). Sslvpn vulnerabilities - client certicates oer a superior defense over otp devices. URL

http://www.networkworld.com/community/node/31124

Housley, R., Polk, W., Ford, W., & Solo, D. (2002). Internet x.509 public key infrastructure certicate and certicate revocation list (crl) prole. URL

http://www.ietf.org/rfc/rfc3280.txt

Jakobsson, M., & M'Rahi, D. (1999). Mix-based electronic payments. In SAC '98: Proceedings of

the Selected Areas in Cryptography , (pp. 157173). London, UK: Springer-Verlag.

Jakobsson, M., & Yung, M. (1996). Revokable and versatile electronic money (extended abstract). In CCS '96: Proceedings of the 3rd ACM conference on Computer and communications security , (pp. 7687). New York, NY, USA: ACM.

Josang, A., Mllerud, P. M., & Cheung, E. (2001).

Web security:

The emperors new armour.

In

Proceedings of the European Conference on Information Systems (ECIS2001 .

Josang, A., Pedersen, I. G., & Povey, D. (2000). Pki seeks a trusting relationship. In ACISP '00:

Proceedings of the 5th Australasian Conference on Information Security and Privacy , (pp. 191
205). London, UK: Springer-Verlag.

Josang, D. A., & Tran, N. (2000). Trust management for e-commerce. In Proceedings of the Virtual

Banking Conference .

Kohl, J. T., Neuman, B. C., & Ts'o, T. Y. (1994). The evolution of the kerberos authentication service. (pp. 7894). IEEE Computer Society Press.

Kouril, D. (2005). A credential renewal service for long-running jobs. In GRID '05: Proceedings of

the 6th IEEE/ACM International Workshop on Grid Computing , (pp. 6368). Washington, DC,
USA: IEEE Computer Society.

Kristol, D. M., Low, S. H., & Maxemchuk, N. F. (1994). Anonymous internet mercantile protocol. Tech. rep., AT&T Bell Laboratories.

Low, S. H., Maxemchuk, N. F., & Paul, S. (1996). Anonymous credit cards and their collusion analysis.

IEEE/ACM Trans. Netw., 4 (6), 809816.

152

BIBLIOGRAPHY

Low, S. H., Paul, S., & Maxemchuk, N. F. (1994). Anonymous credit cards. In CCS '94: Proceedings

of the 2nd ACM Conference on Computer and communications security , (pp. 108117). New
York, NY, USA: ACM.

MasterCard, & Visa (1997a). Set secure electronic transaction specication book 1: Business description.

MasterCard, & Visa (1997b). Set secure electronic transaction specication book 2: Programmer's guide.

Mazumdar, S., & Dwivedi, S. (2007). identity to grid-based portals. URL

On-demand provisioning of proxy certicate for delegating

https://addons.mozilla.org/en-US/firefox/addon/4471

McClave, J. T., & Sincich, T. (2006). Statistics , (10th ed.). Prentice Hall.

Medvinsky, G., & Neuman, B. C. (1993). the internet.

Netcash:

A design for practical electronic currency on

In Proceedings of the First ACM Conference on Computer and Communications

Security , (pp. 102106).

Mozilla (2009). Mozilla developer center. URL

http://developer.mozilla.org

Neuman, B., & Ts'o, T. (1994). Kerberos: an authentication service for computer networks. Commu-

nications Magazine, IEEE , 32 (9), 3338.

Neuman, B. C. (1993). Proxy-based authorization and accounting for distributed systems. In Procee-

dings of the 13th International Conference on Distributed Computing Systems , (pp. 283291).

Neuman, B. C., & Medvinsky, G. (1995). Requirements for network payment: the netcheque perspective. In COMPCON '95: Proceedings of the 40th IEEE Computer Society International Confe-

rence , (p. 32). Washington, DC, USA: IEEE Computer Society.

OASIS (2005a). Assertions and protocols for the oasis security assertion markup language (saml) v2.0. URL

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

OASIS (2005b). extensible access control markup language (xacml) version 2.0. URL

http://docs.oasis-open.org/xacml/access_control-xacml-2_0-core-spec-cd-04.

pdf
153

BIBLIOGRAPHY

Okamoto, T., & Ohta, K. (1989). Disposable zero-knowledge authentications and their applications to untraceable electronic cash. In CRYPTO '89: Proceedings on Advances in cryptology , (pp.

481496). New York, NY, USA: Springer-Verlag New York, Inc.

Okamoto, T., & Ohta, K. (1992). Universal electronic cash. In CRYPTO '91: Proceedings of the 11th

Annual International Cryptology Conference on Advances in Cryptology , (pp. 324337). London,

UK: Springer-Verlag.

OpenSymphony (2008). Quartz online documentation. Last Accessed: November 2008. URL

http://www.opensymphony.com/quartz/

Paulson, L. C. (2002). Verifying the set protocol: Overview. In International Conference on Formal

Aspects of Security (FASec), LNCS .

RBA (2001). Payments system board annual report. Tech. rep., Reserve Bank of Australia, Sydney, Australia.

RBA (2005). Bill payments and automated teller machines. Tech. rep., Reserve Bank of Australia, Sydney, Australia.

Shamir, A. (1979). How to share a secret. Commun. ACM , 22 (11), 612613.

Sirbu, M., & Tygar, J. D. (1995). Netbill: An internet commerce system optimized for network delivered services. In COMPCON '95: Proceedings of the 40th IEEE Computer Society International

Conference , (p. 20). Washington, DC, USA: IEEE Computer Society. Cryptography and Network Security: Principles and Practice , chap. 17, (pp.

Stallings, W. (2006).

549560). Prentice Hall.

Sun (2002). Core j2ee patterns - intercepting lter. URL

http://java.sun.com/blueprints/corej2eepatterns/Patterns/

InterceptingFilter.html
Sun (2008). Java platform standard edition 6. URL

http://java.sun.com/javase/6/docs/api/javax/net/ssl/X509KeyManager.html

Tuecke, S., Welch, V., Engert, D., Pearlman, L., & Thompson, M. (2004). Internet x.509 public key infrastructure (pki) proxy certicate prole. URL

http://www.ietf.org/rfc/rfc3820.txt
154

BIBLIOGRAPHY

Welch, V., Foster, I., Kesselman, C., Mulmo, O., Pearlman, L., Gawor, J., Meder, S., & Siebenlist, F. (2004). X.509 proxy certicates for dynamic delegation. In Proceedings of the 3rd Annual PKI

R&D Workshop .
Welch, V., Siebenlist, F., Foster, I., Bresnahan, J., Czajkowski, K., Gawor, J., Kesselman, C., Meder, S., Pearlman, L., & Tuecke, S. (2003). Security for grid services. In HPDC '03: Proceedings of

the 12th IEEE International Symposium on High Performance Distributed Computing , (p. 48).
Washington, DC, USA: IEEE Computer Society.

Wolrath, C. E. (1998). Secure Electronic Transaction: a market survey and a test implementation of

SET technology . Master's thesis, Department of Information Science, Uppsala University.

URL

http://www.wolrath.com/set.html

Yasushi Kawakura, I. S. J. D. T., Marvin Sirbu (1999). Flexible and scalable credential structures: Netbill implementation and experience.

155

BIBLIOGRAPHY

156

Appendix A

Periodical Payment Policy (XSD)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="policy.unsw.adfa.gov.au" targetNamespace="policy.unsw.adfa.gov.au" elementFormDefault="qualified"> <xs:element name="payment-policy"> <xs:complexType> <xs:sequence> <xs:element name="description" type="Text" minOccurs="0" maxOccurs="1"/> <xs:element name="source-account" type="Account" minOccurs="1" maxOccurs="1"/> <xs:element name="pay" type="Pay" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="cancellation-policy" type="CancellationPolicy" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="merchant-dn" type="xs:string" use="required"/> <xs:attribute name="payment-gateway-dn" type="xs:string" use="required"/> </xs:complexType> </xs:element>
...

157

...

<xs:complexType name="Account"> <xs:choice> <xs:element name="creditcard" type="CreditCard"/> <!-etc --> </xs:choice> </xs:complexType> <xs:complexType name="CreditCard"> <xs:attribute name="cardholder" type="xs:string" use="required"/> <xs:attribute name="cardnumber" type="CreditCardNumber" use="required"/> <xs:attribute name="cvv" type="CreditCardVerificationValue" use="required"/> <xs:attribute name="expiry" type="xs:gYearMonth" use="required"/> </xs:complexType> <xs:simpleType name="CreditCardNumber"> <xs:restriction base="xs:integer"> <xs:pattern value="\d{16}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CreditCardVerificationValue"> <xs:restriction base="xs:integer"> <xs:pattern value="\d{3}"/> </xs:restriction> </xs:simpleType> <xs:complexType name="CancellationPolicy"> <xs:sequence> <xs:element name="pay" type="Pay" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="url" type="xs:anyURI" use="required"/> </xs:complexType>
...

158

Appendix A. Periodical Payment Policy (XSD)

...

<xs:complexType name="Pay"> <xs:attribute <xs:attribute <xs:attribute <xs:attribute </xs:complexType> <xs:simpleType name="Currency"> <xs:restriction base="xs:string"> <xs:enumeration value="aud" /> <xs:enumeration value="usd" /> <!-etc --> </xs:restriction> </xs:simpleType> <xs:simpleType name="Amount"> <xs:restriction base="xs:decimal"> <xs:minInclusive value="0" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="Cron"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:complexType name="Text"> <xs:simpleContent> <xs:extension base="xs:string"/> </xs:simpleContent> </xs:complexType> </xs:schema> name="currency" type="Currency" use="required"/> name="amount" type="Amount" use="optional"/> name="limit" type="Amount" use="optional"/> name="on" type="Cron" use="required"/>

159

160

Appendix B

Payment Web Service (WSDL)

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ns1="http://service.ws.unsw.adfa.gov.au" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:ns0="http://pojo.ws.unsw.adfa.gov.au/xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" targetNamespace="http://service.ws.unsw.adfa.gov.au"> <wsdl:documentation>PaymentProcessingService</wsdl:documentation>
...

161

...

<wsdl:types> <xs:schema xmlns:ax21="http://pojo.ws.unsw.adfa.gov.au/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://pojo.ws.unsw.adfa.gov.au/xsd"> <xs:complexType name="PaymentInstruction"> <xs:sequence> <xs:element minOccurs="0" name="accountFrom" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="accountTo" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="amount" nillable="true" type="xs:decimal"/> <xs:element minOccurs="0" name="description" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:complexType name="PaymentReceipt"> <xs:sequence> <xs:element minOccurs="0" name="id" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="paymentGatewayId" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="paymentInstruction" nillable="true" type="ax21:PaymentInstruction"/> </xs:sequence> </xs:complexType> </xs:schema>
...

162

Appendix B. Payment Web Service (WSDL)

...

<xs:schema xmlns:ns="http://service.ws.unsw.adfa.gov.au" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://service.ws.unsw.adfa.gov.au"> <xs:element name="processPayment"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="paymentInstruction" nillable="true" type="ns0:PaymentInstruction"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="processPaymentResponse"> <xs:complexType> <xs:sequence> xs:element minOccurs="0" name="return" nillable="true" type="ns0:PaymentReceipt"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </wsdl:types> <wsdl:message name="processPaymentRequest"> <wsdl:part name="parameters" element="ns1:processPayment"/> </wsdl:message> <wsdl:message name="processPaymentResponse"> <wsdl:part name="parameters" element="ns1:processPaymentResponse"/> </wsdl:message> <wsdl:portType name="PaymentProcessingServicePortType"> <wsdl:operation name="processPayment"> <wsdl:input message="ns1:processPaymentRequest" wsaw:Action="urn:processPayment"/> <wsdl:output message="ns1:processPaymentResponse" wsaw:Action="urn:processPaymentResponse"/> </wsdl:operation> </wsdl:portType>
... 163

...

<wsdl:binding name="PaymentProcessingServiceSOAP11Binding" type="ns1:PaymentProcessingServicePortType"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <wsdl:operation name="processPayment"> <soap:operation soapAction="urn:processPayment" style="document"/> <wsdl:input><soap:body use="literal"/></wsdl:input> <wsdl:output><soap:body use="literal"/></wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="PaymentProcessingServiceSOAP12Binding" type="ns1:PaymentProcessingServicePortType"> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <wsdl:operation name="processPayment"> <soap12:operation soapAction="urn:processPayment" style="document"/> <wsdl:input><soap12:body use="literal"/></wsdl:input> <wsdl:output><soap12:body use="literal"/></wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="PaymentProcessingServiceHttpBinding" type="ns1:PaymentProcessingServicePortType"> <http:binding verb="POST"/> <wsdl:operation name="processPayment"> <http:operation location="PaymentProcessingService/processPayment"/> <wsdl:input> <mime:content type="text/xml" part="processPayment"/> </wsdl:input> <wsdl:output> <mime:content type="text/xml" part="processPayment"/> </wsdl:output> </wsdl:operation> </wsdl:binding>
...

164

Appendix B. Payment Web Service (WSDL)

...

<wsdl:service name="PaymentProcessingService"> <wsdl:port name="PaymentProcessingServiceSOAP11port" binding="ns1:PaymentProcessingServiceSOAP11Binding"> <soap:address location="nullPaymentProcessingService"/> </wsdl:port> <wsdl:port name="PaymentProcessingServiceSOAP11port_http1" binding="ns1:PaymentProcessingServiceSOAP11Binding"> <soap:address location= "http://host/axis2/services/PaymentProcessingService"/> </wsdl:port> <wsdl:port name="PaymentProcessingServiceSOAP12port" binding="ns1:PaymentProcessingServiceSOAP12Binding"> <soap12:address location="nullPaymentProcessingService"/> </wsdl:port> <wsdl:port name="PaymentProcessingServiceSOAP12port_http1" binding="ns1:PaymentProcessingServiceSOAP12Binding"> <soap12:address location= "http://host/axis2/services/PaymentProcessingService"/> </wsdl:port> <wsdl:port name="PaymentProcessingServiceHttpport1" binding="ns1:PaymentProcessingServiceHttpBinding"> <http:address location= "http://host/axis2/services/PaymentProcessingService"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

165

166

Appendix C

Quartz CRON Syntax

Each

<pay>

element inside a periodical payment policy must contain a single

on

attribute which

represents the period to which this pay expression is applicable. The syntax of this attribute is based on a UNIX CRON scheduling service. Specically, the exact syntax used in this thesis is borrowed from (OpenSymphony, 2008). Table C.1 depicts the seven elds (the last eld is optional) that represent a valid CRON expression. Beside the xed values as depicted in the Allowed Values column, a CRON expression may contain wildcard characters. The meaning of a wildcard character may change depending on which eld it is used in. Table C.2 provides a brief description of each wildcard character and its use. For a

comprehensive description of the CRON syntax, including the description of the wildcard characters and examples see (OpenSymphony, 2008).

Field Name
Seconds Minutes Hours Day of month Month Day of week Year (optional)

Allowed Values
0-59 0-59 0-23 1-31 1-12 or JAN-DEC 1-7 or SUN-SAT present year onwards

Wildcard Values
, - * / , - * / , - * / , - * ? / L W , - * / , - * ? / L # , - * /

Table C.1:

Quartz CRON Attributes

167

Wildcard
, * / L W # ?

Description
List of values Range of values All/Any values Starting value / increment value Shorthand for last Shorthand for weekday The nth day of the month No specic value

Example
hour eld means 10,11,12 o'clock hour eld (same as above)  * in seconds/minutes/hours eld means any time 0/15 in the minutes eld means 0, 15, 30, 45
10,11,12 in an 10-12 in an (i.e. every 15 minutes) 6L in the the month 1W in the

day-of-week

eld means the last Friday of eld means the 1st

day-of-month

working day of the month 6#3 in the day-of-week eld means the 3rd Friday of the month This is just a placeholder for mandatory elds whose value is not important

Table C.2:

Quartz CRON Wildcard Characters

168

Appendix D

Extending Sun X.509 JSSE Implementation

D.1 Security Provider
To implement custom security behaviour needed by the merchant application a new security provider was required extending the default

java.security.Provider

abstract class.

Provider

instances

are registered with the JVM to provide various security services such as key generation, key factories, digital signature algorithms, etc. For the merchant prototype a new provider was required to extend the default behaviour of both the

KeyManagerFactory

and the

TrustManagerFactory

implementa-

tions. Figure D.1 demonstrates a class declaration of this custom security provider that denes the new key and trust manager factories. The

CustomProvider

instance can be registered with the JVM programmatically at any time

although as a best practice it is normally initialised on application start-up. This is done by executing the following instruction:

Security.addProvider(new CustomProvider());.

Alternatively, it can le thus making

also be registered declaratively by adding a new entry to the global

java.security

this provider accessible to all instances of the JVM on the server machine. For example:

security.provider.10=au.gov.unsw.adfa.security.CustomProvider
Once registered, the JVM can in theory use the custom key and trust manager factories to create new key and trust managers needed for obtaining certicate chains and private keys when establishing SSL sessions with remote hosts (merchant side), and validating proxy certicates (payment gateway

169

D.1. Security Provider

public

class CustomProvider extends Provider { public CustomProvider() { super(custom, 1.0, Provider for custom X.509 key and trust managers); put(KeyManagerFactory.custom, au.gov.adfa.unsw.security.provider.CustomKeyManagerFactorySpi); put(TrustManagerFactory.custom, au.gov.adfa.unsw.security.provider.CustomTrustManagerFactorySpi);
}

Figure D.1:

Custom Security Provider Implementation

side). However, this custom provider will not be used by default unless the JVM's preferred factories are changed. Normally, the JVM decides which factories to use by using the following system properties:

ssl.KeyManagerFactory.algorithm

and

ssl.TrustManagerFactory.algorithm. java.security
le.

By default,

these properties are set to SunX509 as declared inside the

Overriding this

property at the command line with the value of custom will force the JVM to use the new security provider (e.g.

-Dssl.TrustManagerFactory=custom).

Being able to override the default security provider implementation at the command line like this is extremely useful as it allows new provider implementations to be added to applications over which developers have little or no control over. For example, this approach can be used to add proxy certicate validation to Tomcat servlet container which was used to deploy the payment gateway application. This same technique would work for any existing J2EE applications that are accessible via HTTPS.

D.1.1 Custom KeyStore Manager

This solution extends the default X.509 key manager implementation enabling it to dynamically select digital certicates and their private keys during SSL mutual authentication handshake based on the currently processed customer payment. It can do this even in a multi-threaded environment with multiple SSL sessions being established and authenticated with dierent proxy certicates at the same time. The code fragment in Figure D.2 depicts the key features of the

CustomKeyManagerFactorySpi X509KeyManager
implementa-

(service provider interface) class. Its purpose is to replace the default

170

Appendix D. Extending Sun X.509 JSSE Implementation

public

class CustomKeyManagerFactorySpi extends KeyManagerFactorySpi { private

...

CustomX509KeyManager keyManager;

@Override protected void engineInit(KeyStore keyStore, char[] password) { KeyManagerFactory factory = KeyManagerFactory.getInstance(SunX509); factory.init(keyStore, password); for(KeyManager keyManager : factory.getKeyManagers) { if(keyManager instanceof X509KeyManager) { this.keyManager = new CustomX509KeyManager( (X509KeyManager) keyManager); break;
} } } }

Figure D.2:

Custom Key Manager Factory Implementation

tion created by Sun's a

KeyManagerFactory

with a custom manager implementation. When creating

CustomX509KeyManager

instance the default

X509KeyManager

is injected into this object via its

constructor.

This ensures that whenever possible the work ow will be delegated to the default

implementation reducing the complexity of the custom key manager code. For the prototype, there was only one method in the to be customised (see

CustomX509KeyManager

class that needed

chooseClientAlias X509KeyManager

method in Figure

??).

The rest simply delegated their When choosing an alias that

workload to the default

class implemented by Sun.

identies the digital certicate and the private key entry within a keystore a check was performed to see if an alias has already been chosen by the application (i.e. merchant payment processing service). Unless the application has specically indicated which alias should be used during the SSL handshake this method, just like the rest of this class, will delegate the work to the default key manager. A simple class, alias string into a

SSLContextLocal, was implemented that would allow a Java application to set an

ThreadLocal variable (see code fragment in Figure D.4 for the full class declaration).

This variable is only local to the currently executing thread which makes this a convenient way of keeping track of application state in a multi-threaded environment without synchronisation. Using this class in both the

CustomX509KeyManager (above) and the PaymentProcessingService (Chapter

171

D.1. Security Provider

public

class CustomX509KeyManager implements X509KeyManager { private

...

X509KeyManager defaultKeyManager;

@Override public
{

String chooseClientAlias(String[] keyType, Principal[] issuers, Socket String if(alias }else{ return
}

socket) alias = SSLContextLocal.getClientAlias(); != null && alias.length() != 0) { return alias; defaultKeyManager.chooseClientAlias( keyType, issuers, socket);

} ... }

Figure D.3:

Custom Key Manager Implementation

172

Appendix D. Extending Sun X.509 JSSE Implementation

public

class SSLContextLocal { private public

}

static ThreadLocal<String> context = new ThreadLocal<String>(); static void setClientAlias(String alias) { context.set(alias);

public
}

static String getClientAlias() { return context.get();

public }
}

static void reset() { context.set(null);

Figure D.4:

SSL Context Local Cache Implementation

5, Figure 5.14) allows the merchant web application and the key manager security framework classes to share data. The coupling between these components is loose with neither one dependent on the other for processing (i.e. if not initialised the key manager simply defaults to the Sun implementation). The design of this prototype utilised only a single keystore for storing digital certicates to be used by the merchant application. to support multiple keystores. However, if required the above example can be easily extended

All changes would be conned to the

CustomX509KeyManager
The

class class

responsible for obtaining certicate and key material from keystores.

SSLContextLocal

could be used to give a Java application control by letting it pre-select which keystore to use with this information stored in another thread-local variable.

D.1.2 Custom TrustStore Manager

The default implementation of the

javax.net.ssl.X509TrustManager

interface provided by Sun

does not implement the required logic for validating X.509 proxy certicates. To overcome this limitation, an extended trust manager is required that would override the default certicate validation logic by recognising proxy certicates and implementing certicate chain validation logic that is applicable to them. The actual implementation of the

TrustManagerFactorySpi

class is almost identical to that of

the key manager factory (see previous section). Both work on the same design principle of wrapping the Sun's default implementation so that whenever possible processing can be delegated to it.

173

D.2. Custom SSLSocketFactory

public

class CustomX509TrustManager implements X509TrustManager { private public

}

X509TrustManager defaultTrustManager; CustomX509TrustManager(X509TrustManager trustManager) { defaultTrustManager = trustManager;

@Override public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { ProxyCertPathValidator.validate(chain, authType);
}

@Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { defaultTrustManager.checkServerTrusted(chain, authType);
}

@Override public
} }

X509Certificate[] getAcceptedIssuers() { return defaultTrustManager.getAcceptedIssuers();

Figure D.5:

Custom X.509 TrustManager Implementation

To solve the issue of proxy certicate validation, there is only one method that needs to be implemented in the

CustomX509TrustManager class.

Specically,

checkClientTrusted method responsible

The default lo-

for validating certicate chains received from client applications must be changed.

gic is replaced to accept chains with multiple end-entity certicates provided that one was used to create the other (i.e. issuer end-entity is used to create proxy end-entity certicate). Figure D.5

demonstrates how this

TrustManager

could be implemented in practice.

Notice that beside the

checkClientTrusted method, all other methods simply delegate their processing to the default trust
manager implementation.

D.2 Custom SSLSocketFactory

The design of the periodical payment framework is such that it requires each unique connection to the payment gateway to be separately authenticated using a proxy certicate. However,

174

Appendix D. Extending Sun X.509 JSSE Implementation

javax.net.ssl.SSLContext

class caches SSL sessions and reuses them whenever multiple connec-

tions to the same host are established. This behaviour necessitated implementation of a new class,

CustomSSLSocketFactory, that would override this behaviour and force creation of a new SSLContext
per SSL connection. The code fragment in Figure D.6 demonstrates how a using this approach.

createSocket

method was implemented

The most signicant part of this code is a reference to the private method This method is invoked every time a new SSL socket is required. The body of

createSSLContext.
the

createSSLContext method likewise reveals that a new SSL context is created and initialised every
context.init(factory.getKeyManagers(), null, null);).

time this method is invoked (as per this line:

By not letting the framework reuse an SSL context with its internal state between invocations the problem of session caching is thus avoided.

createSocket

The SSL socket factory implemented in Figure D.6 follows a standard approach dictated by Jackarta Commons HttpClient open source Java library (Apache, 2008). This library provides mechanisms for customising SSL behaviour within Java applications. to: For example, it allows developers

Swap the default implementation of the SSL protocol (provided by Sun) with a third party library, or

Accept self-signed or untrusted SSL certicates during authentication (something that produces an

SSLException

within the default implementation).

Before the custom SSL socket factory can be used for creating SSL sockets it must be registered with the JVM. This can be done programmatically using HttpClient's method

Protocol

class. It declares a static

registerProtocol

which is designed to register new communication protocols identied by

a unique identier string. This method can also override existing protocols if the identier string used is already present (e.g. https). This is the technique that was used for this dissertation to replace the default Sun

SSLSocketFactory

with a custom implementation. The

CustomSSLSocketFactory

class

was registered with the JVM using the following command:

Protocol.registerProtocol("https",

new Protocol("https", new CustomSSLSocketFactory(), 9443));

175

D.2. Custom SSLSocketFactory

public

class CustomSSLSocketFactory implements ProtocolSocketFactory {

...

@Override public Socket createSocket(String host, int port, InetAddress localAddress, int localPort, HttpConnectionParams params){ if(params.getConnectionTimeout() == 0){ return createSSLContext().getSocketFactory() .createSocket(host, port, localAddress, localPort); }else{ Socket socket = createSSLContext().getSocketFactory() .createSocket(); SocketAddress localaddr = new InetSocketAddress(localAddress, localPort); SocketAddress remoteaddr = new InetSocketAddress(host, port); socket.bind(localaddr); socket.connect(remoteaddr, params.getConnectionTimeout()); return socket;
} }

private

SSLContext createSSLContext() { try { String keyStoreFile = System.getProperty( "javax.net.ssl.keyStore"); char[] keyStorePassword = System.getProperty( "javax.net.ssl.keyStorePassword").toCharArray(); KeyStore keystore = KeyStore.getInstance("JKS"); keystore.load(new FileInputStream(keyStoreFile), keyStorePassword); KeyManagerFactory factory = KeyManagerFactory.getInstance( KeyManagerFactory.getDefaultAlgorithm()); factory.init(keystore, keyStorePassword); SSLContext context = SSLContext.getInstance("SSL"); context.init(factory.getKeyManagers(), null, null); return context; }catch(Exception e) { throw new RuntimeException("Failed creating SSL context.", e);
}

} }

Figure D.6:

SSLSocketFactory Implementation

176

Appendix E

X.509 Proxy Certicate

Figure E.1 depicts the contents of a typical X.509 proxy certicate. However, in order to get the default Java

X509TrustManager

implementation to validate it, a basic constraint has been added to

this certicate that makes it appear as a CA rather than an end-entity certicate. This is only required if the default implementation is used instead of a custom trust manager implementation presented in Appendix D.

177

Certificate: Data: Serial Signature Issuer: Validity NotBefore NotAfter Subject: Subject : Dec 26 02:46:52 2007 GMT : Nov 3 02:46:52 2017 GMT Version: 3 (0x2)

Number: 2 (0x2) Algorithm: sha1WithRSAEncryption C=AU, ST=ACT, L=Canberra, O=UNSW@ADFA, OU=IT&EE, CN=CA

C=AU, ST=ACT, O=UNSW@ADFA, OU=IT&EE, CN=Grigori Goldman Public Key Info: Public RSA Key Algorithm: rsaEncryption Public Key: (1024 bit) Modulus (1024 bit): 00:b9:b0:7a:66:e6:c4:c9:96:22:b1:59:5c:78:eb: 1e:45:e8:1f:c7:06:5f:4a:a9:49:0d:6e:c0:81:e3: db:07:1c:9f:2a:39:f2:98:3a:2d:21:89:f2:7f:cd: fc:d2:1b:9f:e9:e1:ca:40:80:98:82:42:13:3b:77: 29:fc:fc:53:14:9c:d9:dc:61:77:a9:9d:23:db:a2: 4b:a1:b2:d7:6c:86:17:8f:ca:32:fe:9c:88:29:70: 86:42:ca:98:d4:a5:4f:28:c8:c2:af:b9:73:d2:36: 89:9f:76:2c:20:de:2d:f9:63:62:e0:32:c8:21:cb: e4:a6:99:55:3a:88:8c:40:2b Exponent: 65537 (0x10001) extensions: X509v3 Subject Key Identifier: 4B:DF:FE:A1:8F:A1:A6:E5:E6:38:01:53:D2:2C:57:DD:11:4C:79:D2 X509v3 Authority Key Identifier: keyid:AD:A2:5D:CD:53:40:84:C2:F7:B1:F6:D9:3F:A7:35:AD:C9:31:C5:6A DirName:/C=AU/ST=ACT/L=Canberra/O=UNSW@ADFA/OU=IT&EE/CN=CA serial:A6:4E:50:30:A2:7C:53:6A

X509v3

X509v3
Signature

Basic Constraints: CA:TRUE

Algorithm: sha1WithRSAEncryption 78:d6:14:77:4c:d1:fe:8e:3f:5d:06:ea:cb:95:6c:3b:a3:7e: 61:6f:44:cd:78:d4:46:62:67:0e:d9:1a:d8:2e:20:56:ea:cf: 65:a3:95:6b:d9:2d:45:2c:9e:26:92:56:bd:a9:00:fb:ef:ec: 0f:63:67:a4:f8:e5:47:e0:58:99:61:d1:d9:c6:5f:01:74:a6: 5b:e5:49:20:06:21:f7:05:9e:38:2d:29:53:3e:61:97:a1:72: c1:e4:93:f6:df:c5:fe:8f:0e:56:89:05:f1:66:e1:db:26:9d: e7:ab:25:db:0e:93:12:f4:8e:a2:da:65:88:d7:2d:4f:ca:2d: ef:01:21:41:cf:21:60:49:ec:a9:c2:1f:5a:0d:0f:bb:72:fd: 06:aa:45:a5:2f:ef:73:1f:22:b1:16:c7:51:38:fc:f5:8d:65: e8:05:c7:56:db:8e:dc:7c:7d:32:56:e7:24:7e:2d:e7:58:c6: 7a:60:01:29:54:b1:dc:4d:78:c7:06:07:f1:64:2a:7c:43:39: c2:18:6a:c5:b9:f9:af:95:a9:8b:c2:ba:ef:1c:33:cd:07:77: d5:4a:d4:64:42:33:42:f9:02:77:74:65:47:95:42:74:aa:b6: 94:b1:eb:13:bf:82:59:93:b1:9f:ce:ea:d3:b2:67:1f:a7:ae: 63:13:c3:e0

Figure E.1:

X.509 CA Certicate

178

Appendix F

JavaScript to Java Bridge

Java uses the concept of a security policy to protect the application environment. Each application is executed within a sandbox environment with a policy dictating which permissions are available to the executing code. When running Java code within the browser environment, the permissions granted to such code are particularly restrictive. For example, access to the le system is completely prohibited. This security measure was introduced to protect user environments from malicious code downloaded from the Internet. The Proxy Certicate Signing Tool presented in this thesis requires unrestricted access to the host operating system and disk so that it can perform such operations as reading keystore les, adding new security providers, and much more. To accomplish this, a new Java security policy was implemented that assigned AllPermission to the Java code thus eectively giving it unrestricted access to the user's machine. Figure F.1 demonstrates how to implement such a security policy in practice.

public

class WDFSecurityPolicy extends Policy { @Override public

{

PermissionCollection getPermissions(CodeSource codeSource) PermissionCollection pc = new Permissions(); pc.add(new AllPermission()); return pc;

} }

Figure F.1:

Java Policy Example

179

_new:

function(className) { var var return classLoader = new Packages.java.net.URLClassLoader( [/* classpath array */] ); classRef = Packages.java.lang.Class.forName(className, true, classLoader); classRef.newInstance();

Figure F.2:

Creating Java objects in JavaScript

To use this policy instead of the default one, the JavaScript making Java method calls must rst load and initialise it by making the following invocation:

Packages.java.security.Policy.setPolicy(this._new("au.gov.adfa.unsw.wdf.WDFSecurityPolicy"));
The JavaScript function

_new

used in the above expression takes as its argument a class name

string and returns an instance of that class which it created using Java reection API. It is implemented as per Figure F.2. This function implements the necessary logic for instantiating any Java object within the JavaScript environment. As such, it was reused for creating the

au.gov.adfa.unsw.wdf.builder.ProxyCertBuilder
example).

class that implemented methods for proces-

sing X.509 proxy certicate requests and signing proxy certicates (see Appendix H for a complete

180

Appendix G

Proxy Certicate Signing Tool - XUL Overlays & JavaScript Code

<!----> <?xml version="1.0"?> WdfClient XUL Overlay (wdfclient.xul)

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <?xml-stylesheet href="chrome://wdfclient/skin/overlay.css" type="text/css"?> <!DOCTYPE dialog SYSTEM "chrome://wdfclient/locale/wdfclient.dtd"> <dialog xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" xmlns:html="http://www.w3.org/1999/xhtml" id="wdfclient-dialog" title="&wdfclient.title;" buttons="Close" width="700" height="600"> <script <script <script <script
...

type="application/x-javascript" src="wdfclient.js"/> type="application/x-javascript" src="policyTreeView.js"/> type="application/x-javascript" src="policyValidator.js"/> type="application/x-javascript" src="proxyCertBuilder.js"/>

181

<stringbundleset id="stringbundleset"> <stringbundle id="wdfclient-strings" src="chrome://wdfclient/locale/wdfclient.properties"/> </stringbundleset> <vbox id="wdfclient-policy" flex="1"> <groupbox> <caption class="heading" label="&wdfclient.groupbox.message;"/> <html:div id="wdfclient.groupbox.message"/> </groupbox> <separator class="thin"/> <groupbox> <caption class="heading" label="&wdfclient.groupbox.certreqinfo;"/> <grid> <columns><column/><column/></columns> <rows> <row> <label class="heading" value="&wdfclient.label.certsubject;:"/> <label id="wdfclient.label.certsubject"/> </row> <row> <label class="heading" value="&wdfclient.label.certversion;:"/> <label id="wdfclient.label.certversion"/> </row> <row> <label class="heading" value="&wdfclient.label.certexpires;:"/> <label id="wdfclient.label.certexpires"/> </row> </rows> </grid> </groupbox> <separator class="thin"/>
...

182

Appendix G. Proxy Certicate Signing Tool - XUL Overlays & JavaScript Code

<groupbox flex="1"> <caption class="heading" label="&wdfclient.groupbox.certpolicyinfo;"/> <grid> <columns><column/><column/></columns> <rows> <row> <label <label <row> <label <label </rows>

class="heading" value="&wdfclient.label.merchantdn;:"/> id="wdfclient.label.merchantdn"/> class="heading" value="&wdfclient.label.paymentgatewaydn;:"/> id="wdfclient.label.paymentgatewaydn"/>

</row>

</row> </grid> <label

class="heading" value="&wdfclient.label.paymentdescription;:"/>

<description id="wdfclient.label.paymentdescription"/> <separator class="thin"/> <tabbox flex="1"> <tabs> <tab <tab label="View Policy"/> label="View XML Policy"/>

</tabs> <tabpanels flex="1"> <tabpanel orient="vertical"> <tree id="wdfclient-policy-tree" flex="1" hidecolumnpicker="true" onselect="policyTreeView.selectionChanged()"> <treecols> <treecol primary="true" flex="1" label="&wdfclient.treecol.policy;"/> </treecols> <treechildren/> </tree> <separator class="thin"/>
... ... ...

183

... ...

<grid> <columns><column/><column/></columns> <rows> <row> <label value="Status:"/> <label id="tree.messages.1" value="OK" class="status-normal" onchange="document. getElementById('tree.messages.2') .value = this.value;"/> </row> </rows> </grid> </tabpanel> <tabpanel orient="vertical"> <textbox id="wdfclient.textbox.policy" multiline="true" readonly="true" flex="1"/> <separator class="thin"/> <grid> <columns><column/><column/></columns> <rows> <row> <label value="Status:"/> <label id="tree.messages.2" value="OK" class="status-normal"/> </row> </rows> </grid> </tabpanel> </tabpanels> </tabbox> </groupbox> </vbox> <hbox align="right" valign="middle"> <button id="wdfclient-sign" label="&wdfclient.button.sign;" oncommand="wdfclient.sign();"/> <button id="wdfclient-reject" label="&wdfclient.button.reject;" disabled="true"/> <separator class="thin" flex="1"/> <button id="wdfclient-close" label="&wdfclient.button.close;" oncommand="window.close();"/> </hbox> </dialog>

184

Appendix G. Proxy Certicate Signing Tool - XUL Overlays & JavaScript Code

/** * */ var wdfclient = { onload: function(e) { var params = window.arguments[0]; this._setHostName(params); proxyCertBuilder.onload(e); this.proxyCertReq = params != null ? params.inn.proxyCertReq : null; if (this.proxyCertReq != null) { var proxyCertInfo = proxyCertBuilder .getProxyCertInfo(this.proxyCertReq); this._setProxyCertInfo(proxyCertInfo); policyTreeView.onload( proxyCertInfo[proxyCertBuilder.policy]); }else { document.getElementById("wdfclient-sign").disabled = true; this._setStatus(); } }, sign: function() { var params = { password : null}; window.openDialog( "chrome://wdfclient/content/keystorePassword.xul", "","chrome,centerscreen,modal,dialog",params) .focus(); if (params.password != null) { var prefs = Components .classes["@mozilla.org/preferences-service;1"] .getService(Components.interfaces.nsIPrefBranch); var keystore = prefs.getCharPref( "wdfclient.preference.keystore"); var proxyCert = proxyCertBuilder.signProxyCert( this.proxyCertReq, keystore, params.password); window.arguments[0].out = {proxyCert: proxyCert}; window.close(); } },...
185

Wdfclient JavaScript (wdfclient.js)

...

_setHostName: function(params) { var stringbundle = document .getElementById("wdfclient-strings"); var host = [params != null && params.inn.hostname != null ? params.inn.hostname : "[missing server information]"]; var elem = document.getElementById( "wdfclient.groupbox.message"); elem.innerHTML = stringbundle.getFormattedString( "wdfclient.groupbox.message", host); }, _setProxyCertInfo: function(proxyCertInfo) { var sbj = document.getElementById( "wdfclient.label.certsubject"); sbj.value = proxyCertInfo[proxyCertBuilder.subject]; var ver = document .getElementById("wdfclient.label.certversion"); ver.value = proxyCertInfo[proxyCertBuilder.version]; var exp = document .getElementById("wdfclient.label.certexpires"); exp.value = proxyCertInfo[proxyCertBuilder.expiry]; var pol = document .getElementById("wdfclient.textbox.policy"); pol.value=proxyCertInfo[proxyCertBuilder.policy]; }, _setStatus: function() { var statusbar1 = document.getElementById("tree.messages.1"); var statusbar2 = document.getElementById("tree.messages.2"); statusbar1.className = "status-error"; statusbar2.className = statusbar1.className; statusbar1.value = "Failed to find proxy certificate request in HTTP header."; statusbar2.value = statusbar1.value;
}

}; window.addEventListener("load", function(e) { wdfclient.onload(e); }, false);

186

Appendix G. Proxy Certicate Signing Tool - XUL Overlays & JavaScript Code

<!----> <?xml version="1.0" encoding="UTF-8"?> Options XUL Overlay (options.xul)

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <?xml-stylesheet href="chrome://wdfclient/skin/overlay.css" type="text/css"?> <!DOCTYPE prefwindow SYSTEM "chrome://wdfclient/locale/prefwindow.dtd"> <prefwindow id="wdfclient.preferences" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" title="&prefwindow.title;"> <script src="options.js"/> <preferences> <preference id="keystore" name="wdfclient.preference.keystore" type="string"/> </preferences> <groupbox> <caption class="heading" label="&prefwindow.label;"/> <label control="textstringpref"> &wdfclient.label.keystore; </label> <grid> <columns><column/><column/></columns> <rows><row> <textbox id="keystore.textbox" preference="keystore" size="50"/> <button label="&wdfclient.button.open;" oncommand="options.openFile(event)"/> </row></rows> </grid> </groupbox> </prefpane> </prefwindow> <prefpane>

187

/** * */ const var nsIFilePicker = Components.interfaces.nsIFilePicker; options = { onLoad: }, openFile: function(e) { var fp = Components.classes["@mozilla.org/filepicker;1"] .createInstance(nsIFilePicker); fp.appendFilter("Bouncy Castle Keystore (*.bks)", "*.bks"); fp.appendFilter("Java Keystore (*.jks)", "*.jks"); fp.init(window, "Choose keystore file", nsIFilePicker.modeOpen); var rv = fp.show(); if (rv == nsIFilePicker.returnOK || rv == nsIFilePicker.returnReplace) { document.getElementById("keystore").value = fp.file.path; document.getElementById("keystore.textbox").value = fp.file.path; } } }; window.addEventListener("load", function(e) { options.onLoad(e); }, false); function(e) { this.initialized = true; Options JavaScript (options.js)

188

Appendix G. Proxy Certicate Signing Tool - XUL Overlays & JavaScript Code

<!----> <?xml version="1.0"?> KeystorePassword XUL Overlay (keystorePassword.xul)

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <!DOCTYPE dialog SYSTEM "chrome://wdfclient/locale/keystorePassword.dtd"> <dialog title="&keystorePassword.title;" buttons="Close" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <script <vbox type="application/x-javascript" src="keystorePassword.js"/> flex="1"> <grid> <columns><column/><column/></columns> <rows> <row> <label value="&keystorePassword.label;:"/> <textbox id="keystore.password" type="password"/> </row> </rows> </grid> </vbox> <separator class="thin"/> <hbox align="right" valign="middle"> <button <button </hbox> </dialog> label="&keystorePassword.ok.label;" oncommand="keystorePassword.onOK()"/> label="&keystorePassword.cancel.label;" oncommand="window.close()"/>

189

/** * */ var keystorePassword = { onOK: function() { window.arguments[0].password = document.getElementById("keystore.password").value; window.close(); } }; KeystorePassword JavaScript (keystorePassword.js)

190

Appendix H

Proxy Certicate Signing Tool - Core Java & JavaScript Code

/** * */ const const const const var WDFCLIENT_APP_ID = "wdfclient@wdfclient.com"; WDFSECURITY_POLICY_CLASS = "au.gov.adfa.unsw.wdf.WDFSecurityPolicy"; PROXYCERT_BUILDER_CLASS = "au.gov.adfa.unsw.wdf.builder.ProxyCertBuilder"; nsIExtensionManager = Components.classes["@mozilla.org/extensions/manager;1"] .getService(Components.interfaces.nsIExtensionManager); proxyCertBuilder = { subject: 0, expiry: policy:
...

ProxyCertBuilder JavaScript (proxyCertBuilder.js)

1, 3,

version: 2,

191

...

onload:

function(e) { this.classloader = new Packages.java.net.URLClassLoader( this._classpath()); this.certbuilder = this._new(PROXYCERT_BUILDER_CLASS); Packages.java.security.Policy.setPolicy( this._new(WDFSECURITY_POLICY_CLASS));

}, getProxyCertInfo: function(proxyCertReq) { return }, signProxyCert: function(proxyCertReq, keystore, password) { return }, _new: function(className) { var return }, _classpath: function() { var var var var for } return },
...

this.certbuilder.getProxyCertInfo(proxyCertReq);

this.certbuilder.signProxyCert( proxyCertReq, keystore, password);

classRef = Packages.java.lang.Class.forName( className, true, this.classloader); classRef.newInstance();

ext = nsIExtensionManager .getInstallLocation(WDFCLIENT_APP_ID) .getItemLocation(WDFCLIENT_APP_ID); libDir = new Packages.java.io.File( ext.path + "/content/lib"); listOfJars = libDir.listFiles(); classpath = new Array(); (i = 0; i < listOfJars.length; i++) { classpath[i] = listOfJars[i].toURL(); this._toJavaUrlArray(classpath);

192

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

...

/* From 'SIMILE lab' http://simile.mit.edu/repository/java-firefox-extension/ firefox/chrome/content/scripts/browser-overlay.js */ _toJavaUrlArray: function(a) { var var for dummyUrl = new java.net.URL( "http://gaggle.systemsbiology.org"); urlArray = java.lang.reflect.Array.newInstance( dummyUrl.getClass(), a.length); (var i = 0; i < a.length; i++) { var url = a[i]; java.lang.reflect.Array.set(urlArray, i, (typeof url == "string") ? new java.net.URL(url) : url); urlArray;

} return } };

193

/** * */ public class ProxyCertBuilder { public static String signProxyCert( String proxyCertReq, String keyStoreFile, String password) throws Exception { KeyStore keyStore = loadKeyStore(keyStoreFile, password); PrivateKey privateKey = getPrivateKey(keyStore, password); X509Certificate[] issuerCert = getCertificateChain(keyStore); PKCS10CertificationRequest certReq = DERCertificateDecoder .decodeCertificateRequest(proxyCertReq); X509Certificate x509Cert = X509ProxyCertificateFactory .createProxyCertificate(issuerCert[0], privateKey, certReq, "proxy"); List<X509Certificate> chain = new ArrayList<X509Certificate>(); chain.add(x509Cert); chain.addAll(Arrays.asList(issuerCert)); return DERCertificateEncoder.encodeCertificatePath(chain);
}

ProxyCertBuilder Java Class

public

static String[] getProxyCertInfo(String proxyCertReq) throws Exception { String[] proxyCertInfo = new String[4]; PKCS10CertificationRequest certReq = DERCertificateDecoder .decodeCertificateRequest(proxyCertReq); CertificationRequestInfo certReqInfo = certReq .getCertificationRequestInfo(); proxyCertInfo[0] = certReqInfo.getSubject().toString(); proxyCertInfo[1] = ; // get end date from user cert on signing proxyCertInfo[2] = 3; ProxyCertInfo certInfo = X509ProxyCertificateRequestFactory .getProxyCertInfo(certReq); proxyCertInfo[3] = certInfo.getProxyPolicy().getPolicyAsString(); return proxyCertInfo;

} ...

194

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

...

private

static KeyStore loadKeyStore( String keyStoreFile, String password) throws Exception { KeyStore keyStore = KeyStore.getInstance("BKS", "BC"); keyStore.load(new FileInputStream(keyStoreFile), password.toCharArray()); return keyStore;

private

static X509Certificate[] getCertificateChain(KeyStore keyStore) throws Exception { Certificate[] certs = keyStore.getCertificateChain("cert"); if (certs != null && certs.length > 0) { int certCount = 0; X509Certificate[] x509certs = new X509Certificate[certs.length]; for (Certificate cert : certs) { x509certs[certCount++] = (X509Certificate) cert;
}

return }else{ throw

} }

x509certs; new Exception("Failed to obtain user certificate from keystore with ID 'cert'");

private

static PrivateKey getPrivateKey(KeyStore keyStore, String password) { try (PrivateKey) keyStore.getKey("cert", password.toCharArray()); (Exception e) { throw new Exception("Failed to retrieve private key from keystore"); { return

}catch

} } }

195

/** * */ var ProxyCertReqObserver = { observe: function(oHttp, aTopic, aData) { oHttp.QueryInterface(Components.interfaces.nsIHttpChannel); var wwwAuth = null; try { wwwAuth = oHttp.getResponseHeader("WWW-Authenticate"); }catch(error) { // do nothing most likely the response does not // have 'WWW-Authenticate' parameter in the // header } if (oHttp.responseStatus == 401 && wwwAuth == "ProxyCertReq") { this._open(oHttp); } }, onMenuItemOpenCommand: function(e) { this._open(null); }, onMenuItemOptionsCommand: function(e) { window.openDialog("chrome://wdfclient/content/options.xul", "", "chrome,titlebar,toolbar,centerscreen,modal").focus(); },
...

ProxyCertReqObserver JavaScript (overlay.js)

196

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

...

_open:

function(oHttp) { var host = oHttp != null ? oHttp.getRequestHeader("Host") : null; var params = { inn: { hostname: host != null ? host.substring(0, host.indexOf(":")) : null, proxyCertReq: oHttp != null ? oHttp.getResponseHeader("X-ProxyCertReq") : null }, out: { proxyCert: null } }; window.openDialog("chrome://wdfclient/content/wdfclient.xul", "", "chrome,dialog,modal,resizable=yes,centerscreen", params).focus(); if (oHttp != null) { this._send(oHttp, params.out.proxyCert); }

}, _send: function(oHttp, proxyCert) { var postData = Components.classes["@mozilla.org/network/mime-input-stream;1"] .createInstance(Components.interfaces.nsIMIMEInputStream); postData.addHeader("Authorization", "ProxyCert"); postData.addHeader("X-ProxyCert", proxyCert); loadURI(oHttp.name, null, postData); } }; Components.classes["@mozilla.org/observer-service;1"] .getService(Components.interfaces.nsIObserverService) .addObserver(ProxyCertReqObserver, "http-on-examine-response", false);

197

/** * */ const var XML_PAY_ATTRIBUTES = ["currency", "amount", "limit", "on"]; policyValidator = { validatePolicyStructure: function(dom) { return }, validatePayAttributes: function(payelem) { var if attrs = payelem.attributes; (attrs == null || attrs.length == 0) { return {text: "PAY instruction does not have any parameters.", type: "error"}; (j = 0; j < attrs.length; j++) { if (XML_PAY_ATTRIBUTES.indexOf(attrs[j].name) == -1) { return {text: "PAY instruction contains an unknown parameter: " + attrs[j].name, type: "warn"}; } limit = attrs["limit"], amount = attrs["amount"]; (limit != null && amount != null) { return {text: "PAY instruction must not define both AMOUNT and LIMIT parameters.", type: "error"}; (limit != null && isNaN(limit.value)) { return {text: "PAY instruction LIMIT parameter must be numeric.", type: "error"}; (amount != null && isNaN(amount.value)) { return {text: "PAY instruction AMOUNT parameter must be numeric.", type: "error"}; this._checkPaymentPolicy(dom); PolicyValidator JavaScript (policyValidator.js)

} for

} var if

} if

} if

} ... ...

198

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

... ...

if

(attrs["currency"] == null) { return {text: "PAY instruction does not contain CURRENCY parameter.", type: "error"}; (attrs["on"] == null) { return {text: "PAY instruction does not contain ON parameter.", type: "error"};

if

} }, _checkPaymentPolicy: function(dom) { var if policy = dom.getElementsByTagName("payment-policy"); (policy == null || policy.length != 1) { return {text: "Policy document is invalid.", type: "error"}; (policy.item(0).attributes["merchant-dn"] == null) { return {text: "Policy document does not contain merchant-dn attribute.", type: "error"}; (policy.item(0).attributes["payment-gateway-dn"] == null) { return {text: "Policy document does not contain payment-gateway-dn attribute.", type: "error"}; payelems = policy.item(0).getElementsByTagName("pay"); (payelems == null || payelems.length == 0) { return {text: "Policy document does not contain PAY instructions.", type: "error"};

} if

} if

} var if

}
... ...

199

... ...

var var for

ppCount = 0; cpCount = 0; (k = 0; k < payelems.length; k++) { var payelem = payelems.item(k); if (payelem.parentNode.tagName == "payment-policy") { ppCount++; }else if (payelem.parentNode.tagName == "cancellation-policy") { cpCount++; } (ppCount == 0) { return {text: "Policy document does not contain PAY instructions.", type: "error"}; cancellations = dom .getElementsByTagName("cancellation-policy"); (cancellations != null && cancellations.length == 1 && cpCount == 0) { return {text: "Cancellation policy does not contain PAY instructions.", type: "error"};

} if

var if

} } };

200

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

/** * */ const const const const const STATUS_ERROR = "status-error"; const STATUS_WARNING = "status-warning"; DAYOFWEEK_ARRAY = ["", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"]; DAYOFWEEK_MAP = { SUN: "Sunday", MON: "Monday", TUE: "Tuesday", WED: "Wednesday", THU: "Thursday", FRI: "Friday", SAT: "Saturday" }; MONTH_ARRAY = ["", "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"]; MONTH_MAP = { JAN: "January", FEB: "February", MAR: "March", APR: "April", MAY: "May", JUN: "June", JUL: "July", AUG: "August", SEP: "September", OCT: "October", NOV: "November", DEC: "December" }; PolicyTreeView JavaScript (policyTreeView.js)

function TreeNode() { this.level = 0; this.label = ""; this.container = false; this.open = false; this.error = null; this.haserrors = function() { return }
}

this.error != null;

var

policyTreeView = { onload: function(xml) { var var var var var var var
...

dom = new DOMParser().parseFromString(xml,"text/xml"); policies = new Array(); cancelpolicies = new Array(); validationerrors = new Array(); errors = false; warnings = false; validationresult = policyValidator .validatePolicyStructure(dom);

...

201

... ...

if

(validationresult != null) { var statusbar = document .getElementById("tree.messages"); statusbar.value = validationresult.text; statusbar.className = "status-error"; return;

policy = dom.getElementsByTagName("payment-policy") .item(0); document.getElementById("wdfclient.label.merchantdn").value = policy.attributes["merchant-dn"].value; document.getElementById("wdfclient.label.paymentgatewaydn").value = policy.attributes["payment-gateway-dn"].value; var description = dom.getElementsByTagName("description"); if (description != null && description.length != 0) { document.getElementById( "wdfclient.label.paymentdescription") .appendChild(document.createTextNode( description.item(0) .firstChild.nodeValue)); } var creditCard = dom.getElementsByTagName("creditcard") .item(0); var cardholder = creditCard.attributes["cardholder"].value; var cardnumber = creditCard.attributes["cardnumber"].value; var expiry = creditCard.attributes["expiry"].value.split("-"); var cardnode = new TreeNode(); cardnode.level = 1; cardnode.label = "Debit credit card of " + cardholder + ", account number " + cardnumber + " expiring in " + MONTH_ARRAY[expiry[1]] + " of " + expiry[0]; cardnode.container = false; policies[policies.length] = cardnode;
... ...

var

202

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

... ...

var if

cancellationPolicy = dom.getElementsByTagName("cancellation-policy"); (cancellationPolicy != null) { var cancelNode = new TreeNode(); cancelNode.level = 1; cancelNode.label = "Send your cancellation requests to " + cancellationPolicy.item(0) .attributes["url"] .value; cancelNode.container = false; cancelpolicies[cancelpolicies.length] = cancelNode; elems = dom.getElementsByTagName("pay"); (i = 0; i < elems.length; i++) { var node = new TreeNode(); node.level = 1; node.label = "pay"; node.container = true; node.open = true; var elem = elems.item(i); var subnode = new TreeNode(); subnode.level = 2; subnode.label = this._toNodeLabel(elem.attributes); node.error = policyValidator.validatePayAttributes(elem); if (!errors) { errors = node.error != null && node.error.type == "error"; } if (!warnings) { warnings = node.error != null && node.error.type == "warn"; } if (elem.parentNode.tagName == "payment-policy") { policies[policies.length] = node; policies[policies.length] = subnode; }else { cancelpolicies[cancelpolicies.length] = node; cancelpolicies[cancelpolicies.length] = subnode; }

var for

} ... ... 203

... ...

this.treeData = new Array(); if (policies.length > 0) { var node = new TreeNode(); node.label = "payment-policy"; node.container = true; node.open = true; this.treeData[0] = node; this.treeData = this.treeData.concat(policies);
}

if

(cancelpolicies.length > 0) { var node = new TreeNode(); node.label = "cancellation-policy"; node.container = true; node.open = true; this.treeData[this.treeData.length] = node; this.treeData = this.treeData.concat(cancelpolicies);

} this.visibleData = new Array(); this.visibleData = this.visibleData.concat(this.treeData); document.getElementById("wdfclient-policy-tree").view = policyTreeView; if (errors || warnings) { var statusbar1 = document.getElementById( "tree.messages.1"); var statusbar2 = document.getElementById( "tree.messages.2"); statusbar1.value = "Policy contains " + (errors ? "errors" : "warnings") + ". Click on highlighted node(s) for details."; statusbar2.value = statusbar1.value; statusbar1.className = errors ? "status-error" : "status-warning"; statusbar2.className = statusbar1.className; document.getElementById("wdfclient-sign").disabled = true; } },
...

204

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

...

_toOnLabel: function(onattr) { var var var var var var label[0] label[1] label[2] label[3] return }, _toNodeLabel: function(attrs) { var if } if amountlabel = []; (attrs["limit"] != null) { amountlabel[0] = "upto "; (attrs["currency"] != null) { amountlabel[amountlabel.length] = attrs["currency"].value.toUpperCase(); (attrs["amount"] != null) { amountlabel[amountlabel.length] = "$" + attrs["amount"].value; else if (attrs["limit"] != null) { amountlabel[amountlabel.length] = "$" + attrs["limit"].value; label = [amountlabel.join("")]; (attrs["on"] != null) { label[1] = this._toOnLabel(attrs["on"].value); label.join(" "); cron = onattr.split(" "); dayOfMonth = cron[3]; month = cron[4]; dayOfWeek = cron[5]; year = cron.length == 7 ? cron[6] : null; label = []; = this._processDayOfMonth(dayOfMonth); = this._processDayOfWeek(dayOfWeek); = this._processMonth(month, label[0], label[1]); = this._processYear(year); label.join(" ");

} if

} var if } return },
...

205

...

_processDayOfMonth: function(dayOfMonth) { var if }else }else }else }else label = null; (dayOfMonth == "*" || dayOfMonth == "?") { if (dayOfMonth == "W") { label = "on any workday"; if (dayOfMonth == "L") { label = "on the last day"; if (dayOfMonth == "WL") { label = "on the last working day"; if (dayOfMonth.indexOf("-") != -1) { var days = dayOfMonth.split("-"); label = "on any day between day " + this._toNumLabel(days[0]) + " and " + this._toNumLabel(day[1]); if (dayOfMonth.indexOf(",") != -1) { label = "on these days " + dayOfMonth; if (dayOfMonth.indexOf("/") != -1) { var days = dayOfMonth.split("/"); label = "every " + days[1] + " days starting from day " + days[0]; if (dayOfMonth.indexOf("W") != -1) { var num = dayOfMonth.split("W")[0]; label = "on the " + this._toNumLabel(num) + " working day"; label;

}else }else

}else

return },

_toNumLabel: function(num) { var if else else else }, _toDayOfWeekLabel: function(weekday) { if else },

...

len = num.length - 1; (num[len] == "1" && num != "11") { return num + "st"; } if (num[len] == "2") { return num + "nd"; } if (num[len] == "3") { return num + "rd"; } { return num + "th"; }

(isNaN(weekday)) { return DAYOFWEEK_MAP[weekday]; } { return DAYOFWEEK_ARRAY[weekday]; }

206

Appendix H. Proxy Certicate Signing Tool - Core Java & JavaScript Code

...

_processYear: function(year) { var if }else label = null; (year == "*") { label = "of every year"; if (year.indexOf("-") != -1) { var yrs = year.split("-"); label = "of every year between " + yrs[0] + " and " + yrs[1]; if (year.indexOf(",") != -1) { label = "in the year of " + year; if (year.indexOf("/") != -1) { var yrs = year.split("/"); label = "every " + yrs[1] + " years"; { label = "in " + year; } label;

}else }else

}else return },

_processDayOfWeek: function(dayOfWeek) { var if }else label = null; (dayOfWeek == "*" || dayOfWeek == "?") { if (dayOfWeek.indexOf("-") != -1) { var day = dayOfWeek.split("-"); label = "on weekdays between " + this._toDayOfWeekLabel(day[0]) + " and " + this._toDayOfWeekLabel(day[1]); if (dayOfWeek.indexOf(",") != -1) { label = "on the following weekdays " + dayOfWeek; if (dayOfWeek.indexOf("/") != -1) { var day = dayOfWeek.split("/"); label = "every " + day[1] + " weekdays startin on " + this._toDayOfWeekLabel(day[0]); if (dayOfWeek.length == 2 && dayOfWeek[1] == "L") { label = "on the last " + this._toDayOfWeekLabel(dayOfWeek[0]); if (dayOfWeek.length == 3 && dayOfWeek[1] == "#") { label = "on the " + this._toNumLabel(dayOfWeek[2]) + " " + this._toDayOfWeekLabel(dayOfWeek[0]); label;

}else }else

}else

}else

} return },
...

207

...

_toMonthLabel: function(month) { if else }, _processMonth: function(month, dayOfMonth, dayOfWeek) { var if label = null; (month == "*") { label = (dayOfMonth != null || dayOfWeek != null ? "of " : "") + "every month"; if (month.indexOf("-") != -1) { var mnths = month.split("-"); label = (dayOfMonth != null || dayOfWeek != null ? "of " : "") + "every month between the months of " + this._toMonthLabel(mnths[0]) + " and " + this._toMonthLabel(mnths[1]); if (month.indexOf(",") != -1) { var months = month.split(","); var monthLabels = []; for (i = 0; i < months.length; i++) { monthLabels[i] = this._toMonthLabel(months[i]); } label = "in the month of " + monthLabels.join(","); if (month.indexOf("/") != -1) { var mnths = month.split("/"); label = "every " + mnths[1] + " months starting in " + this._toMonthLabel(mnths[0]); { label = "in the month of " + this._toMonthLabel(month); label; (isNaN(month)) { return MONTH_MAP[month]; } { return MONTH_ARRAY[month]; }

}else

}else

}else

}else

return
}

/* * * */ }; The rest of this module is based on tree building code described at the Mozilla Firefox Developer Center.

208

Appendix I

Merchant Payment Processing Service

/** * */ public class PaymentProcessingService { private public PaymentProcessingServiceStub paymentProcessingServiceStub; PaymentReceipt processPayment(PaymentInstruction pi) { ProcessPayment processPayment = new ProcessPayment(); processPayment.setPaymentInstruction(pi); ProcessPaymentResponse response = paymentProcessingServiceStub .processPayment(processPayment); return response.get_return();
}

PaymentProcessingService Java Class

public

void setPaymentProcessingServiceStub(PaymentProcessingServiceStub paymentProcessingServiceStub) { this.paymentProcessingServiceStub = paymentProcessingServiceStub;

public
} ...

void setKeyStore(String keyStore) { System.setProperty("javax.net.ssl.keyStore", keyStore);

209

...

public
}

void setKeyStorePassword(String password) { System.setProperty("javax.net.ssl.keyStorePassword", password);

public
}

void setTrustStore(String trustStore) { System.setProperty("javax.net.ssl.trustStore", keyStore);

public

void setTrustStorePassword(String password) { System.setProperty("javax.net.ssl.trustStorePassword", password);

public

void setKeyManagerFactoryAlgorithm(String keyFactoryAlg) { Security.setProperty("ssl.KeyManagerFactory.algorithm", keyFactoryAlg);

public

void setKeyManagerFactoryDefaultAlgorithm(String keyFactoryDefaultAlg) { System.setProperty("ssl.KeyManagerFactory.algorithm.default", keyFactoryDefaultAlg);

public
} }

void setSslProvider(Provider provider) { Security.addProvider(provider);

210

Appendix I. Merchant Payment Processing Service

/** * */ public private private private private private private private class ProxyCertHttpFilter implements Filter { static final String HTTP_HEADER_AUTHORIZATION = "Authorization"; static final String HTTP_HEADER_WWW_AUTHENTICATE = "WWW-Authenticate"; static final String HTTP_HEADER_PROXY_CERT_REQ = "X-ProxyCertReq"; static final String HTTP_HEADER_PROXY_CERT = "X-ProxyCert"; Random rand = new Random(System.currentTimeMillis()); ProxyCertHttpFilterContext context; ProxyCertRequestBuilder proxyCertRequestBuilder; public void destroy() { context = null; proxyCertRequestBuilder = null;
}

ProxyCertHTTPFilter Java Class

public

void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; HttpServletResponse httpResponse = (HttpServletResponse) response; if (isAuthorised(httpRequest)) { persistProxyCertificate(getProxyCertificate(httpRequest), httpRequest); filterChain.doFilter(request, response); }else { sendUnauthorisedResponse(httpRequest, httpResponse); }

public

void init(FilterConfig filterConfig) throws ServletException { Security.addProvider(new BouncyCastleProvider()); this.context = new ProxyCertHttpFilterContext(filterConfig); this.proxyCertRequestBuilder = new ProxyCertRequestBuilder(context, null);

} ...

211

...

private

final boolean isAuthorised(HttpServletRequest request) { boolean String if { isAuthorised = false; authorisation = request.getHeader( HTTP_HEADER_AUTHORIZATION); (authorisation != null && authorisation.equals("ProxyCert")) isAuthorised = ProxyCertValidator.validate( getProxyCertificate(request), context);
}

return
}

isAuthorised;

private

final void sendUnauthorisedResponse(HttpServletRequest request, HttpServletResponse response) throws ServletException { int String if statusCode = SC_UNAUTHORIZED; certRequest = null; (request.getHeader(HTTP_HEADER_PROXY_CERT) == null) { certRequest = createProxyCertificateRequest(request); statusCode = certRequest != null ? SC_UNAUTHORIZED : SC_INTERNAL_SERVER_ERROR;

writeToResponseBuffer(response, certRequest, statusCode);

}

private

final void persistProxyCertificate(CertPath certPath, HttpServletRequest request) throws ServletException { try { KeyPair keyPair = (KeyPair) request.getSession() .getAttribute("ProxyCertKeyPair"); Certificate[] chain = certPath.getCertificates() .toArray(new Certificate[0]); context.addEntryToKeyStore("proxy" + rand.nextInt(), keyPair.getPrivate(), chain); context.saveKeyStore(); request.getSession().removeAttribute(PROXY_CERT_KEY_PAIR); (Exception e) { throw new ServletException(e);

}catch }
} ...

212

Appendix I. Merchant Payment Processing Service

...

private

final String createProxyCertificateRequest(HttpServletRequest request) throws ServletException { try proxyCertKeyPair = KeyPairFactory .generateRSAKeyPair(); persistProxyCertKeyPairInSession(proxyCertKeyPair, request); return proxyCertRequestBuilder .createProxyCertificateRequest( proxyCertKeyPair); (IOException e) { throw new ServletException("Failed to Base64 encode new proxy certificate request.", e); (NoSuchAlgorithmException e) { throw new ServletException( "Failed to create a new RSA key pair needed for creating proxy certificate request.", e); (X509CertificateException e) { throw new ServletException("Failed to create a new proxy certificate request.", e); { KeyPair

}catch

}catch

}catch

} }

private

final void writeToResponseBuffer(HttpServletResponse response, String certRequest, int statusCode) throws ServletException { response.setStatus(statusCode); response.setContentLength(0); if (statusCode == SC_UNAUTHORIZED && certRequest != null) { response.setHeader(HTTP_HEADER_WWW_AUTHENTICATE, "ProxyCertReq"); response.setHeader(HTTP_HEADER_PROXY_CERT_REQ, certRequest);
}

try }catch

{ response.flushBuffer(); (IOException e) { throw new ServletException("Failed while writing response content to buffer.", e);

} } ...

213

...

private

static final CertPath getProxyCertificate(HttpServletRequest request) { CertPath certPath = null; String proxyCert = request.getHeader(HTTP_HEADER_PROXY_CERT); if (!StringUtils.isBlank(proxyCert)) { try { certPath = DERCertificateDecoder .decodeCertificatePath(proxyCert); }catch (CertificateException e) { }
}

return
}

certPath;

private

static final void persistProxyCertKeyPairInSession(KeyPair proxyCertKeyPair, HttpServletRequest request) { request.getSession().setAttribute(PROXY_CERT_KEY_PAIR, proxyCertKeyPair);

} }

214

Appendix I. Merchant Payment Processing Service

/** * */ public class ProxyCertRequestBuilder { private private private public static final String PROXY_CERT_SUBJECT_DN = "CN=proxy"; String subjectDn; ProxyCertHttpFilterContext context; ProxyCertRequestBuilder(ProxyCertHttpFilterContext context, String subjectDn) { this.context = context; this.subjectDn = subjectDn != null ? PROXY_CERT_SUBJECT_DN;
}

ProxyCertRequestBuilder Java Class

subjectDn :

public

String createProxyCertificateRequest(KeyPair keyPair) throws IOException, X509CertificateException { String policyLanguageOid = context.getPolicy() != null ? context.getPolicyOID() : INDEPENDENT.getId(); PKCS10CertificationRequest certRequest = X509ProxyCertificateRequestFactory .createProxyCertificateRequest( context.getSignatureAlgorithm(), subjectDn, keyPair, policyLanguageOid, context.getPolicy().getBytes()); return DERCertificateEncoder.encodeCertificateRequest( certRequest);

}
}

215

/** * */ public class X509ProxyCertificateRequestFactory { public static PKCS10CertificationRequest createProxyCertificateRequest( String signatureAlgorithm, String subject, KeyPair keyPair, String policyLanguageOid, byte[] policy) throws X509CertificateException { try { ProxyPolicy proxyPolicy = new ProxyPolicy( policyLanguageOid, policy); ProxyCertInfo proxyCertInfo = new ProxyCertInfo( 1, proxyPolicy); Attribute proxyCertAttr = addExtensionToAttribute( proxyCertInfo); return new PKCS10CertificationRequest( signatureAlgorithm, new X509Name(subject), keyPair.getPublic(), new DERSet(proxyCertAttr), keyPair.getPrivate()); (Exception e) { throw new X509CertificateException( ErrorCode.CERT_REQ_CREATE_ERROR, e); X509ProxyCertificateRequestFactory Java Class

}catch

}
}

public

static ProxyCertInfo getProxyCertInfo(PKCS10CertificationRequest certRequest) throws IOException { ProxyCertInfo proxyCertInfo = null; Attribute attribute = getAttributeByType(certRequest, PKCSObjectIdentifiers.pkcs_9_at_extensionRequest); if (attribute != null) { X509Extension extension = getExtensionByOID(attribute, ProxyCertInfo.OID); if (extension != null) { proxyCertInfo = ProxyCertInfo.getInstance( BouncyCastleUtil.getExtensionObject( extension)); }
}

return
} ...

proxyCertInfo;

216

Appendix I. Merchant Payment Processing Service

...

private

static Attribute getAttributeByType(PKCS10CertificationRequest certRequest, DERObjectIdentifier attrType) { Attribute attribute = null; ASN1Set attributes = certRequest.getCertificationRequestInfo() .getAttributes(); if (attributes != null && attributes.size() > 0) { for (int i = 0; i < attributes.size(); i++) { Attribute attr = Attribute.getInstance( attributes.getObjectAt(i)); if (attr.getAttrType().equals(attrType)) { attribute = attr; break;
} } }

return
}

attribute;

private

static X509Extension getExtensionByOID(Attribute attribute, DERObjectIdentifier oid) { X509Extensions extensions = X509Extensions.getInstance( attribute.getAttrValues().getObjectAt(0)); return extensions != null ? extensions.getExtension(oid) : null;

private

static Attribute addExtensionToAttribute(ProxyCertInfo proxyCertInfo) { Hashtable<DERObjectIdentifier, X509Extension> extensions = new Hashtable<DERObjectIdentifier, X509Extension>(1); extensions.put(ProxyCertInfo.OID, new X509Extension(true, new DEROctetString(proxyCertInfo))); DERSet proxyExtensionSet = new DERSet(new X509Extensions(extensions)); return new Attribute( PKCSObjectIdentifiers.pkcs_9_at_extensionRequest, proxyExtensionSet);

} }

217

/** * */ public class X509ProxyCertificateFactory { public static X509Certificate createProxyCertificate(X509Certificate issuerCert, PrivateKey issuerKey, PKCS10CertificationRequest certRequest, String cnValue) throws X509CertificateException { try { ProxyCertInfo proxyCertInfo = X509ProxyCertificateRequestFactory .getProxyCertInfo(certRequest); BasicConstraints basicConstraints = new BasicConstraints(false); X509ExtensionSet extSet = new X509ExtensionSet(); extSet.add(new X509Extension(X509Extensions .BasicConstraints.getId(), true, basicConstraints.getEncoded())); /** * HACK - Sun SSLSocketImpl class will have * issues validating proxy certificates, * therefore making this extension non-critical * so that it does not complain during * validation (also proxy issuer has to have * CA:TRUE as a basic constraint) * extSet.add(new ProxyCertInfoExtension(certInfo)); */ extSet.add(new X509Extension(ProxyCertInfo.OID.getId(), false, BouncyCastleUtil.toByteArray( proxyCertInfo.getDERObject()))); /* * zero lifetime indicates that the new * certificate will have the same lifetime * as the issuing certificate */ int lifetime = 0; X509ProxyCertificateFactory Java Class

... ... ...

218

Appendix I. Merchant Payment Processing Service

... ... ...

}catch

BouncyCastleCertProcessingFactory factory = BouncyCastleCertProcessingFactory.getDefault(); return factory.createProxyCertificate(issuerCert, issuerKey, certRequest.getPublicKey(), lifetime, GSIConstants.GSI_4_LIMITED_PROXY, extSet, cnValue); (Exception e) { throw new X509CertificateException( ErrorCode.CERT_CREATE_ERROR, e);

}
}

219

220

Appendix J

Test Results Analysis - Multiple Regression

The analysis presented in Chapter 6 indicated that there is a relationship between the number of concurrent threads and the performance of the payment gateway server. This relationship likewise extends to the authentication method used for testing. Depending on whether SSL is used and what type of certicate exchange is enabled has an impact on request processing times. These relationships can be quantied using multiple regression tests producing results that can further strengthen the arguments made in Chapter 6. The rst multiple regression test used two predictor variables to determine their eect on the criterion variable (i.e. request processing time). The rst predictor variable represented the number of concurrent threads used (i.e. authentication method. 100, 120, 140 or 160) while the second variable represented the

Considering that the authentication method is not by default quantiable

(i.e. it is not a numeric value) it was used as a dummy rating. A numeric value of -1 was used to represent No Authentication method while value 1 was used to represent the SSL server certicate authentication method. Table J.1 show results of this multiple regression test. The next multiple regression test changed the meaning of the second predictor variable. For this test, the use of server certicate versus mutual authentication was compared. The numeric representation of the authentication method was -1 for server certicate and 1 for mutual authentication. The rst predictor variable (i.e. number of concurrent threads) was unchanged. Table J.2 show results of this multiple regression test.

221

Regression Statistics
Multiple R R Square Adjusted R Square Standard Error Observations df Regression Residual Total 2 5 7 SS 7339829.6 265562.4 7605392 Standard Error 480.6654637 3.643915477 81.4804271 t Stat -0.465812539 5.524277423 10.37672519 P-value 0.660936113 0.002663076 0.00014313 Lower 99% -2161.999595 5.43730489 516.9613496 Upper 99% 1714.199595 34.82269511 1174.03865 MS 3669914.8 53112.48 0.98238605 0.965082352 0.951115293 230.4614501 8 F 69.09703331 Signicance F 0.000227831

Coecients Intercept Number of Threads SSL Method -223.9 20.13 845.5

Table J.1:

Analysis of Variance (ANOVA) - No Authentication vs Server Certicate

Regression Statistics
Multiple R R Square Adjusted R Square Standard Error Observations df Regression Residual Total 2 5 7 SS 55844418.4 3985381.6 59829800 Standard Error 1862.063907 14.11627005 315.6493941 t Stat -1.051682487 4.088190422 7.303989943 P-value 0.341093458 0.009463576 0.000753373 Lower 99% -9466.360335 0.791541488 1032.764576 Upper 99% 5549.760335 114.6284585 3578.235424 MS 27922209.2 797076.32 0.966120084 0.933388017 0.906743224 892.7913082 8 F 35.03078501 Signicance F 0.001145199

Coecients Intercept Number of Threads SSL Method 2305.5 -1958.3 57.71

Table J.2:

Analysis of Variance (ANOVA) - Server Certicate vs Mutual Authentication

222

Appendix K

Additional Material
K.1 CD-ROM
This thesis includes a CD-ROM that contains various artifacts produced during the preparation of this dissertation. The contents of this CD-ROM are as follows:

1.

projects:

This directory contains Eclipse Java projects that in combination comprise the peri-

odical payment framework presented in this thesis.

(a)

wdf-client:
(

The Firefox extension implementation. This directory also contains a help le

readme.txt) that discusses how to install this extension into Firefox.

The core cryptographic libraries used by the Firefox extension, merchant and

(b)

wdf-core:

payment gateway web applications. (c)

wdf-lters:

The HTTP servlet lter used by the merchant web application to obtain proxy

certicates from customers. (d) (e)

wdf-merchant:

A J2EE merchant web application. The code and congurations required to build an Apache Axis2

wdf-payment-gateway:
web service.

(f ) (g)

wdf-policy:

The core library required to process and validate periodical payment policies. Mock merchant test application used for testing the prototype as

wdf-test-framework: archive:

well as various utility classes (e.g. code for generating test proxy certicates). (h) Already built Java archives (JAR, WAR, etc) for the above projects.

223

K.2. Note on Development Environment

2.

test-data:
prototype.

This directory contains the test data used during the performance testing of the

(a)

demoCA: This directory contains an OpenSSL demo certicate authority used to sign all
test certicates.

(b) (c)

test-user-certs:

This directory contains the pre-generated user proxy certicates. This directory contains keystore/trustore les for the merchant and

test-server-certs:

the payment gateway application servers.

3.

test-results:

This directory contains Microsoft Excel spreadsheets that were used to analyse

the test results data and prepare some of the charts.

(a)

results.xls:
etc).

This le contains the raw results data and majority of the analysis work (e.g.

averages, time series charts, Pearson's Product Moment Correlation Coecient calculations,

(b)

results-mulitpleregression.xls:
This thesis.

This le contains the results of multiple regression tests.

4.

thesis.pdf :

K.2 Note on Development Environment

Various technologies were used in the process of validating the ideas presented in this dissertation. The following table contains all of technologies that are required to re-create the development environment. Tool JDK Eclipse Europa Apache Tomcat Apache Axis2 Apache Ant Apache Maven OpenSSL Mozilla Firefox Version 1.6.0_02ea 3.3.0 6.0.14 1.3 1.6.5 2.06 0.9.8g 3.0.8

Table K.1:

Development Environment Tools

It should be noted that while newer versions of these tools are available no testing was done using them. As such, at this stage it is unknown how the existing code base will behave in an upgraded

224

Appendix K. Additional Material

environment. It is expected that some changes maybe required to get the code working on the newer platform (e.g. changing maximum version inside

install.rdf

le of the Firefox extension will be

required to get it working on the newer version of the browser, etc). Building the periodical payment framework from source requires Apache Maven. folder contains a Each project

pom.xml

le. This le denes all library dependencies that each project requires

for both compilation and execution.

225