Chapter 1

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.


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.


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. Using these technologies. 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. in order to retain focus the proposed solutions presented in this thesis are better formulated as a single hypothesis. The key element of the above hypothesis that is of particular importance is the emphasis on the currently available and industry supported technologies. With increased complexity introduced by the enhanced security and improved interoperability a slight performance overhead is to be expected. 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.1. Using tested technologies helps to minimise the risk and accelerate the implementation process. 2007) was specically criticised due to a lack of quantitative 5 . 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. Introduction 1.Chapter 1. However. standards compliant and industry supported technologies. Changes to existing nancial applications are costly due to a high level of risk associated with them. Those elements are important as they help to minimise resistance from the nancial industry stakeholders. A theoretical proposal presented at the Australasian Computer Science Conference by myself (Goldman. Another important concept presented in the above hypothesis is the performance of the proposed application. Having to deal with so many issues at once in a single dissertation is dicult. Therefore. 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. As such. It will achieve this by developing concrete solutions to the problems described previously.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. any overheads introduced should be within acceptable tolerance levels for the industry and have a linear rather than exponential impact on performance. 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). Despite enhanced security and increased interoperability. As such.

Integration of X.4). Instead. One major goal of this thesis is to question this traditional view of customer-merchant relationship and propose an alternative based solely on delegation.2. Problem Statement analysis proving viability of using delegation for electronic payments. 2.2. Delegation of payment authority using cryptographic tokens is an appealing option. Potentially it would allow customers to issue proxy credentials to merchants. hence the order of the following list is important: 1.1.2). merchant electronic commerce and payment gateway applications (see section 1. 3.2. this dissertation has a number of research goals that it attempts to address.1). 6 . Design and implementation of a payment policy language for restricting the use of delegated payment credentials (see section 1. 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.3). 4. 1. which can act as intermediary entities accessing consumer accounts on their behalf.2 Research Goals There are a number of unresolved issues with using conventional electronic payment applications for establishing direct debit agreements. Development of a reference implementation prototyping customer browser extension. It is likewise quite dicult to reuse the same applications for securely performing direct debit transactions without sacricing customer control of their own funds.1.1. such as debiting a xed dollar amount until a predened end date.2. Specically. Both past and present approaches dene customer-merchant relationship in a way that precludes delegation of authority.1.509 restricted proxy certicates into the framework designed in step 1 (see section 1. all eort is made to restrict merchants' access to information that would enable them to gain access to customer accounts. Learning from that experience.1. This concept of delegated payment credentials has not been extensively investigated in notational payment systems. Development of a theoretical model for delegation of payment credentials from customers to merchants (see section 1.1. Each goal is dependent on the successful completion of its predecessor. 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.

which could use it to withdraw funds from a user account and deposit them into 7 . That is. In general. In other words restricting the potential actions that the merchants can take. as it provides the features that are currently lacking in the existing model. 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. it was concluded that this delegation must be restricted to prevent merchants from using customer accounts in ways not originally intended.2 X. Delegation of payment tokens to merchants is a unique concept never before applied to electronic payments. a credential was issued to a service provider.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 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. That is.1. enabling the merchants to independently initiate transactions on behalf of their customers.2. 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. 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. using the proxy constructs provides a lot of exibility in the way a payment protocol is designed and implemented. This paper did not focus entirely on accounting but rather introduced various examples of practical usage of restricted proxies. 1993).1.Chapter 1. 1. Introduction 1. Proxy-based accounting is an important step towards implementing a payment protocol that can support direct debit payments. In this thesis.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.2. this concept will be examined more closely to determine how best to apply it to the problem of securing direct debit payments online. 1993) originally used this concept for securing a traditional accounts based payment model using custom delegated restricted proxies. Furthermore. That is. a mechanism is needed that would cryptographically enforce direct debit agreements established between merchants and their customers. Cliord Neuman (Neuman. Using delegation as a solution is natural. regardless of whether direct debit payments are required or not.

as they can be used as alternatives to traditional X. this particular approach did not consider all of the intricacies involved in direct debit transactions. legal aspects of using digital signatures in a periodical payment framework are considered out of scope of this dissertation. 1 Legal issues surrounding the use of digital signatures are complex and are best left to the experts. 1. it relied solely on a custom architecture for authorisation and proxy generation services. a payment policy language must be exible enough to be able to capture any possible scenario within the direct debit context.1. an investigation is required to determine the viability of this approach. The challenge is to keep this language as simple and intuitive as possible since it must be accessible to customers. customers should be able to use their certicates within their browser of choice (e. Problem Statement its own.1. which are considered to be the standard for securing communication channels online.509 restricted proxy certicates into a payment model to facilitate direct debit payments.3 Semantics and Syntax of Payment Policy The X. 8 . electronic direct debit agreements will never be considered legally 1 binding.1. Since customers are required to obtain and maintain a set of cryptographic keys and certicates. In addition. These certicates were originally invented to support delegation of authentication and authorisation credentials within grid environments (this was briey discussed in Tuecke et al. Mozilla Firefox) as this is the main interface used for establishing direct debit agreements online.g. it is important to ensure that this can be done with the currently available technology. Clearly. However. as such the use of delegation was quite limited.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. The X509 proxy certicate standard provides all of the necessary features for a policy based restricted delegation. Unless customers can read and understand each policy. As part of this research goal. The issued credential contained a set of restrictions that dened what actions the service provider was allowed/not allowed to perform.. Since no electronic standards exist dening direct debit agreements.509 certicates.2. These types of certicates can be integrated into existing payment frameworks with minimum eort. 2004). 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. as it requires a reasonably mature public key infrastructure to exist. As such. In addition. It is a goal of this dissertation to integrate 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. Another signicant advantage of the new approach is its practical use of the payment agreement for enforcing the terms during every single payment transaction. customers are required to sign an agreement.2. 2000) since it allows for a seamless integration with an existing payment infrastructure without high overheads. Introduction 1. which could be used in case of disputes.Chapter 1. delegating the right to withdraw funds from their accounts to a nominated merchant. payments are viewed as a series of linked transactions. 1.. This is made possible by using X. enforceability and non-repudiation. 9 . Instead of treating each payment transaction as a point-to-point transfer of funds. eectively preventing fraud. 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. or the electronic version where it is not even traceable or binding. This study investigates how credential delegation can improve one particular form of electronic payments commonly known as direct debit. 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. 1995. The goal is to take a similar approach as in (Bellare et al. 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. Just like in the oine direct debit process. simulating physical cash changing hands.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. 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. Unlike with the paper-based model where the agreement is only enforceable when legally disputed.1. 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.2 Thesis Statement This thesis explores the subject of authentication credential delegation in the context of electronic payment systems. This thesis takes a fundamentally dierent approach to electronic payments. the new approach actively assures that each transaction is within the agreed bounds of the policy.

• The integration of X. Either use an acquirer payment gateway or alternatively manage sensitive customer information (e. Using such policies ensures that it is no longer possible for merchants to make a mistake (intentional or otherwise) and overcharge their customers by. • 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 10 . The new proxy certicates are returned back to the caller (i. Since the merchant application needs to choose which customer's credential to use for each transaction. which can be used to enforce direct debit conditions for each transaction.509 restricted proxy certicates into a periodical payment model. This new technique allows merchants to securely gain access to consumer accounts and initiate transactions without customer intervention.e.1. Using specically certicates based on X. X. for example.1 Contribution This thesis makes a number of signicant contributions to the current state of the art in the electronic payments eld.509 restricted proxy certicates.2.g.e.2.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. Currently merchants only have two options for implementing direct debit services. 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). response header. • The design and implementation of a payment policy language for specifying conditions on the use of X. credit card details) themselves. This is the rst time an attempt has been made to translate direct debit agreements into an electronic form. merchant) via a custom HTTP • The development of a reference implementation of a merchant web application capable of obtaining signed payment credentials (i. Neither approach delivers the exibility and security of the periodical payment model discussed here. Thesis Statement 1. 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.509 restricted proxy certicates) from customers and using those credentials for initiating payment transactions via a payment gateway web services interface. initiating two transactions per month instead of only one.

The payment gateway is designed to work as a proxy between the merchant and the current payment processing infrastructure which will function unchanged. In Chapter 4 a theoretical architecture of the periodical payment framework is presented. There is a distinct lack of information available on this subject mainly due to commercial interests.3 Thesis Structure The rest of this thesis is organised as follows. For example. PayPal and Google Checkout are both introducing web services over SSL. Chapter 3 is dedicated to the analysis of the Secure Electronic Transaction (SET) protocol. the data obtained and the results documented will clearly be of value in the future. In Chapter 2. This chapter discusses all major processes within this framework. • The collection of empirical data analysing performance characteristics of the relationship between the merchant and the payment gateway. This feature works even in a multi-threaded environment with each thread capable of using a dierent digital certicate for authentication. Specic emphasis is placed on notational systems rather than digital coins as it more closely matches the approach adopted in this dissertation. however. a detailed overview of the current state of academic and commercial research in the area of electronic payments is presented. Not having benchmark data made it dicult to analyse the performance of the periodical payment 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. 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. 1. 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.Chapter 1. This protocol was collaboratively designed by numerous industry leaders including Visa and MasterCard and contains features that are similar in concept to periodical payments. Using web services is a convenient way of minimising the eort This payment required to integrate existing merchant applications into the new framework. • The development of a prototype payment gateway application built using web services as the main (and only) interface. 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. such as creation and delegation of proxy 11 . Introduction provider implements a mechanism for dynamically selecting digital certicates and their keys.

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

Chapter 2 Literature Review This chapter contains a summary of a comprehensive literature review performed across multiple electronic payment domains and related technologies. its use of X. This approach ensured that during payment transactions. 1983). Specically. This chapter concludes with a review of the security model within grid environments that was used as the foundation for security in periodical payments. It begins with a brief historic overview of the dierent electronic payment schemes proposed and implemented over three decades. 1985). As a consequence of this work. It then continues to explore notational payment schemes that were used as the basis for the implementation of the periodical payment framework presented later. a bank) and the customer (see Chaum. This work was fundamental in sparking the decade long interest in anonymous electronic payments that duplicated physical cash.1 Background As was mentioned previously in the introduction.g.509 restricted proxy certicates is examined in great detail as this concept and related technologies will be discussed throughout this dissertation. 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. Using digital tokens to represent monitory value is dicult because unlike physical cash. 2. 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. 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. tokens 13 . the research eld on electronic payments is quite mature.

Medvinsky & Neuman. that would maintain customer private information. To overcome this problem.. 1992) or all tokens that are currently in circulation but not yet deposited (e. Okamoto & Ohta. Considering that customer identity information was stored on them. 1993. 1988).1. 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. 1983). 1989. O-line schemes oer the most exibility and eciency but cannot on their own deliver doublespending detection. the authors also presented a mechanism for splitting digital tokens to facilitate giving of change. As such. 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. 1992.g. The device ensures that no personal information is leaked out during communication between the observer and the outside world. on-line and o-line. called the observer. In (Okamoto & Ohta. Okamoto & Ohta. concerns were raised regarding the amount of information that was possible to extract from tamper resistant devices. enough information is revealed for the token issuer to trace it back to the customer's account (see Chaum et al. smartcards) was introduced (see Even & Goldreich. 1993). 1994. extracting information from them would eectively eliminate anonymity and allow device providers to track customer purchases. Originally. which unconditionally protects the customer's identity. 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. 1988. As soon as the customer spends the same token for the second time. To deliver on-line double-spending prevention functionality in o-line schemes.2. There are two dierent approaches of implementing a digital token scheme. 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. 1992). 14 . Ferguson. This solution requires the provider to be constantly on-line and to keep detailed records of either all tokens that have been deposited (e. However. Background can be easily duplicated and reused. It works by using a variant of blind digital signatures. Using such hardware guarantees that tokens cannot be retrieved and duplicated without damaging the hardware that stores them.g. detection and prevention of double spending in digital token schemes was and still is the most dicult problem to solve. the concept of digital wallets with observers was rst proposed by David Chaum (Chaum.. 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. 1995). O-line schemes oer double spending detection only post-fact. as long as the token is only used once. Brands. 1992). The idea was to introduce an entity into the device.g. the concept of tamper resistant hardware (e. 1993.

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

the funds are exchanged between two parties within a single transaction. Their design is targeted specically at duplicating the model of physical cash changing hands.2. notational systems avoid the complexities of the double spending problem by never releasing funds to customers. that is. Bellare et al. however. Notational payment schemes. which could then be enhanced to support the concepts presented in this thesis. Such systems enable a more secure. which have become the predominant area of research for these types of systems. however. Camp et al. 1995. 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. provide the right paradigm for designing an electronic payment mechanism capable of supporting periodical payments although none have been developed so far. much can be learnt from their architectures. some proposed systems have attempted to re-use the existing infrastructure by providing services that use the current nancial networks for payment clearing (e. 1995. both coin and notational systems can be described as point-to-point.2 Overview of Notational Payment Schemes The term notational system was used in (Sirbu & Tygar. notational systems facilitate a more straightforward migration from the existing payment infrastructure. 2. Finally.2.. Instead. fund transfers are done on behalf of the customers by their banks. This.. 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. 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. In fact. transaction-based approach to funds transfer that can be tailored to provide traceability or anonymity where appropriate. As was stated previously. This by default implies that all funds must be committed at the time of the transaction. Overview of Notational Payment Schemes enable exchange of funds between the customer and the merchant. 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 . 2000). In general. Such approach does not t well into the periodical payments paradigm. 1995) to describe payment mechanisms that did not use digital tokens to represent monitory value. It is recognised that whilst none of the systems presented in the next section actually support periodical payments.g. which is completely opposite to the approach taken by the periodical payment model where payments can be deferred until later. raises privacy issues.

Since the NetCheque protocol does not actively attempt to solve the anonymity problem. NetCheque uses a special kind of Kerberos ticket called a proxy as a cheque signature. Using a Kerberos proxy ticket is an interesting proposal as it allows merchants to authenticate directly to customer's accounting services. Besides the obvious lack of anonymity. the cheques contain both the identity of the customer and the merchant. There are some critical issues with the NetCheque proposal. 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).. Yasushi Kawakura. In particular. The goal of these systems was to reduce the costs per transaction to ensure that they can be used for processing micro-payments. Neuman & Ts'o. 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. there are two types of notational schemes: debit-credit and secure credit card transactions. than cheques cannot be cleared 17 . It works well for the basic scenario. In this section. However.2. None of the literature reviewed so far. 1995).1 NetCheque NetCheque uses a network of distributed accounting services to manage all of the participants in electronic payment transactions. it could be used to enable periodical payments. the scheme also fails to deliver ecient. 1994. In general. Communication security is achieved using symmetric key cryptography using the Kerberos protocol (Kohl et al. directly mentions periodical payments as dened in the previous chapter. In particular. Two such systems are NetBill (Neuman & Medvinsky. in which both the customer and the merchant have accounts with the same accounting service. Literature Review intervention.Chapter 2. the clearing of the cheques can be performed in real time at a very low cost. Customers and merchants are required to open an account on one of these accounting services before issuing and accepting electronic cheques. However. 1994). Since the proxy can be restricted to a particular network address and for a particular purpose. there do exist several interesting proposals that address various other issues that can be enhanced to support the periodical payment model. 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. In this case. 2. 1995. 1999) and NetCheque (Sirbu & Tygar. real time clearing of cheques. if the participants belong to dierent accounting services. some of these systems will be presented.

2. The scheme relies on the fact that if the cheque bounces. debits the customer's account and credits the merchant. The nal step in this process. price quote is received and accepted. Hence. this protocol also does not handle anonymity issues directly.2 NetBill Unlike NetCheque.2. Its main purpose is to enable delivery of digital content rather than being used as a charging mechanism for various services. 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). which is where periodical payments are mostly needed. the customer conrms receipt of the as yet unread merchandise and at the same time authorises payment. 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. While customer identity could be protected from the merchant. 18 . 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. In addition to payment processing. periodical payments are unlikely to be supported by this protocol as it is heavily driven by the user interaction. Similar to NetCheque.e. which the merchant must forward to the customer. which are only revealed to the customer upon payment. NetBill architecture is not distributed. the purchasing phase of the protocol also involves encrypting When Once the merchandise with one-time keys. Furthermore. involves the till checking that the checksum is valid (i. 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. it is encrypted and cannot be viewed until the payment is processed. the customer receives the merchandise. Overview of Notational Payment Schemes in real time unless the merchant is willing to accept extra costs. 2. By calculating the checksum on the message and sending a signed response. The NetBill server is designed to contain accounts for everyone within the network. the chequebook sends a purchase request message. the NetBill server can still monitor all transactions and therefore link each customer to his purchases. The chequebook communicates directly with the merchant library called a till via an encrypted channel. the identity of the customer is known. The system can place a hold on the funds but cannot guarantee that the cheque will clear. The receipt returned to the merchant contains the decryption key. the NetBill protocol is designed to guarantee delivery of digital merchandise to customers.2.

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. which can be validated by both the customer and the merchant. To achieve interoperability. the gateway and the overall payment system must have complete access to all customer information in order to process transactions. 2KP proposes the use of server-side certicates (i. Furthermore. iKP uses the gateway concept to convert payment requests generated by the protocol into messages that will be understood by the clearing mechanism. It relies on traditional authentication techniques to validate customers. non-repudiation of messages originating from either the customer or the merchant is not possible. 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). 19 . Just like the protocols discussed above. The rst of the three protocols. since only the gateway is capable of signing data. 1995. certicates belonging to the merchant). Therefore.. 3KP. 2000) is another noteworthy protocol that delivers account-based.Chapter 2. Time stamping prevents the merchant from capturing and reusing encrypted payment orders. The nal protocol in the series. Clearly.e.2. Literature Review 2. non-anonymous payment processing. In particular. it makes it possible for the payment system to track customer spending habits. stipulates the use of certicates by both merchants and customers. iKP is in fact a series of three protocols. Its unique contribution is its compatibility with existing payment clearing mechanisms and its staged approach designed for simplied integration. encrypted with the public key of the gateway.3 i-Key Protocol (iKP) i-Key-Protocol (iKP) (Bellare et al. which oers non-repudiation of messages originating from the merchant. while customer identity can be hidden from the merchant (by encrypting it with the public key of the gateway). using server-side certicates gives the customers extra assurance that they are dealing with the legitimate merchant. designed for quick deployment and integration. Payment authorisations are signed by the gateway. 1KP is the simplest of the three. Each payment order contains the customer's credit card details and a PIN. iKP uses the familiar concepts of payment gateways that serve as mediators between the merchants and the banks. Unlike other protocols discussed in this section. Since all transactions go through the gateways before reaching the clearing infrastructure. This ensures that the merchant cannot access private details of the customer. iKP does not completely address the issue of anonymity. Each protocol builds on its predecessor and aims to deliver more security features.

1996) made a signicant contribution in presenting a notational system that successfully preserved customer and merchant anonymity using techniques described in (Chaum. 2001. 3KP in particular.. or to guarantee amounts as commonly done. 2000 for further discussion). This means that the customer may present multiple invoices from the same merchant at the same time and pay for them all at once. The technique presented by David Chaum (Chaum. The system works by allowing the customer to have two accounts with dierent providers. is designed to use client side certicates as an enhanced form of customer authentication. The proposed protocol uses anonymous accounts to separate the customer's identity from his purchases. The next two protocols use the concepts originally discussed in (Chaum.4 Anonymous Credit Cards Anonymous credit cards rst discussed in (Low et al. 1995). for example. 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. which at the moment is not the case. 2000). Clearly. Ellison & Schneier. this concept does not address the issues discussed in this thesis because it still involves the customer in every transaction. 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.. 2000. one of them being anonymous. Requiring customers to properly manage the security of their certicates is also a major issue (refer to Josang & Tran. In (Bellare et al.2. no further explanation is given.. They rarely guarantee that a Certication Authority (CA) has properly authenticated its holder. in the case of car rentals (Bellare et al. The invoice is considered as an oer. 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. In fact. 1981. 2. which may be used at a later date to make the actual purchase. 1985). The merchant is not capable of initiating payment transactions independently without customer authorisation. certicates merely dene an association between the public key and a name.2. Josang et al. This implies that certicates themselves carry a certain degree of trust. 1994. 1981) to implement anonymity within a notational payment scheme..2. As far as can be determined. 1981) works by allowing customers to transfer funds between regular and anonymous accounts and then using just 20 . Overview of Notational Payment Schemes Furthermore. 2000.

Desmedt & Frankel. This same principle is used to transfer money between the customer's anonymous account and the merchant account. the authors have chosen to use a mix-network (see Chaum.. This is done as an automated process. It fails to deliver true delegation of payment authorisation from a customer to a merchant. 1989. which does not involve the customer. which is encrypted using 21 . The data is represented as a payment order. which the customer must pay. ve parties could collude to determine the customer's identity. 1994. this protocol suggests creating a network of bank servers and government entities to full that task. Shamir. To enable this. The customer begins by communicating with the transaction center to initiate a funds transfer to a blinded merchant account. Literature Review the anonymous accounts to make purchases.2. 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. There are of course major dierence between this system and the periodical payment model being presented in this thesis. Instead it relies on prearranged agreements between two nancial institutions managing customer accounts.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'Raïhi. While it does not specically discuss this concept. The customer's involvement is limited to receiving the bill from the credit card company. 2. for implementing direct debit features it suers the same problems as the conventional systems used today. Since the account is not linked to a customer's identity all purchases are therefore anonymous. Collectively this service is named a transaction center. 1999). 1979. This protocol constitutes the earliest major piece of work that makes a signicant step forward towards introducing periodical payments to electronic payment schemes. 1979. As such. 1981) to enable anonymous communication between transaction participants. Just like in (Low et al. Instead of using a single logical node to represent the mix server. For example. the mechanisms presented in the two papers provide the basic building blocks for periodical transactions. 1996). The authors admit that the system does not provide unconditional anonymity but in fact. 1992) with each bank receiving a share of the private key they can use to collectively sign and decrypt payment orders. 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.Chapter 2. To enable this. a threshold scheme is used (see Blakley.

As a nal step. Also. 1996). by using the notational paradigm rather than digital coins. The transaction center can verify the signature and decrypt the request. and additionally signed by the customer. the payment orders can no longer be linked to the originating customer thus achieving transaction anonymity.6. 1994.. Overview of Notational Payment Schemes the public key of the transaction center. In fact. this system cannot support the periodical payments paradigm. It can then debit the customer's account and schedule transfer of funds to the blinded merchant account.2.e. it solves the bank robbery attack in which the attacker obtains the private key of the bank (see Jakobsson & Yung. however. 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.6 Payment Protocols using Disposable Accounts 2. this protocol delivers solutions to the problem of privacy without the complexities often associated with digital coin schemes. this protocol reduces the amount of data that must be stored by customers and merchants making it a candidate for a smart card implementation. A signicant drawback of this system is the fact that the customer has to communicate with the transaction center to initiate every transaction. which theoretically empowers the merchant to initiate payments on customer's behalf without customer intervention. In (Kristol et al. 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).. In addition.2. Note.e. Like most payment schemes based on the notational paradigm. Whilst 22 . until the funds are 2. 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. spent).1 Anonymous Mercantile Protocol The authors of (Low et al. 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. 1994) a protocol is presented that allows a customer to set up a session (i. at this stage the customer is known to the transaction center. Crediting merchant accounts is a batch process that occurs at periodic intervals.2. the merchant is not.2. Consequently. temporary) account with the merchant and then submit multiple requests for merchandise. Finally. when transferring funds to merchant accounts during the batch process (at which stage the merchant becomes known to the transaction center).

In this paper.. The main objective of this approach was to reduce the amount of data managed by the customer and the merchant. 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. the merchant will continue to deliver data to the customer. the disposable anonymous accounts provide the same functionality as traditional digital coins discussed in the previous section. the reduction in communication overhead due to the consolidation of payments for multiple items undoubtedly creates a more ecient system. 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 authors have also discussed possible extensions to the original protocol to allow customers to leave session accounts active for prolonged periods of time. In this system.2 Mini-Cash A similar approach was also used in (Jakobsson & M'Raïhi. 2. which now only requires participants to manage their own private keys whilst all of the funds storage and transaction 23 . The unspent amount is refunded back to the customer using the same technique as in (Low et al. Spending a coin in this system means destroying the account and creating a new one whose associated public key belongs to the recipient (i. The protocol ensures that the disposable accounts (just like the digital coins) cannot be traced to the identities of their owners. 1996). Once the funds run out. the customer has the option to top-up his account or terminate the transaction.Chapter 2. which can only be spent in its entirety. Besides the convenience factor. Its main contribution is the simplication of the coin paradigm. the account is cancelled. Once the amount is spent.2. 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. 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). 1994.6. Literature Review the customer has funds left in his session account. 1999) to implement a hybrid system that combines features of digital coins with an account-based paradigm. Each account corresponds to a xed amount.e. 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. merchant).

any approach that attempts to duplicate the features of conventional cash will struggle to support periodical payments. periodical payments are used because the customer does not want to commit to a large payment within a single transaction (e. However. hence.6. In addition. the disposable accounts described in (Jakobsson & M'Raïhi. customers have no control of how. Overview of Notational Payment Schemes management is transferred to the bank server.g. 2. 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.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. 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. this approach cannot be considered a sucient solution to the problem. Clearly. It is also designed to protect the system from the bank robbery attack. One major limitation of the session account concept is the fact that the funds have to be committed before the transaction takes place. (1994). which is a truly account-based concept. Just like paper money. distributed across a predened length of time. this protocol does not facilitate setting restrictions on the use of customer accounts by merchants. each transaction in this protocol constitutes a transfer of coins from one party to another without being deposited into the recipient's mainstream account. In most cases. 24 . choosing to pay insurance premium by the month rather than paying it all at once at the start of the year). This protocol also requires the customer to commit funds before each transaction and therefore cannot delegate control of money to a third party. This. This oers the participants signicant saving in storage and thus makes this solution ideal for smart cards. 1999) also only supercially resemble periodical payments. As such.2. Similarly. when and by how much their accounts are credited.2.2. this system supports multiple funds exchanges between dierent parties without being deposited into a  real account in between each transaction. there are signicant conceptual dierences between the periodical payments discussed in this thesis and the session accounts described by Kristol et al. customers can potentially lose the funds stored in their accounts. in fact. contradicts our current view of periodical payments. Conceptually. Session accounts are not capable of supporting the desired level of granularity for account control. which allows customers to split a single large payment into multiple smaller ones.

these tasks are commonly referred to as batch jobs because they are not executed when submitted. In the context of the grid environment. 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.1 Grid Security Architecture A signicant amount of research and development towards improving and standardising the X. Kouril. 2003). 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. distributed network and across dierent administrative domains (Welch et al.2) was accomplished through the development of the grid security services. 2003. This is an important aspect of a grid architecture since it is likely that new resources will be dynamically 25 . The toolset. and in particular. This is a highly exible and fast way of delegating credentials to user dened processes that do not involve any external parties (i. certication authority).3. heterogeneous environment.. Furthermore. the grid framework assumes the existence of a trusted certication authority. To support X. 2005. 2004). This ensures that such certicates will be authenticated by all services within a grid. The concept of grid computing can be dened as a collection of systems and applications that cooperatively manage resources and services across a heterogeneous.Chapter 2. which can issue certicates to grid users.3.3 Overview of Electronic Payment Related Technologies 2. The grid infrastructure supports cross-realm authentication using the gateway paradigm. the Open Grid Services Architecture (OGSA). Kerberos). known as the Globus Toolkit (GT version 3).e. Instead they are scheduled and executed when appropriate hosts are found and enough resources have been allocated to execute them. Literature Review 2..509 certicates.509 certicates) into site specic ones (e.e. Tuecke et al.509 proxy certicate specication (see section 2. This architecture introduced the concept of virtual organisation (VO). X. Its major contribution. 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. which enable the development of secure services based on strong authentication and delegation of permissions using proxy certicates (see Welch et al. which is used to translate authentication credentials from the common format (i. Using proxy certicates allows grid users to create new grid identities and delegate some (or all) of their privileges to those identities. has delivered a set of standard tools that use proxy certicates for authentication within a complex.. delivers a set of APIs.g. its Grid Security Infrastructure (GSI).

In addition. the system retries. The reference to MyProxy server tells the WMS that the user wants the proxy credential to be registered with the renewal service. a MyProxy online credential repository was introduced that allows users to store their digital certicates on a secure server administered by a grid administrator. The connection to the MyProxy server is encrypted after mutual certicate authentication is performed. in addition to providing its own certicate. The renewal service periodically checks its database to determine if any of the registered credentials are about to expire and if it nds any.g. longer than the proxy certicate lifetime). Once the renewed certicate is returned. The registration process involves storing the proxy certicate and the date when it should be renewed. the resources that are executing user tasks). updating and removing them. which must possess valid credentials to be able to interact with other entities within the grid.3. the users rarely know how long that job will take.e. 2005). Then it needs to forward a new certicate to that resource. However. the user may need to supply username/password or end-entity certicate with a corresponding proof of possession of private key).2. Using proxy certicates to enable long running batch jobs is not in itself sucient to ensure high level of security within the grid environment. proxy certicate lifetimes should be kept to a minimum. 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. which limit credential accessibility to proxy clients. the users may specify access control policies. This repository allows users to remotely access their credentials for the purpose of storing. quarter of lifetime remaining) a credential renewal service is used. it can contact the MyProxy server to renew them. However. To automatically renew credentials that are about to expire (i. During the submission of a batch job to the workload management service (WMS) that is suspected to take a long time (i. Overview of Electronic Payment Related Technologies created. which needs to nd the resource that is executing the task for which the proxy certicate was changed.e. especially considering that it is up to the grid scheduler to nd the necessary resources and to start the job when it can.e. It is clear how the use of proxy certicates within a grid environment is applicable in periodical 26 . This is handled by another subsystem of the WMS. the renewal service overwrites the old proxy certicate and updates the next renewal date. at the submission of a batch job. Access to these credentials is protected via an authentication mechanism (e. the renewal service must also prove possession of the proxy certicate being renewed. if the certicate cannot be renewed at a particular time. the user may specify which MyProxy server can be used to renew the proxy certicate provided during the job submission process. Alternatively. It is a commonly accepted fact that to be eective and secure. In (Kouril.

only restricted proxy certicates shall be considered. this is not possible using the conventional X. 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. while the privileges always refer to the amount of funds that can be transferred and who can do so. which is applied to authentication and authorisation problems. the resources for which access is granted is always the customer's bank account. 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 user may prove to other parties that it is the owner of the certicate. Proxy certicates are identical to standard X.509 Restricted Proxy Certicates In principle. Using the private key. Some common issues that are relevant in grids are not relevant in periodical payments simplifying the electronic payment paradigm. For periodical payments. For example. 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. There is a minor dierence between a proxy certicate and a restricted proxy certicate that is important to keep in mind during this discussion. 2. the X.509 certicate.2 X. It is used to bind a public key to a user identity.3. Restricted proxy certicates allow issuers to dene restrictions. 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. which are placed on proxy certicates via policies. In (Tuecke et al. 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. Literature Review payments.Chapter 2. This enables issuers to dene which subset of their overall permissions are to be transferred to another party. Without revealing the private key. 2004) a full specication of this mechanism is presented. which parties are involved and once the payment contract is negotiated no changes are necessary or allowed. dynamic creation of new entities within the network is not an issue since it is always known before each transaction. The main focus of this review is on presenting this concept in the context of periodical payments. thus subsequently reducing the potential damage that can be caused by credential misuse.509 certicate is a concept. For the purpose of this discussion.. which limit the privileges that are delegated to a certicate bearer. The proxy certicate specication denes a mechanism for specifying delegation policies. while the private key is kept secret.509 certicates and as such can be processed by 27 .

Check that the number of proxy certicates in the chain does not exceed the maximum path length value declared in the PCI. If the value is zero. 3. It is the PCI that provides the necessary framework for carrying delegation policies within certicates. such logic would include the following steps (Welch et al. i.e.3. 28 . 2004): It contains three elds which are of particular • Policy method identier : This eld contains a unique identier (i. Normally. which can interpret the policy dened by the policy method identier within the PCI. attribute certicates). the certicate cannot be used for further delegation.. certicate is a proxy certicate. denes the actual syntax/format of the policy. It is possible to enhance the certicate validation logic by using this PCI extension with delegation policies. 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. interest (Tuecke et al.2. than no restrictions apply. Currently. OID) that describes the policy language used by the proxy certicate to dene restrictions. 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. the issuer). 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.e. Check that the proxy certicate has a valid PCI extension block. 4. Id-ppl-independent : Proxy certicates with this method delegate no privileges.g. Overview of Electronic Payment Related Technologies all existing authentication tools. Check that the proxy certicate has a valid principal name (it should be derived from the name of the parent certicate. can the bearer create/sign other proxy certicates to be used by additional parties). Checking of the policy would normally be given to an entity. 2004): 1. If the eld is empty.. 2. This means that other mechanisms are needed if the user wishes to delegate privileges to the recipient (e. Determine the set of permissions that are delegated to the bearer by examining the policy specication stored in the PCI policy eld. • Policy : This eld is used for carrying the policy specication.e. The dierence is that a certicate may contain an optional proxy certicate information (PCI) extension.

An alternative to using policies encoded in proxy certicates is to use attribute certicates. In addition. Since proxy certicates are just X. policies are not generic constructs but rather may contain application specic assertions. Despite the number of signicant improvements achieved in this area the issue of periodical payment processing remains unresolved. Changes to attribute assertions can also be done with greater ease. For example. As such. a simple. which can be used to uniquely identify them within a CRL. Although there are many more electronic payment systems available they are mostly variants of the schemes discussed here. Literature Review The actual policy language to be used for dening the delegation of permissions is not specied by the proxy certicate specication. as renewal of proxy certicates is not required. Just like all certicates. This means that generic authentication mechanisms in use today cannot verify them. this dissertation.. proxy certicates contain a unique identier.4 Summary This chapter presented a number of electronic payment solutions developed over three decades of academic research. There are numerous XML based authorisation languages that are available (e. production environment a more robust specication would most likely be required. 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. 2005b)) which can be used as proxy certicate policy languages. 2004 for a discussion on strength and weakness of each approach). which are created separately to the proxy certicates. which means that they cannot completely validate the proxy certicates. 2.Chapter 2. 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). policies contained within a certicate must be dened during the creation of the certicate. This dissertation aims to combine the 29 . custom XML based language was designed to demonstrate basic concepts although it is acknowledged that in a real. which means that no amendments to the list of privileges delegated to the bearer is possible. revocation can be handled using certicate revocation lists (CRL).g. 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. There are some problems with using policies encoded in a proxy certicate (see Welch et al.509 certicates. 2005a) or XML Access Control For Mark-up Language (OASIS. Security Assertion Mark-up Language (OASIS.

4.2. this literature review is expanded to encapsulate commercial research and development in this area. 30 . Summary existing ideas of electronic payments with the new developments in credential delegation technologies to enable secure periodical payments. In the next section.

This chapter aims to rectify this imbalance by analysing various commercial attempts at solving security issues within electronic payments. Both Visa and MasterCard. are currently in the process of implementing and deploying new and competing authentication 31 . the previous chapter presents an unbalanced view of the research and development achievements within this eld. from time to time attempts are made to break away from the accepted status quo by introducing new and radical changes to current systems. As such. 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. it focuses on Secure Electronic Transaction (SET) specication. However. As such. as it was the most radical and inuential commercial protocol of its time. at times this industry has lagged behind the technological developments. such as Visa and MasterCard. Even seemingly small changes to infrastructure are costly and time consuming.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. 3.1 Background Traditionally. for example. It continues with analysis of its eventual abandonment and presents the current solutions being actively advocated by the industry leaders. the nancial industry has been risk averse when introducing new concepts and technologies into its long established processes. Specically.

There is no doubt that SET was and most likely still is the most ambitious and technically advanced specication dealing with electronic payments. by studying its design and by analysing the reasons for its failure its mistakes can be avoided in the future. The registration phase of the SET specication deals with describing the process of obtaining a digital certicate from a certicate authority (CA). It can be an independent third party company or it can be cardholder issuers and merchant acquirers. A registered CA can be any service provider that issues certicates on behalf of a card brand (e. Perhaps. 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 site dedicated to it has been disabled. It has been over a decade since Visa and MasterCard have unveiled their vision by presenting SET. SET Overview technologies aimed at reducing credit card fraud.1 Cardholder Registration Cardholders are responsible for obtaining their own digital certicates using SET client-side software. each one must posses a digital certicate. However. Despite its failure there is quite a lot that can be learnt from it.2. 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. 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. 3. which can uniquely identify them to each other.2.2. etc).setco.1.2 SET Overview 3. 3.1 Registration Phase Before either cardholders or merchants can participate in SET secured payment transactions. This software allows cardholders to establish a secure connection with a Certicate Authority 32 . These technologies will be covered in detail later in this chapter. Visa. 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. In the late 1990s a Secure Electronic Transaction (SET) specication was developed oering the market a new solution for processing credit card payments. MasterCard. Before introducing competing products solving credit card fraud issues.g.

it is responsible for preparing the initiate response message. 1. the cardholder software has all of the information it needs to securely communicate with the CA. A CA needs a credit card number to correctly identify which registration form it needs to return to the cardholder. Once the CA receives an initiate request message. If the registration form is available locally. 33 . The registration form is normally obtained from the cardholder's issuer. 1997a. 3. Since this request message is carrying sensitive information.b). The message is digitally signed using the CA's public key. However.Chapter 3. which is generated by the cardholder's software.1: Cardholder Registration (CA). This message will contain its certicate as well as the freshness challenge it received from the cardholder. Cardholders' software bootstraps this process by sending the CA an initiate request message. 2. the CA can simply return the registration form back to the cardholder. it is encrypted using a symmetric key. The cardholder registration process is described in detail in (MasterCard & Visa. which will issue them a certicate. Once the initiate response message is received. rst it needs to validate the CA certicate by traversing its trust chain to the root certicate. This key is in turn encrypted using the CA's public key. Presumably the root CA would most likely be the card brand itself. which contains the name of the cardholder and a freshness challenge that the CA needs to return as part of the response message. 4. The next message in the process is the registration form request. 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. Secure Electronic Transaction (SET) Literature and Technical Review Figure 3.

Instead. 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). Unlike with cardholders that can number in millions. the CA encloses a hash of the card details (i. 5. The signed certicate and the secret value is encrypted using the symmetric key generated in the previous step and sent to the cardholder. which tells the cardholder's software to contact an alternative CA. 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 certicate) can be encrypted using this key. the CA needs to identify the merchant's acquirer. billing address. the merchant receives the registration form as a response to its initiate request message.e. When generating the certicate. the cardholder's software also needs to generate the public/private key pair (if the cardholder does not have one). another symmetric key (also newly generated) is enclosed so that the response generated by the CA (i.e. 6. the CA returns a referral response message. The certicate request message is encrypted using a symmetric key that the cardholder's software generates. In addition.1.3. the card number. expiry date and secret value). 3. 1. In addition.2 Merchant Registration Merchant registration process is simpler than the cardholder registration process.2. there can only be a relatively small number 34 . for example if cardholder's issuer is operating its own CA.2: Merchant Registration Alternatively. At this point the cardholder needs to ll out the registration form giving such details as card number. Before issuing a certicate to the merchant. The public key is going to be bound to the identity of the cardholder inside the certicate.b). It does not require the exchange of credit card details reducing the communication overheads by one message. The merchant registration process is described in detail in (MasterCard & Visa.2. SET Overview Figure 3. etc. 1997a.

All of this information is combined into a certicate request message which is encrypted using a newly generated symmetric key. rst it needs to validate the CA certicate by traversing its trust chain to the root certicate. The entire message is signed by the new signature key and transmitted to the CA. To receive a registration form therefore the merchant must include its name in the initiate request message it sends to the CA. one for signature and the other for encryption. 4. It is assumed that before this can be done that the merchant has already established a relationship with an acquirer o-line. which 35 . the CA will also include its certicate in the response message so that the merchant can securely communicate with it. hence it can identify them by name rather than card numbers. address and unique identier are recorded. Secure Electronic Transaction (SET) Literature and Technical Review of unique merchants.e. Completing the registration form is the next step in the process. the merchant has all of the information it needs to securely communicate with the CA. In addition. Since the name is not a secret. The method for doing this is not specied in the SET specication. The certicate is then sent to the merchant.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. However. which is subsequently encrypted using the merchant's public key (i. the CA will issue a new certicate signed by its public key. Presumably the root CA would most likely be the card brand itself. Such information as the merchant's name. the merchant must also generate two sets of public/private key pairs. The certicate is encrypted using a newly generated symmetric key. 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. 3.2. 2. Provided that the information is correct. The response message is digitally signed using the CA's public key. Once the CA receives. which itself is encrypted using the CA's public key.Chapter 3. the encryption not the signature key). In addition to the registration form. decrypts and validates the signature of the certicate request it needs to validate the information provided by the merchant inside the registration form. before secure communication channel is established). Once the registration form is received.e. 3. it can be transmitted to the CA before its certicate is received (i. SET process starts with the cardholder requesting a certicate of the payment gateway.

The merchant must include the freshness challenge in its response to the cardholder. the merchant must also forward its own certicate to the cardholder so that it can securely communicate with it.3: Purchase. The purchase phase is described in detail in (MasterCard & Visa. 1997a. which it expects to receive back from the merchant. 3. SET Overview Figure 3. The cardholder software sends an initiate request message containing the payment card brand that the cardholder is using and the freshness challenge. hashed again and the result signed using the cardholder's public key. When the cardholder software receives initiate response message. using the payment gateway's public key the symmetric key is encrypted itself. Assuming that they are valid. In addition. it will check the validity of the merchant and the payment gateway certicates by traversing their trust chains. 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).b). then the hashes are concatenated. 1. Then. This information is 36 . Authorisation and Capture it needs to securely exchange payment instructions with it without revealing them to the merchant.3. A new symmetric key is generated and the dual signature and the PI are encrypted. then sent to the merchant as a purchase request message. Both constructs are hashed separately. the software will generate the order instruction (OI) and the payment instruction (PI) constructs. This creates a dual signature. 2.2.

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


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. 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


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.


3.3. Issues 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


g. SET makes many assumptions regarding the state of the application when the protocol is initiated. without a standardised approach for establishing a SET session. 3.3. credit/debit cards) seems impractical and unlikely to be done in practice. USB tokens and any additional software required.1.Chapter 3. however. In fact. however. the certicate registration phase formulated by SET seems redundant. SET specication assumes that the client software will know at which point to send the initiation request. This information is exchanged between the cardholder and merchant software during the shopping phase before the rst SET message. Secure Electronic Transaction (SET) Literature and Technical Review focus their attention on shopping and payments. however. The interactions that can occur between these three parties can take several alternative execution paths (Bella et al. It works by allowing customers to download and install digital certicates from its secured servers. 1997a) reads: For example. leads to complications such as interoperability issues discussed later. the cardholder must start it.2 Purchase Phase The purchase phase of the SET protocol is somewhat complicated because of the three-way interaction that occurs between the cardholder.. It is unclear. 41 . Australian Tax Oce (ATO) uses this approach for distributing cryptographic credentials to Australian businesses that register to use its online services. although it does have a substantial o-line overhead for distributing passwords. In the context of card issuers. The initiation of the protocol is interesting because as is the tradition of the SET specication. SET requires the cardholder to be directly aware of the payment gateway used by the merchant. The issuers are providing their customers with already pre-populated hardware tokens that contain all the necessary keys and certicates that they will need. This is an easy assumption to make. 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 overhead is minimal because keys and certicates can be distributed using the same procedures as used for provision of credit/debit cards. For example. the merchant and the payment gateway. in practice. Given the current state of technology and the already established processes. Not providing such credentials when issuing cardholders with authentication tokens (e. 2002) causing unnecessary complexity. Once again this is only possible because of the custom client-side software that must be installed prior to making payments. the SET Business Description (MasterCard & Visa. precisely how to bootstrap the initiation process.

this step can be easily removed from the specication. By removing the need to hide payment instruction details. 2002). The drawback of doing this is that the payment instructions will no longer be hidden from the merchant. The use of dual signatures is an excellent idea to be able to hide purchase and payment details from various parties in the transaction. as will be demonstrated later. 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. PAN Secret seems somewhat redundant considering that in most PKI solutions. That is.e. Issues Since SET deals exclusively with the payment and not the shopping process. It does. which must be lled in by the cardholder with the credit card details. clearly SET relies on these pre-initialisation steps to be followed. Another interesting part of the specication involves the use of PAN Secret. By removing this dependency on the payment gateway. 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).3. This is the way online payments work today. Instead of issuing the cardholder with a single certicate that uniquely identies them to the issuer. quite a substantial amount of information is repeated in each message (Bella et al. There is an alternative method that could be used to hide credit card details from the merchant. such important facts are left unspecied. knowledge of credit card number does not allow an attacker to make payments. However. the cardholder software needs to obtain the certicate of the payment gateway that the merchant is using. a random secret that can be used to authenticate cardholders to the payment gateway. 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). hence hiding it from the merchant is unnecessary). Depending on which certicate is used. otherwise the whole protocol cannot be bootstrapped. In most cases. However.. however. 42 . Submission of this page initiates the process. the security can be derived from the knowledge of the private key rather than being able to successfully hide credit card details (i. each cardholder may be issued with multiple certicates each one representing a unique binding between the cardholder's identity and an account number.3. proof of possession of the private key is sucient in order to authenticate a client presenting a digital certicate. complicate the algorithm and makes the purchase phase of the protocol longer. The merchant presents the cardholder with the payments page. There is another advantage of removing the requirements for bootstrapping the SET session via the client software. This rst step is only necessary because it needs to facilitate the three-way interaction. the payment gateway can determine which account to debit while the merchant remains unaware.

These 43 . Client-side authentication as presented in SET also suered from lack of portability. Clearly this is not a desirable or practical approach. SET depends on authentication and authorisation of credit card payments by This form of authentication requires the presence of a large. open public key infrastructure (PKI) was assumed to exist that would support the SET standard. a decade later. Its use is limited to Intranet based applications. USB cryptographic tokens have emerged that combine both the smartcard and a reader in a single device. smartcard support on customer PCs was practically non-existent. 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. This eectively solves smartcard integration issue on customer platforms. distributed In other words an using client certicates. by far the most advanced specication for securing credit card payments in open networks. With limited bandwidth available to users at the time it was unacceptable. Using this technology. The use of smartcards was recommended as a possible solution to this problem. this meant that cardholders needed to install SET software and their certicates on all machines that they were going to use. At the time of its conception.Chapter 3. This thesis relies on this fact as it pursues the same approach of using client side certicates for authentication and delegation. infrastructure for supporting certicate issuance. at the time of SET's development.2 Immature Technology It is true that SET was and probably still is. the use of custom client-side software at the time would have been a signicant deterrent. as USB penetration of the consumer PC market is adequately comprehensive. it was based on bleeding-edge technologies utilising the most advanced cryptographic techniques that even now are not commonly used. This was discussed at length in (Wolrath. Furthermore. revocation and management. Each SET client machine needed to have installed both the SET client software and a copy of the cardholder's certicate and private key. Hashing of the PAN Secret in order to authenticate the cardholder to the payment gateway seems like an acceptable solution in such cases.3. and most importantly requires a substantial amount of time and signicant nancial investment to establish. Such infrastructure is expensive to build and maintain. However. Even now. 1998) with issues relating to shopping cart abandonment associated with complicated shopping experiences being cited as signicant problems faced by retailers. 3. Eectively. just like now. For example. The need for installing a heavyweight application on client machines even now is considered  bad practice . such infrastructure does not exist despite continuous interest in certicate-based authentication. In recent years this has changed with the development and widespread adoption of Universal Serial Bus (USB) standard.

While performance is very likely to have been a problem a decade ago. Having little incentive and facing enormous costs. 3. 1998) it quickly becomes apparent that most SET client side applications provided no feedback to the users regarding the progress of payment transactions. 3. 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.3.3 Performance Due to its complexity and improved security model SET struggled with performance. This thesis makes heavy use of these features for seamlessly extending browsers in order to implement custom business logic for supporting delegation. Reading this market survey (Wolrath. Wolrath (1998) described how some vendors reported lag times of up to fty seconds for processing a single cardholder request. 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. For example. Requiring minimal user eort and using very little bandwidth this approach is considered appropriate in the current environment. the lack of feedback via the user interface would most denitely have created negative customer experience leading to unfavourable customer opinions. it is also possible that the interface between the client and the merchant also could have played a part in its demise.3. By comparison. most merchants decided not to pursue this expensive option. 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. 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. 44 .3.3. 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.g. Mozilla Firefox framework allows the use of XUL with JavaScript for extending both its user interface and business logic). Considering the average processing time of up to a minute. 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. The recorded times encapsulated both the initial cardholder request. up to and including receiving the approval response from the merchant.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.

3.g. 3. however. however.1 Visa and MasterCard It has already been briey mentioned at the start of this chapter (see section 3. more merchants would have been able to justify the cost of implementing a SET application. Interoperability Reference Guide For SET 1. any compliant SET application should have been able to interact with other SET applications developed by dierent vendors. environment the card brands establish themselves as the exclusive supplier of the payment processing service. various vendors attempted to implement the specication in order to gain that all-important market share.1) that both Visa and MasterCard have abandoned SET. In (Wolrath. 1998). 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. There is no question that the merchants and cardholders stand to benet as well. in practice this did not prove to be the case. long-term solution. as was discussed in (Wolrath.3. less expensive alternatives. it only deals with the payment part of it. This specication does not cover the entire shopping process. Instead they have introduced alternative.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. While large companies. 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.0). at the same time increasing brand awareness and gaining market share (Wolrath. Perhaps if the Internet community quickly adopted the standard. In theory.Chapter 3. 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. such as IBM tried to develop other standards to ensure that SET vendors produced applications that could inter-operate with each other (e. competing technologies aimed at solving credit card fraud issues.4 Credit Card Security after SET 3. When it came out. when it comes to justifying cost over benet. it seems that the market has chosen to pursue other. For Visa this technology is Visa Three Domain 45 .4. this clearly did not lead to an acceptable. 1998).

while MasterCard implemented a Secure Payment Application (SPA) protocol. When the cardholder's browser is redirected to the issuer. Both protocols solve exactly the same problem but using a dierent approach. Using the Visa Directory. the cardholder must provide the issuer with its customer number and the password. 4. Credit Card Security after SET (3-D) Secure authentication protocol. this clearly is not appropriate. the cardholder's browser is once again redirected to the merchant web site. Since the cardholder is communicating directly 46 . This works particularly well for username/password authentication model. 3. 2002b). These steps do not include the authorisation and the clearing process that the merchant must perform post fact (GPayments.1. The cardholder must provide the merchant with sucient detail in order to obtain a reference to the cardholder's issuer. In particular. For strong authentication (e. Assuming that the issuer is capable of participating in a 3-D Secure transaction. it is the rst several digits of the credit card number. Normally.4 illustrates the initial steps that the cardholder and the merchant must perform to begin a purchase transaction. it dictates that each payment transaction requires a new authenticated session.g. Visa dictates that additional software must be installed on each cardholder machine for chip type authentication (GPayments. the merchant will redirect the cardholder to its issuer for authentication. There is no scope for credential caching or reuse. 2002b).4.b): 1. meaning the cardholder must be redirected to the issuer for every transaction and therefore enter username and password multiple times. A good discussion of each protocol along with feature-by-feature comparison is provided by (GPayments.4. It uses browser redirection as the main mechanism by which cardholders are authenticated. After the authentication step is performed. Instead of burdening the merchant with the task of obtaining user credentials. There is a disadvantage of using browser redirection as a mechanism for cardholder authentication. 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. 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. 2002a. 3. Figure 3. 2. smartcards).1 Visa Three Domain (3-D) Secure Visa 3-D Secure model works particularly well in the current browser dominated business environment.3. however. as it requires no additional software on the cardholder's machine.

the issuer must create and sign a response message and redirect the cardholder's browser back to the merchant web site. That is. signed response message) the merchant proceeds with payment authorisation and capture as per normal. 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. Once the cardholder is redirected back to the merchant site there is not much that the cardholder must do. 2. The merchant can use the reply from the acquirer to prepare a receipt. 2002a.5 illustrates this process which is described in detail in (GPayments. Figure 3.4: Visa 3-D Secure Payment Initialisation with the issuer. 5. Once the submit button is clicked. The reply received from the issuer is returned to the merchant. 3. Assuming that authentication credentials are valid.g.Chapter 3.b): 1. This process is identical to the steps that current merchant applications must follow to initiate a transaction. it issues a payment authorisation request to the acquirer. the issuer provided the cardholder with a valid. username and password information is never revealed to a third party (e. The acquirer must contact the cardholder's issuer directly for it to authorise the payment. which is provided to the cardholder.e. Assuming that the issuer successfully authenticated the cardholder (i. 47 . Secure Electronic Transaction (SET) Literature and Technical Review Figure 3. the merchant).

Assuming that the credentials entered by the cardholder are correct. the is- 48 . A SPA applet must be installed on every machine that the cardholder intends to use for making online payments. hence it can be safely installed and used on even unsecured machines (e. There is a dierence between the SPA and the SET applets. 2002b). At this stage.4. 1. Once shopping is completed the credentials are destroyed and another user can safely reuse the same SPA applet. 2.1. The MasterCard SPA applet installed on the cardholder's machine is activated when it encounters a SPA compatible page. Internet cafes.g.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. Using an applet instead of browser redirects means that customer credentials can be cached locally and reused over multiple payment sessions.g. Credit Card Security after SET Figure 3. Cardholders do need to enter issuer information before making purchases as it is needed during authentication.4. It also means that integration with smartcards is easy as all of the software is already installed on the customer's machine. a SPA applet does not require any customer specic information. The SPA applet is responsible for securely communicating with the issuer when authenticating the cardholder. the cardholder is asked for authentication credentials (e.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. 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. etc). Unlike SET. Figure 3.5: Visa 3-D Secure Payment Authorisation 3. username and password).3.

The merchant sends a payment authorisation request together with the authentication token it received from the cardholder. 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. which uses the existing MasterCard network for payment authorisation and clearing. 49 . When the cardholder accepts the terms of the purchase. 6. The merchant informs the cardholder of the status of the transaction by issuing a receipt message. Secure Electronic Transaction (SET) Literature and Technical Review Figure 3. 4.Chapter 3. 5. the SPA applet sends the authentication token to the merchant. This request is forwarded to its acquirer. which it can use to authorise payments via its acquirer. Whatever response it receives from the issuer is forwarded to the merchant. 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.

3.4. Credit Card Security after SET 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


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.


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


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


54 . 2005. APCA. 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. however.3. the use of digital policies for validating direct debit transactions proposed here is unique and an area that the SEPA scheme is weak in.5. In addition. This is especially true with Visa. SEPA could likewise benet from the superior techniques developed here for policy issuing and signing. 2005) it is clear that a niche exists that has so far been overlooked by these major industry leaders. Summary essentially session based. Despite its maturity. which sets out guidelines for processing direct debit transactions across national boundaries within the European Union. which does not even support credential caching. This chapter concludes with an overview of the SEPA Core Direct Debit scheme. 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). They provide no support for delegation and in fact require the customer to be physically present during every transaction. there are areas of this scheme that can be improved. Considering the usefulness of this payment type and its growing popularity (as evident from RBA.

1 Overview The complete periodical payment process is somewhat involved. It assumes that cardholders and merchants will be issued with digital certicates separately. for example.1. 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. this process works in a schedule-type framework.509 restricted proxy certicates into an electronic payment application.Chapter 4 Periodical Payment Framework Theory This chapter presents the theoretical model for integrating X. 4. which assumes immediate transfer of funds. Major components of this application such as the delegation of payment credentials and their use for initiating payment transactions are analysed. Unlike the traditional model. This makes this specication a lot simpler to describe and analyse.1 Periodical Payment Process using X. Instead. whereby the initial (and only) customer-merchant interaction simply 55 . when being issued new accounts such as credit cards.509 Restricted Proxy Certicates 4. periodical payments do not. the periodical payment framework discussed in this chapter deals solely with payments. Unlike the SET specication that described a complete cardholder and merchant registration process. In addition.

The policy language must contain sucient expressiveness to describe most common periodical payment scenarios. Before discussing the details of the periodical payment framework it is important to understand this fundamental idea. language simplicity is of the highest importance to ensure that customers can easily.4. when delegating credentials. lets examine the two stages of the periodical payment process: 56 .1. it is most likely that customers would be interested in the following restrictions: 1. 4. The merchant will only charge the customer account once per agreed payment period. 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. As such. 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. 2. The merchant promises to provide a customer with a service while the customer agrees to pay for that service on regular basis. 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.2). if this forms a part of their agreement. anything under $200. The merchant will only charge the customer account for services provided or to be provided to the customer. The merchant will only charge the agreed xed amount or an amount within a specied range (e. etc). it will be demonstrated how each of the above assertions can be easily expressed using an experimental policy assertion language (see section 4. The periodical payment policy is the core of the model. The important qualities for the policy language that are of particular interest are its simplicity and exibility. 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. For now.g.509 Restricted Proxy Certicates establishes the terms of each scheduled transaction. For example. The merchant will cease to charge the customer account on request. visually inspect each periodical payment contract and understand it. 5. a contract between a customer and a merchant. language exibility is also crucial. While simplicity is of particular importance. This policy is essentially an agreement. 3. Later in this section. Periodical Payment Process using X.

The only major dierence to the original protocol is the enforcement 57 .e.2).1. Periodical Payment Framework .1. transfer of funds from a customer to a merchant account (see section 4. It is based on the X.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.1: X.Chapter 4. i.3) 4.Theory Figure 4. 2004)..509 proxy certicate delegation specication dened in (Tuecke et al. The delegation of the payment credential including signing of the policy document (see section 4. and 2. Initiation of a payment transaction.1.509 Restricted Proxy Certicate Delegation 1.

however. Due to the nature of periodical payments. a malicious customer may attempt to circumvent this security protocol by setting 58 . 5. The customer must review and verify the terms of the policy document received from the merchant. the above validation process is not quite sucient to ensure that the merchant obtains a completely usable certicate. the customer can either try to renegotiate the terms of the policy.1.1 and it works as follows: 1.509 Restricted Proxy Certicates of the certicate policy (i. however. Using the key pair created in step 1.. This request must conform to the specication described in (Tuecke et al. At this point. Periodical Payment Process using X. it can use the proxy certicate subject to its policy.4. It will also contain the policy created in step 2. The customer veries that the proxy certicate request is valid. 8. This delegation process is depicted in Figure 4. 4. The root certicate will most likely be well known. reject it or proceed with the next step. the customer must process the request to examine the policy and to sign the certicate). 7. Normally. Also. Proxy certicates are likely to inherit life spans of their issuers and as such may not be valid for the full periodical payment period. which is normally an optional extension of the certicate. in this framework it is mandatory. The customer creates and signs the proxy certicate and sends it back to the merchant.e. the policy document is an optional eld. 6. The merchant then creates a payment policy statement. for example a Visa or a MasterCard certicate. This can be done locally by following the certicate chain to its root.e. the merchant needs to validate the authenticity of the proxy certicate signature. the merchant generates a new publicprivate key pair. This step is important as signing the certicate request binds the customer to the policy agreement. 3. periodical payment policy in this case). this part is not specically addressed in this dissertation. As a nal step. the merchant creates a restricted proxy certicate request. the merchant may also choose to check a certicate revocation list (CRL) hosted by its payment gateway or a similar third party service. In addition. 2. the customer checks that all of its mandatory elds have been correctly set. Once the merchant receives the response. That is. The request is sent to the customer for consideration (i. Once the customer requests a periodical payment option. 2004).

It is merely assumed that it will be present post authentication process. Visa or MasterCard) before it can process payment transactions. when presented to a payment gateway.g. The proxy certicate can be used for authentication to the payment gateway using the SSL/TLS protocol.. an additional feature for renewing proxy certicates is also needed (e. Since the proxy certicate is simply an extended X. additional checks: (a) Ensure that the rst periodical payment is scheduled to be after the Not Before date attribute of the proxy certicate. using a similar mechanism as in European DataGrid project. 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.g. 2005). However. this particular approach is highly inexible and does not reect all possible payment scenarios. The nal step (step 8) of this process concludes with the merchant obtaining possession of a valid restricted proxy certicate which.509 certicate no modication to the underlying protocol is needed. 4. To ensure that this is not possible.2 does not depict the authentication process nor does it demonstrate how the proxy certicate becomes accessible within the payment gateway context. proxy certicates will be usable for the entire periodical payment contract. Unfortunately.1. The payment gateway depicted in Figure 4. 2004).3 Payment Process Once the merchant has the proxy certicate the payment process is simple. the acquirer must be associated with one or more card brands (e. As such. the above process is exactly the same as the one outlined in (Tuecke et al. and (b) Ensure that the proxy certicate will not expire until the last periodical payment is made. the merchant must perform the following. will enable it to transfer funds from the customer account to its own. by checking its Not After date attribute This additional validation will ensure that once obtained. In addition.2 hides complexity which is important to understand before discussing the payment process.Chapter 4. For this reason Figure 4. The payment gateway is used to connect the merchant and its acquirer. With the exception of the treatment of the policy within the certicate. The acquirer maintains a relationship with the merchant.Theory a short proxy certicate validity period. see Kouril. This 59 . Periodical Payment Framework . It breaks down for long-term contracts or contracts with undened end dates. to limit the scope of this thesis this task is left for the future. which must be established o-line before the merchant can use its services.

Its back-end logic implements the functions that interact with the credit card network for processing payment transactions.1.2: Single Payment Transaction Process association with a credit card network allows the acquirer to validate customer credit card accounts and clear funds. That is. the payment gateway can check that the amount being charged is within agreed range of values. To simplify the design of the periodical payment framework the new payment gateway reuses this existing interface instead of replacing it. the design of the periodical payment framework allows for third party organisations to operate as payment gateways. 60 . The Legacy Payment Gateway depicted in Figure 4. Periodical Payment Process using X. As such.4.509 Restricted Proxy Certicates Figure 4. For example. Once the initial authentication process is completed the payment gateway performs the following tasks: 1. this need not be the case.2 represents an existing interface between the merchant and its acquirer. whether it conforms to the agreement made between it and its customer. Unless this validation succeeds the payment gateway will reject this transaction. Extract the payment policy from the proxy certicate and determine whether the merchant's payment instruction is valid. However. payment gateway applications are often operated by acquirer organisations directly. In practice.

That is. As such. 3.4. 4. Periodical Payment Framework . For example.1. 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.1. Specically. It is one of the most important issues that the current direct debit model has failed to appropriately address. This solution. The cancellation process is described in more detail in section 4. however. 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. By only comparing it to the current payment instruction received from the merchant it is not possible to detect double charging. 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. It is inecient to store records of all executed transactions and requires the payment gate- 61 . The process as it has been described so far has a signicant aw. 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. This log of transactions in combination with the certicate policy is sucient to determine whether an individual transaction is valid.3.Chapter 4. demands a great deal of the payment gateway. a new technique has been designed for solving this issue within the periodical payment framework.Theory 2. however. This includes any legacy authentication credentials that may be required.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. provides the periodical payment framework with various convenient ways of solving this problem. 4. 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. The simplest solution to this problem is for the payment gateway to record each transaction performed by the merchant. Check a registry of cancellation requests received directly from customers. Using proxy certicates for payment authorisation. It is described in the next section. 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. 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.

In this new approach. 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. Periodical Payment Process using X. The design for the logging mechanism proposed here is based on the concept of revocation. instead of merely specifying the allowed transaction dates. could be validated using solely the payment policy making payment gateway servers more ecient. 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 . For example. The logs can be trimmed down to the last performed transaction with all previous records discarded for a particular certicate. it is unlikely to work in practice as the level of eciency required is unrealistic and would result in extremely brittle.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. 4.. Any attempt to use the same certicate twice within the same month would fail due to this entry in the list. similar to certicate revocation lists (CRL) described in (Housley et al. given a monthly payment period. There are numerous reasons why policies may need to be cancelled. Using the delegated certicate at any other time would result in an error causing the transaction to be rejected. the use of stricter time-based conditions was examined. This works well in theory but unfortunately leaves no room for error. There was one more alternative solution that was briey considered before TRL based approach was chosen.1. For example.2 for details) can handle ne grained date-time restrictions. As such.1. Since the payment policy language (see section 4. However. A closer analysis of this problem and of the payment policy use reveals that such detailed record keeping is not strictly necessary. in this case the whole certicate cannot be revoked simply because the merchant will be unable to initiate any more payment transactions using it. 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. Instead. 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.509 Restricted Proxy Certicates way to keep a signicant amount of session information. a time up to the minute/second condition was required. 2002). unmaintainable applications. requiring merchants to be ultraecient in their payment processing. a policy would dictate that a transaction must occur on the rst working day of every month at precisely nine o'clock. This approach removes all dependencies Each transaction on the payment gateway to keep session state information between transactions.4.

Periodical Payment Framework . The customer-side process can be described as follows: 63 . The scheme presented in this and the following sections. There are numerous ways this can be implemented. Unlike the delegation and payment processes. the cancellation process most likely requires scrutiny from both nancial institutions and merchants alike.Chapter 4.3 presents just one possible scenario how this can potentially work. 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.Theory Figure 4. merchant competitors are oering better deals for the same type of services.3 depicts the process of cancelling a periodical payment certicate with its payment policy. etc). In this section.g. was specically designed to allow for deliberate. Figure 4. which are relatively easy to dene.3: Payment Certicate Cancellation Process no longer suitable (e. non-malicious cancellation of policies. Figure 4. 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.

to simplify the a payment period. Its address must be encoded within the payment policy so that customers know how to contact it. 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. Having established a mutually authenticated SSL session.4. This assures the payment gateway that it is dealing with a legitimate customer that originally established the periodical payment. and (b) There is at least one assertion within this sub-policy that allows cancellation of the policy within the current processing period. This request must contain the original. 4. It is strictly a one-way relationship. This will happen automatically once the merchant initiates the next payment transaction. where applicable. known as a cancellation policy. the payment gateway never directly initiates contact with merchants. Therefore.1. protocol. The customer must initiate this process by communicating directly with the payment gateway over an SSL encrypted channel. signed proxy certicate. This certicate must be the same as the one used for creating the merchant's proxy certicate. Even if the customer's request is valid and the policy can be cancelled. the merchant is entitled to one more transaction. Before the payment gateway registers a cancellation request it must ensure that the customer's payment policy allows it. The customer must use a certicate obtained from the issuer for SSL mutual authentication. the customer proves possession of a private key linking its identity to the certicate. The merchant process can be described as follows: 64 . the payment gateway cannot do so straight away. This step involves the creation of the cancellation request that will be forwarded to the payment gateway. Periodical Payment Process using X. Since this request is most likely to be received in a middle of Also. A payment policy is considered cancellable if it matches the following two criteria: (a) It declares a sub-policy. For this dissertation a simple approach was taken to determine this. cancelling the certicate at this stage would deny the merchant of collecting any outstanding charges and cancellation fees. As such.509 Restricted Proxy Certicates 1. 3. 2. within the main body of the payment policy document. in this step the payment gateway registers the customer's request in a cancellation registry to be processed next time that certicate is used.

By keeping track of contract and/or certicate expiry the length of the CRL can be thus managed. functionality and simplicity of the protocol. The above scheme makes a number of assumptions about how cancellation of periodical payments will be commonly used. In this case. the payment gateway must check the validity of the proxy certicate used. The payment process from the merchant's perspective begins exactly the same as described in section 4. Any attempt to circumvent this will result in a rejected transaction just like with any regular payment. The only dierence is that a single transaction may contain two payment instructions for the regular payment and a cancellation fee. Once the payment order has been processed. Instead.1. this scheme does not support immediate termination of contracts.3. 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.1. 4. 65 . 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. Periodical Payment Framework . permanently ended. the merchant using this scheme is not aware that a policy has been cancelled until an attempt to debit a customer is made. For example. 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.Chapter 4. This means that given a monthly payment period. When the payment request is received from the merchant. 3. A payment request will not be processed for certicates agged as registered for cancellation. a customer cannot suspend payments halfway through the month. Whatever fees are charged must be within the bounds of the payment policy agreement made between the customer and the merchant.Theory 1. When a notication of pending cancellation message is received. As such. At this stage the merchant is unaware that the periodical payment agreement has been cancelled. 2. When the payment gateway receives the amended payment order it follows a somewhat similar process to what has already been presented in section 4. One of the tests must include checking the cancellation request registry. the payment gateway can nally revoke the proxy certicate.3. On the other hand. this rst payment instruction contains only the regular amount due. 5. this approach favours the merchant as it can collect more revenue before the contract is permanently cancelled. a notication message is returned to the merchant carrying information about the customer's cancellation of the periodical payment agreement. These assumptions take the middle ground between exibility. the merchant can change the payment instruction to include any cancellation fees that may be applicable.

In this one assertion it is possible to encode both the contract boundaries (i. The attributes that can be set on the <pay> element are dened in Table 4. This was done to eliminate any possibility of scams involving foreign currencies. allows a merchant Alternatively. The rst three attributes of the <pay> element are simple. USD) Numeric (Decimal) Numeric (Decimal) CRON Expression Mandatory Yes No No Yes Table 4. AUD. The amount attribute. limit attribute can be used instead to dene a range of values up to and including the value of this attribute. This may not appeal to some merchants.1: XML <pay> element attributes Furthermore. begin and end dates) as well as the interval between each transaction. for example. Both attributes are optional and if not included eectively give merchants permission to debit any amount from customers' account. They are designed for restricting the amount that merchants can charge their customers. The currency attribute is self-explanatory. CRON is a utility commonly used on UNIX-like operating systems for scheduling batch jobs for execution at regular intervals.g. 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. Periodical Payment Policy Language Attribute currency amount limit on Type String (e. unlike the previous two it is mandatory. is the most complex. Its value is represented by a CRON expression. the merchant must react immediately when it receives a pending cancellation message. The syntax of the policy language is simple. the to dene a xed value that it can periodically debit from a customer's account.1. hence all its administrative tasks must be easily automated.4. This policy language is dened using an XML Schema which is listed in its entirety in Appendix A.e. The exact syntax for this attribute was taken from a popular open source Java job 66 .2 Periodical Payment Policy Language The periodical payment policy used within the proxy certicate is the core of this payment framework. The last attribute. 4. 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. merchants whose customer retention strategies yield good results. However. if used.2. The <pay> element encapsulates most of the contrac- tual information discussed in this thesis. on.

4).3. It has already been established in this thesis that manual validation of policies is essential for customer signatures to be meaningful.Theory * seconds * minutes * hours * day of month * month * day of week * year Table 4. A typical periodical payment policy must contain a single one <source-account> element and at least <pay> element. a simple mechanism for converting CRON expressions into text descriptions will be presented that eectively solves this problem (see Figure 5. All four attributes should be The self-explanatory as their denition and use directly reects current credit card usage. To minimise the scope of this thesis. see Appendix C for a summary). an ability to convert CRON expressions into a format that can be easily understood by consumers is needed. 2008). 2008) is the best reference for a complete listing of each eld and the types of values that it accepts (alternatively. A Quartz tutorial for its CronTrigger class (OpenSymphony.2 provides a brief description of the seven elds that constitute a valid Quartz CRON expression. credit cards were chosen to represent customer accounts within the periodical payment policy in this dissertation.2. Due to its concise format it is not human-readable which is something that is of crucial importance within the periodical payment framework. The only disadvantage of the CRON syntax is its complexity. 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 . In the next chapter (section 5. card verication value and expiry date. State.2: CRON expression format scheduling service called Quartz (OpenSymphony. Periodical Payment Framework .1). 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. only one type of customer accounts was considered. As such. 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. Its content is dependent on the type of account the customer wishes to use and cannot be generalised. Table 4. this element could potentially contain such information as account name. and so on. It enhances the original CRON expression syntax making it more ne-grained. The <source-account> element is used to dene the customer's account to which access is granted.Chapter 4. A the <creditcard> sub-element of <source-account> element was dened containing attributes listed in Table 4. Branch (BSB) code and account number. card number. For credit cards. Based on their popularity and widespread use on the Internet. For example. For regular Australian bank accounts it would be the Bank.1.

equally likely that merchants would demand some exibility to cope with special cases. It is envisaged that in the future the <source-account> element will be extended to support other account types. to circumvent a cancelled policy because the policy is bound to a particular provider.2. In fact.3: XML <creditcard> element attributes payment gateway) only. As was described previously. 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. however. a merchant may want to oer its customers a discounted rst payment as incentive for choosing it over its competitors. In this example an implicit assumption is made that all transactions within the specied period will have the same monetary value. In addition. For example.4 denes a simple policy that allows a merchant to debit twenty dollars from a customer's credit card account.1). An example in Figure 4. 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. 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.509 certicates. the policy schema was extended to allow multiple <pay> elements to be used within a single policy document. it is without exception. a customer will receive this policy as part of a proxy certicate request generated by the merchant (see Figure 4. The CRON expression in the on attribute species precisely when this transaction(s) can occur. it is assumed that the payment schedule will remain That is. The element denes two attributes information. an optional <description> element was used in this policy to identify the service for which payment(s) are made. Having two or more <pay> assertions 68 . In addition. It is the customer's responsibility to check the terms of the agreement and if acceptable. it states that the merchant may initiate a transaction on the rst working day of every month in 2009. sign the request thus creating a proxy certicate which is then returned to the merchant. <payment-policy> merchant-dn and payment-gateway-dn responsible for storing this Using these attributes ensures that the merchant cannot change a payment gateway. To facilitate handling of odd transactions. dispute resolution). for example. Its contents are free-text and are only there as a formality for o-line use (e.4.g. constant as well. 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. Specically.

is problematic because it introduces ambiguity as to which one the payment gateway should validate against during payment processing.6.ST=ACT.O=UNSW. only one of the two dened assertions will be applicable. the policy should be considered ambiguous and rejected. 69 . on attribute. dening payments from February through to December for a higher amount of fty dollars. a customer and the payment gateway must check that <pay> assertions do not overlap over the same payment period.OU=ITEE. The second assertion is applicable to the rest of the year.ST=ACT. Unless this condition is met. The rst assertion declares a single payment of twenty dollars on the rst business day of January (i.OU=ITEE.4: Periodical payment policy example within one policy. 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. 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>. part of the policy validation logic also needs changing.O=UNSW. An example in Figure 4. rst month) in 2009. Periodical Payment Framework . however. The dierent values of the <pay> elements to dene an odd on attribute dene non-overlapping periods thus producing a valid policy. This is the discounted rst payment that was used as an example earlier.e. 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.5 demonstrates the use of multiple transaction.Theory <payment-policy merchant-dn=CN=Merchant. A merchant can use this exibility in dening a periodical payment contract to overcharge its customers. From this example it is quite clear that regardless of the month during which a transaction is processed. To ensure that this is not possible. Extending the payment schema and validation logic to dene multiple <pay> elements is also useful was when solving issues with certicate cancellation. When validating a policy.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.C=AU payment-gateway-dn=CN=PaymentGateway.Chapter 4.

This is important as the same rules apply for the cancellation policies.OU=ITEE.ST=ACT.ST=ACT.O=UNSW.ST=ACT.OU=ITEE.O=UNSW.5: Periodical payment policy with two assertions example <payment-policy merchant-dn=CN=Merchant. Furthermore.2. 70 . Hence any ambiguity within this element causes the entire payment policy to be invalidated and rejected.O=UNSW.4. Also notice the url attribute of the <cancellation-policy> element.OU=ITEE. which are dependent on when the customer terminates this agreement. just like with the previous example (see Figure 4. 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.C=AU payment-gateway-dn=CN=PaymentGateway. 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.ST=ACT.6: Periodical payment policy with cancellation example In this policy cancellation example two <pay> assertions are used to declare two distinct fee struc- tures. Periodical Payment Policy Language <payment-policy merchant-dn=CN=Merchant.O=UNSW.C=AU payment-gateway-dn=CN=PaymentGateway.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.5) both assertions apply to dierent time periods with no overlap.3.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.OU=ITEE.

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).O=UNSW. As such.C=AU payment-gateway-dn=CN=PaymentGateway. The delegation of payment credentials from customers to merchants using X.ST=ACT. situations.509 restricted proxy certicates.OU=ITEE. gas.OU=ITEE. Such contracts are usually established without a termination date and can only be cancelled manually. for paying utility bills (e. to limit the scope of this thesis and in recognition that this problem is already being investigated. it cannot be used to initiate more transactions despite the fact that the policy allows it.Chapter 4. The use of proxy certicates for initiating and processing periodical payments. To x this a proxy certicate renewal service is required. It declares a quarterly payment of up to ve hundred dollars on the rst working day of every third month.3 Summary This chapter provided a detailed overview of the theoretical architecture for the periodical payment framework.2) it was discussed that there can potentially be policies that extend beyond the lifespan of the proxy certicates that represent them. However.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. earlier in this chapter (section 4.g. 2).O=UNSW.1. this task is left for the future (see Future Work section of Chapter 7 for a detailed discussion of possible solutions to this problem). Periodical Payment Framework .7 denes a periodical payment with an undened termination date. This would allow merchants to renew certicates holding open-ended policies before they expire. and 3). direct debit contracts are established for an indenite period. telephone) using direct debit it is not possible or practical to dene an end-date. An example in Figure 4. Such policies remain active as long as the proxy certicates that hold them are valid. Once a proxy certicate expires. It examined its three most signicant processes: 1). electricity. The non-malicious customer cancellation of 71 . 4.ST=ACT.Theory <payment-policy merchant-dn=CN=Merchant. In many real-life For example. Notice that the year parameter is not specied in the on attribute of the <pay> element.7: Periodical payment policy with no termination date example Finally. this policy will remain valid until the proxy certicate that holds it expires.

3.4. In addition. 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 . Summary existing policies. the complete language semantics of the policy language was presented with a number of real world examples describing its use.

509 proxies instead of standard certicates). using X. The main problems encountered were security related as the claimed theoretical compatibility of various mechanisms did not translate into practice (e. standards compliant and widely available. the major aim during the development of this prototype was ensuring that the technologies utilised were stable. Server-side components had their own set of unique issues despite the choice of technologies. 3. This solution consists of three distinct tiers: 1. 73 . as they would be most aected by the lack of compatibility and support.Chapter 5 Periodical Payment Framework Implementation In the previous chapter a detailed overview of the theoretical model for the periodical payment framework was discussed. Just like any traditional integration project a signicant amount of time was dedicated to making these technologies work together in this new way. The aim of this chapter is to present a concrete implementation of that architecture as a working prototype. Merchant payment processing service implemented as a J2EE web application. Client-side browser plug-in implemented as a Mozilla Firefox extension/add-on.g. This was especially important when developing customer-side components. Acquirer payment gateway web service implemented using the Apache Axis2 framework From earlier discussions. 2.

An overlay must reference the desired merge point within the 74 .1 Mozilla Firefox Browser Extension 5. This browser is built on top of a mature. 5. However. in the past these technologies have not been popular with the end-users. capturing a user's action of clicking a button to trigger opening of a dialog window). Each widget may be assigned one or more JavaScript action listeners.1.5. 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.2 Design Overview The entire Firefox graphical user interface has been implemented using XML User Interface Language (XUL). A merge point can be any Firefox widget that is already dened within the master document. which enables third-party developers to extend the core browser functionality with new features. which will reduce the level of user resistance to this approach. extensible framework that makes it simple (relatively) to dynamically extend its graphical user interface and behaviour. This trend is partially motivated by the growing popularity and development of the Mozilla Firefox browser. downloadable applications and applets were also considered.1. Opera and Apple's Safari browser are all moving towards a similar open.1 Design Rationale Using a browser extension to implement the client-side software needed for enabling proxy certicate delegation is a logical choice. for example. Browser plug-ins and extensions are becoming increasingly common way of distributing custom software to Internet users. which are designed to capture user activity and perform various functions (e. Other browsers such as Microsoft's Internet Explorer. Google Chrome. The process of downloading and installing Firefox extensions in particular is quite streamlined. Extending the default behaviour of the end-users' browsers at this stage seems like the safest approach with a high probability of success. 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). the status bar of the main Firefox window. extensible architecture. Firefox uses a concept of XUL overlays to dynamically change existing XUL screens at run time. This language allows developers to represent user interface widgets using predened XML elements. An overlay document is an XUL fragment whose contents are injected into the master document at a specied merge point.1. Mozilla Firefox Browser Extension 5.g. Other technologies such as standalone.

css" type="text/css"?> <!DOCTYPE <overlay overlay SYSTEM "chrome://wdfclient/locale/wdfclient.1: XUL Overlay Example document body using its unique identier. Periodical Payment Framework .js"/> <statusbarpanel class="statusbarpanel-menu-iconic" image="chrome://wdfclient/skin/wdfclient-icon-small.options. Additional features are superimposed onto the existing code base without making any changes to it.png"> <menupopup> <menuitem label="&wdfclient.e.Implementation <?xml version="1. such as Cross Platform Component Object Model (XPCOM) provide many more features but their discussion is out of scope for this thesis.xul"> <script type="application/x-javascript" src="overlay. 2009).menuitem.onMenuItemOptionsCommand(event)"/> </menupopup> </statusbarpanel> </statusbar> </overlay> <statusbar id="status-bar"> Figure 5. Overlays and other Firefox demonstrates how an overlay was used to add a panel to an existing Firefox status bar (alternatively. The concept of overlays is quite powerful as it allows for non-intrusive injection of custom code into an existing application.509 Proxy Certicate Signing Tool and for opening a conguration dialog window.onMenuItemOpenCommand(event)"/> <menuseparator/> <menuitem label="&wdfclient. Figure 5.0" encoding="UTF-8"?> <?xml-stylesheet href="chrome://wdfclient/skin/overlay.dtd"> id="wdfclient-overlay" xmlns="http://www.Chapter status-bar). This panel contains menu items required for manually launching X.menuitem. which is not the desired eect. For further 75 . discussion of these technologies refer to Mozilla Developer Center (Mozilla. refer to Appendix G for complete examples of XUL use within this dissertation).open. Notice the value of the id attribute of the statusbar element (i. Its value is important as it identies an existing widget within the browser window making this element a merge point." oncommand="ProxyCertReqObserver . Getting this value wrong creates a completely new status bar widget inside the main window.only." oncommand="ProxyCertReqObserver .

addObserver(ProxyCertReqObserver. false).getService(Components.http-on-examine-response. Figure 5.5.nsIObserverService) . 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. From the above example it is clear that topic which processes the certicate signing tool observer is bound to a all HTTP responses.1. 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. The Proxy Certicate Signing Tool overlay imports which denes a overlay.1] . the ProxyCertReqObserver observer was implemented to trigger opening of the proxy certicate signing tool dialog if a HTTP response matched the following conditions: 76 .2. 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.2).1. For this task a nsIObserverService was used which allows client listeners implementing nsIObserver interface to register to receive notications of various Firefox events.js JavaScript (see line 6 of Figure 5. This binding between the observer listener and a topic is made during observer registration using its addObserver method.interfaces. ProxyCertReqObserver script also registers the object using the observer service to receive HTTP responses. Since the http-on-examine-response observe method will be called for all HTTP responses.2: Observer Service JavaScript Example 5.classes[ This was done using one of many Firefox XPCOM services accessible via a JavaScript interface. aData) { // // } launch proxy cert signing tool if HTTP response contains proxy cert request } Components.1 X. aTopic.2 is an example of how this is implemented in practice.509 Proxy Certicate Signing Tool Using overlays it was possible to extend a Firefox browser to become periodical payment HTTP response aware. The code extract in Figure 5. Mozilla Firefox Browser Extension var ProxyCertReqObserver = { observe: function(oHttp.1) This ProxyCertReqObserver JavaScript object implementing nsIObserver interface. As such.

Figure 5. 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. Unauthorized) 2. The HTTP response contains a header attribute tReq WWW-Authenticate with a value of ProxyCer- Normally. Notice how the contents of the X-ProxyCertReq header attribute contain only HTTP safe cha- racters.e.Implementation Figure 5. In this framework. The HTTP response status code is 401 (i. The HTTP response matches both conditions presented above and as such will trigger opening of the Proxy Certicate Signing Tool. Base64 decoding of the proxy certicate request occurs during initialisation of the signing tool 77 .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. Periodical Payment Framework .Chapter 5. is reused whenever a merchant application wants to request a new proxy certicate from a customer. the standard HTTP response header attribute WWW-Authenticate dened in (Franks et al..3: HTTP Headers Response Example 1. 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).

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. For the prototype. However. It is ultimately customers' responsibility whether they choose to accept the terms under which the merchant will provide them with goods and services. 2007). the set of allowed values in each CRON eld is restricted to a xed number. The transformed policy is much easier to read than its raw XML equivalent which is depicted in Figure 5. as its contents need to be presented to a user. Figure 5. 2009). 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). 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. It remains an exercise for the future to change this code to use the preferred Firefox XPCOM services approach instead. Its only attempt at policy vali- 78 . Fortunately. 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. understanding the meaning of each assertion in isolation is not enough to be able to understand the entire policy. The most interesting part of this screen is the Proxy Certicate Policy Info section. Mozilla Firefox Browser Extension dialog window. 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.5. calling Java from a Firefox extension is not the most ecient approach.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. 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. This prototype provides a suciently easy to read transformation of the periodical payment policy for most customers to be able to understand each assertion.5. 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. Presenting such expressions in their native format to customers is clearly not a good option. specically PolicyTreeView JavaScript). 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. Using multiple <pay> assertions within the same policy document adds an extra level of complexity making comprehension of the policy document somewhat unintuitive.1. this logic was While implemented in Java using Bouncy Castle cryptographic Java API (BouncyCastle. It presents the periodical payment policy (refer to section 4.

Periodical Payment Framework .509 Proxy Certicate Signing Tool Example 79 .4: X.Chapter 5.Implementation Figure 5.

509 Proxy Certicate Signing Tool View XML Policy Example 80 .5.1.5: X. Mozilla Firefox Browser Extension Figure 5.

6 depicts a signing tool dialog window containing a periodical payment policy with two errors. Figure 5. specically PolicyValidator JavaScript). 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. This approach will ensure that migrating to an XPCOM implementation in the future will be easier. Figure 5. ProxyCertBuilder class accessed via JavaScript. Beside presentation logic. 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. Instead. The validation logic is currently not using any DTD or XML Schema checking. This will prevent a user from accidentally signing an invalid policy causing issues further on in the processing chain (i.Chapter 5. notice how in this case the Sign Proxy Cert button is disabled. 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.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. hence this extension prompts the user for a password before opening the keystore le and extracting a signature key from it. refer to Appendix H).7 demonstrates how this add-on can be congured to read signature keys from a le 81 . 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. at the payment gateway server which would reject this policy as being invalid). this prototype add-on does not use any of the Firefox XPCOM services for managing user certicates and keystores. this XML transformation and validation logic was implemented in JavaScript.e. Improving customer understanding of these policies is not something that can be easily automated. As was mentioned previously. Also. it must be congured to read a keystore le directly from disk extracting the signature key from it via Java code (i. Instead. 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. the proxy certicate signing tool implements features for creating and signing proxy certicates using merchant requests and customer signature keys retrieved from a keystore.e. For example. Keystores are generally protected by passwords. however. Periodical Payment Framework . The rst error is related to a missing element.

6: Error Example 82 . Mozilla Firefox Browser Extension Figure 5.5.1.

bks) le is chosen.8 for an example). which is then forwarded to the merchant server via the HTTP method POST.Implementation Figure 5. pressing the Sign Proxy Cert button initiates the nal step in this process. a method ProxyCertBuilder signProxyCert implementing the logic for creating and signing a proxy certicate and encoding it using base64 encoding scheme.Chapter 5. Once a customer is happy with the terms of the agreement and provided that the policy XML is valid. 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. keytool command line utility. Figure 5. Periodical Payment Framework . In this example. 83 . accepting the password string and for passing all of the relevant information to the ProxyCertBuilder Java class.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. 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.jks). It is responsible for opening the dialog window. It returns the base64 encoded proxy certicate. supports. a Bouncy Castle Keystore (i. such as class denes the keystore path. its password and the proxy certicate request. *.509 Proxy Certicate Signing Tool Conguration Example based keystore.e. Both formats can be used with the Java *.e. There is only a thin layer of JavaScript code in this step.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. Bouncy Castle which this extension also keystore format is similar to the Sun keystore implementation (i. 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.7: X.

Mozilla Firefox Browser Extension Figure 5.5.8: Signing Proxy Certicate Example 84 .1.

however. is stored in the second request attribute. 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.. HTTP Headers Request Example Authorization. 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. Periodical Payment Framework . et al.9: The rst attribute. a receipt/tax invoice screen.Implementation Figure 5. which is precisely how it is used in this framework as well. The actual proxy certicate payload. Once the proxy certicate is forwarded to the merchant server. 1999). In this case.Chapter 5. this custom attribute carries a base64 encoded proxy certicate produced by the certicate signing tool extension. for example. 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. 85 . 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. X-ProxyCert. It is commonly used directly as a result of receiving a 401 (Unauthorized) status code from the server. Specically. How the merchant uses the proxy certicate from this point is covered in detail in the next section.

see Chapter 3) has failed due to the lack of support from merchants.2 Design Overview The merchant web application architecture consists of three distinct components: 1.5. More changes are needed to make merchant applications aware of the new payment gateway web service. As such. Proxy Certicate HTTP Filter . 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. Only minor changes are needed thereafter for the merchant to take advantage of the work that is performed inside the lter (e. Depending on how well the merchant application is designed. 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. Merchant J2EE Web Application . changes should only be required in the layer responsible for the payment instruction creation.responsible for negotiating with the client browser to receive a proxy certicate for use during payment processing. Merchant Payment Processing J2EE Web Application 5. this prototype relies heavily on the J2EE interceptor servlet lter design pattern for implementing logic for obtaining proxy certicates from clients.2. It was costly to implement and required signicant infrastructural changes to make it work with existing e-commerce applications. Noting that some changes are unavoidable the aim was to minimise disruption as much as possible. Specically.1 Design Rationale The last signicant attempt at introducing change into electronic commerce environment (i.2. 86 .2 Merchant Payment Processing J2EE Web Application 5.2.the core (possibly legacy) business logic of the merchant electronic commerce business.g.e. 5. proprietary transport and interface layers. dispatching and response processing (assuming proper abstraction was used when creating these services). 2. accessing proxy certicates from a keystore populated by the servlet lter during its authorisation process). 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. SET. 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.

Figure 5. 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. A high-level architecture of the merchant application is depicted in Figure 5.Implementation Figure 5.Chapter 5. authentication.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.10.e. This design pattern allows for pre-processing of HTTP requests before they reach their target by passing them through a collection (i.2. chain) of lter objects each one responsible for performing a particular task on it (e.g. 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.wrappers around client-side stubs generated from payment gateway Web Services Denition Language (WSDL) for dispatching payment instructions and processing responses. logging. The choice of using an intercept lter in a J2EE environment is heavily inuenced by its independence from the application code.10: Merchant Web Application Architecture 3.xml) rather than programmatically. The following is a discussion of each component of this architecture.g. validation. Periodical Payment Framework .11 adopted from (Sun. Payment Gateway Web Service interface . web. etc).2. In fact. 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. 2002) depicts a core J2EE servlet lter design pattern. 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 for more detail). At this stage the request is blocked and is not allowed to continue to its destination (i. This step involves creating a new public/private key pair and generating a proxy certicate request (see Section 4. the ow of HTTP requests in this part of the framework can be described as follows: 1. 1b).10 except with slightly more detail. This protected URL is congured via web.5. (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. ProxyCertHTTPFilter is congured to intercept requests directed towards a specic URL pat- tern. Its purpose is to initiate this process. Most HTTP requests directed towards the merchant web application are forwarded directly to their destination without going through the ProxyCertHTTPFilter. HTTP Interceptor Filter Design Pattern Figure 5. These are standard requests generated as the user navigates through the merchant web site (1a. (a) The original HTTP request received by the ProxyCertHTTPFilter contains no security information. The message ow presented in this diagram is exactly the same as in Figure 5. 2.2.1. Merchant Payment Processing J2EE Web Application Figure 5. 88 . Part of the merchant payment workow is to direct the user to this URL thus indirectly invoking this lter. Specically.12 depicts a concrete implementation of the interceptor lter pattern.11: added functionality).e.xml and is expected to be reserved for initiating the proxy certicate request process. a page or action within the merchant web application).

Earlier in this section it was stipulated that the ProxyCertHTTPFileter could be declaratively congu- red into an existing J2EE application without aecting its implementation. e. 3.Chapter 5. Subsequent HTTP responses created by the merchant web application go straight to the client. 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.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.13 demonstrates how this was done for the prototype merchant application.g.Implementation Figure 5. Periodical Payment Framework . it includes a reference to as all conguration parameters that it needs to do its job. however. Lightweight Directory Access Protocol (LDAP). 4. policy-template) that is used to generate periodical payment policies 89 . This proxy certicate is validated and stored inside a keystore. Once a proxy certicate is obtained. development of this is out of scope for this thesis). The <filter> XML element denes the implementation class of the interceptor lter as well Specically.e. 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. Figure 5. a le keystore is the only supported option. Currently. which can then be accessed by the merchant web application when making payments. a policy template le (i. it is possible to extend this implementation to use alternative means of storing proxy certicates. For a production deployment.

e. this parameter should be extended to contain a list of templates for the lter to choose from based on usage context. in a production system this le would contain placeholders for various parameters that can only be provided at run time (e.2. which will only happen if a proxy certicate is created and is successfully stored within the keystore le on the merchant's server. denes the URL pattern to match when deciding whether to apply this lter or not (this task is performed by the servlet container.jsp will only be returned to the customer's browser if it gets past the lter.2.13. Jetty. 5. Complete reference implementation of the ProxyCertHTTPFilter class is provided in Appendix I.jsp) The resource at the end whenever it wanted to obtain a new proxy certicate from a customer. 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. keystore. Merchant Payment Processing J2EE Web Application inserted into proxy certicate requests. the merchant application must be changed to utilise the new payment gateway web services interface.g. from this example.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. of this URL is protected in a sense that the user will only get to it if a valid proxy certicate is provided.g.5. http://localhost/merchant/proxy/authenticated. etc). the contents of authenticated. as changes are still needed for the merchant application to take advantage of the added functionality. This part of the lter can also be extended if other keystore data sources are to be used instead of a simple le keystore.jks KEY_STORE_PASSWORD=password The next XML element in Figure 5.g. As such. contract dates. as a future enhancement. Fortunately. prices. For the prototype this le contained the entire policy that was inserted into certicate requests unchanged. <filter-mapping>. Apache Tomcat. The prototype merchant web application was designed to direct a customer to a URL containing a proxy keyword (e. however.2. these changes should be conned to a single area of the merchant code and should not be 90 . Using an interceptor lter only partially achieves this goal. Furthermore. The second parameter. Instead of calling a legacy payment gateway using its proprietary communication protocol and data structures. 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. The data structures required for calling this web service are also dierent and must be constructed by the merchant application as well. etc).

account to and from. processPayment.g. due to unique properties of periodical payments a new standalone service can be written (this can even be a generic.Implementation <filter> <filter-name>ProxyCertHttpFilter</filter-name> <filter-class>au. amount. 91 .Chapter 5. Alternatively.adfa.</param-value> </init-param> </filter> <filter-mapping> <filter-name>ProxyCertHttpFilter</filter-name> <url-pattern>/proxy/*</url-pattern> </filter-mapping> Figure 5. vendor product) that works independently of the merchant web application.xml</param-name> </init-param> <init-param> <param-name>keystore</param-name> <param-value>keystore. PaymentProcessingService to initiate transactions by creating instances of PaymentInstruction classes containing information about a single payment (e. the merchant payments processing servlet used Using its sole public method.e. Its purpose would be to schedule payment tasks and process them when required.ProxyCertHttpFilter</filter-class> <init-param> <param-name>policy-template</param-name> <param-value> 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. Periodical Payment Framework . This service can be congured into ProxyCertHTTPFilter as a keystore data source. 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. Most of this logic was encapsulated in the PaymentPorcessingService class. This approach would have a minimal (if any) impact on current merchant applications. WSDL2Java utility as a wrapper for the payment gateway web services stub (i. which served PaymentProcessingServiceStub) class.13: Proxy Certicate HTTP Filter Conguration Example dicult or expensive to change (although the amount of subsequent testing required is signicant). http://localhost/axis2/services/PaymentProcessingService?wsdl). As a proof of concept. description.g.unsw.filter.

X509KeyManager and javax. Payment Processing Service Class Diagram the default implementation of SSL (i. Merchant Payment Processing J2EE Web Application Figure 5. The PaymentProcessingServiceSub abstracts the communication layer between the merchant application and the payment gateway. The design of this part of the application is depicted in Figure 5. 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. it was possible to overcome these limitations by replacing the default security provider used by the merchant application with a custom implemen- 92 .e. based on which customer is being charged). as the merchant must always go through the SSL handshake so that it could present the certicate relevant to the currently executing payment transaction. It assumes that all HTTPS requests to a single.5. The returned object. 2. would indicate a success or failure of this operation.ssl.2. javax.14.SSLSocketFactory) as developed by Sun has two signicant limitations: 1. It relies on the standard Java implementation of HTTP (and SSL) to handle the physical communication between the two servers. As such. Java provides an elegant mechanism for making new security providers accessible to Java applications without making programmatic changes to them. unique host will be authenticated using the same certicate from one (and only one) keystore. To enhance performance.e. This eectively prevents the merchant from authenticating to the payment gateway using a proxy certicate of its choosing (i. This is problematic.ssl.14: etc).net. Unfortunately.

such as the success or failure of the payment transaction. 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. 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.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.2.Chapter 5. 5. 2008).2. the standard approach.This inner class is also a simple Java bean object. • PaymentProcessingServiceStub.PaymentReceipt . and transaction description.2.2 the payment gateway web services interface is exposed to the merchant application via a wrapper class generated using the PaymentProcessingService.e. Its role is to carry information back from the payment gateway to the merchant. • PaymentProcessingServiceStub. see Sun.This inner class represents a simple Java bean object that encapsulates payment order instructions from the merchant to the payment gateway. however.PaymentInstruction . It is envisaged that for a production system. The WSDL from which the above classes are generated is included in Appendix B. The stub classes auto- WSDL2Java Apache Axis2 utility include the following: • PaymentProcessingServiceStub . It is also responsible for receiving responses from the payment gateway web service wrapped in a ProcessPaymentResponse class.2.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.3 Payment Gateway Web Service Interface As was already mentioned in section 5. 93 . The implementation of the security provider together with instructions on how to congure it. is described in Appendix D. Periodical Payment Framework . this complexity would have to be introduced back in to handle the various intricacies of real life situations. It contains such attributes as: to and from account numbers. amount.

the proxy certicate validation was disabled with the payment processing service still functioning as per normal. However. 5. as a starting point. These types of web services are based on an architectural style called Representational State Transfer (REST). 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. Acquirer Payment Gateway Web Service 5.5.2 Design Overview For this dissertation.g. Its aim is to simplify the web services stack by favouring common Web conventions over W3C-style standards.D. This is especially important in the current electronic commerce environment in which there are a multitude of applications all developed using dierent programming languages. Web services running on the Axis2 platform can be declaratively congured using XML les.3. 94 .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. As such.3. SOAP) these types of services are more ecient than using the traditional approach. By minimising the feature stack (e.3. They can build their own using the WSDL accessed directly from the payment gateway site. Roy Fielding rst used this term in his Ph. which acts independently of the main payment gateway web service business logic. Unlike existing payment gateway interfaces. making changes to one of the components has no eect on the other. web services have been used in numerous commercial applications where decoupling of components and interface exibility is of particular importance. In recent years the term RESTful web services have gained popularity. ecient architecture that is highly congurable.3 Acquirer Payment Gateway Web Service 5. 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. the Apache Axis2 open source engine was selected to provide the web services feature stack required. dissertation (Fielding. So far. 2000). In fact. this dissertation follows the traditional model of web service development leaving REST as a performance enhancement task for the future (if required). at one point for testing purposes. web services abstract the client from the physical implementation of the service. Axis2 has a mature. The payment gateway presented in this thesis relies on this architecture to congure a security handler. which means that merchants will no longer require proprietary libraries supplied by the payment gateway providers to process transactions.

Periodical Payment Framework . As such. This gure depicts a fragment of a large conguration le used for initialising an instance of the Axis2 engine. 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). 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. In particular. a lot of the detail involved in actually conguring a fully functional web service is not included. 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. the process that it depicts can be described as follows: 95 . These two components are independent. 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. This particular approach implies that the policy handler will apply to any web service running within this particular instance of the Axis2 engine. Getting back to Figure 5. The only exception to this style was for the Proxy Certicate Policy Handler component. In actual fact. The focus of this diagram is on the components that had to be designed and implemented for this thesis. Notice how at this stage the actual web service implementing the payment processing logic is not congured.Chapter 5.Implementation Figure 5.18). as will be discussed later when the implementation class for this handler is presented (see Figure 5.15 depicts a high level architecture of the payment gateway web service deployed using the Axis2 engine.15. This component belongs in the InFlow security phase.15: Payment Gateway Web Services High Level Architecture Figure 5. the ins and outs of the InFlow and the OutFlow phases have been combined into two components: In Flow Modules and Out Flow Modules. however.16. Acquirer Payment Gateway Web Service <phaseOrder type="InFlow"> <phase name="Transport"> <handler name="RequestURIBasedDispatcher" class="org.RequestURIBasedDispatcher"> <order phase="Transport"/> </handler> <handler name="SOAPActionBasedDispatcher" class="org.axis2.16: Fragment of axi2.3.DispatchPhase"> .apache.apache..axis2.ProxyCertPolicyHandler"> <order phase="Security"/> </handler> </phase> <phase <phase </phase> ...5.axis2. Figure 5.axis2.xml conguration le 96 .dispatchers.engine..adfa. <phase <phase </phaseOrder> name="MessageOut"/> name="Security"/> name="PreDispatch"/> name="Dispatch" class="org. </phaseOrder> <phaseOrder type="OutFlow"> .SOAPActionBasedDispatcher"> <order phase="Transport"/> </handler> </phase> <phase name="Addressing"> <handler name="AddressingBasedDispatcher" class="org.AddressingBasedDispatcher"> <order phase="Addressing"/> </handler> </phase> <phase name="Security"> <handler name="ProxyCertPolicyHandler" class="

17: Tomcat SSL Connector Conguration (server. web services) are accessed in the same way as actions in any standard J2EE application. <Connector port="9443" SSLEnabled="true" minSpareThreads="200" maxSpareThreads="250" maxThreads="400" scheme="https" clientAuth="true" sslProtocol="TLS" secure="true" keystoreFile="conf/localhost. By choosing to use HTTPS the merchant is forced to provide an X. note that the default HTTP connector does not have to be disabled to secure this web service. In this step. For example. Periodical Payment Framework . This attribute tells the connector to request an X. It relies on the fact that the merchant making the request will authenticate itself using a proxy certicate. HTTP over SSL) protocol. For example. This same technique is used when the framework eventually invokes the 97 . After the SSL handshake is completed the SOAP request is allowed to go through to the Axis2 engine.16. Its resources (i.jks" keystorePass="password" truststoreFile="conf/localhost. 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.Chapter 5. Notice the connector attribute clientAuth=true. 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.509 certicate by the Apache Tomcat web server congured for mutual authentication.509 certicate The received certicate is authenticated and the from the caller during the SSL handshake. 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. Notice how Axis2 is just another web application deployed into the Tomcat container. 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.xml) 2. notice how the original HTTP request is converted into a MessageContext class used in step 3.Implementation 1.e. The payment gateway web service was designed to be accessible via a HTTPS (i. request is allowed to proceed to its target (in this case a web service running within the Axis2 engine).17.jks" truststorePass="password"/> Figure 5. the gateway's payment processing service is accessible via this URL: https://localhost:9443/axis2/services/PaymentProcessingService Also.e.

(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. Eventually the Axis2 engine will invoke the PaymentProcessingService using its processPayment method (see Figure 5.e.18). Both the payment instruction as well as the actual date of the transaction (i. Handler This class is a custom implementation of a interface responsible for validating the request against the proxy certicate policy. 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. the current invocation date) must have a corresponding assertion within the policy allowing this transaction.18). 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.19). This information is available from the raw HTTP request accessible via the MessageContext instance (see getCertificateChain method in Figure 5. 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.1.5.e. 3.18). this web service was built using the POJO (Plain 98 .e. 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. In general. The rst certicate in the chain should always be the policy carrying proxy certicate. 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. 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. At that point a class is used as an input parameter instead of its SOAP equivalent. Acquirer Payment Gateway Web Service PaymentProcessingService PaymentInstruction web service in step 4. amount limit values are specied). it assumes that the caller of the payment service authenticated using a proxy certicate). In particular.509 certicate chain used to (b) Provided that a PaymentInstruction authenticate the caller to the web service. exists retrieve an X.3. For example.3. 4. For the prototype.

MC_HTTP_SERVLETREQUEST). private PaymentInstruction getPaymentInstruction(MessageContext msgCtx) try { OMElement methodElement = msgCtx. new Class[] { PaymentInstruction.X509Certificate"). proxyPolicy.getObjectSupplier()). return (PaymentInstruction) params[0].request.g. } return } InvocationResponse. } catch (AxisFault af) { return null.amount } private } private } } Figure 5.CONTINUE. if (pi != null) { X509Certificate[] chain = getCertificateChain(msgCtx). certInfo.Implementation public . msgCtx ..deserialize(methodElement. ProxyPolicy proxyPolicy) { // compare proxy policy vs payment instruction. Object[] params = BeanUtil. class ProxyCertPolicyHandler extends AbstractHandler { public InvocationResponse invoke(MessageContext msgCtx) throws AxisFault { PaymentInstruction pi = getPaymentInstruction(msgCtx).Chapter 5.amount == paymentInstruction. validate(pi.18: ProxyCertPolicyHandler class 99 ..getProxyPolicy()). Periodical Payment Framework .class }.509 certificate void validate(PaymentInstruction paymentInstruction.getAttribute("javax. return (X509Certificate[]) req .getBody() .getEnvelope().getAxisService(). // e.getProperty(HTTPConstants.getFirstElement(). ProxyCertInfo certInfo = getProxyCertInfo(chain[0]).servlet. ProxyCertInfo getProxyCertInfo(X509Certificate cert) { // extract and return ProxyCertInfo from X. } } private X509Certificate[] getCertificateChain(MessageContext msgCtx) { HttpServletRequest req = (HttpServletRequest) msgCtx .

return paymentReceipt. paymentReceipt.e.. (b) Which Java class to use as a web service implementation (see <parameter name=ServiceClass> in Figure 5.20).3.. The actual business logic inside the PaymentProcessingService class is somewhat limited.5. } Figure 5. 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.20). A message receiver uses this information to instantiate the required class and to invoke methods on it. public PaymentReceipt processPayment(PaymentInstruction paymentInstruction) { // call legacy payment gateway and get response PaymentReceipt paymentReceipt = new PaymentReceipt()..xml (see Figure 5. The services. The Axis2 engine generates the WSDL automatically whenever it is requested via a special URL query parameter: wsdl. in step 1 the following URL was used to access the payment gateway web service: https://localhost:9443/axis2/services/PaymentProcessingService 100 . 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.19: PaymentProcessingService class Old Java Object) approach. Notice how dening a web service using the POJO approach relieves the developer from having to construct a WSDL manually. That is. paymentReceipt.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. For example.setPaymentGatewayId(PAYMENT_GATEWAY_ID). required method to invoke through Java reection and then deserialising the input parameters from the SOAP message into Java objects. PaymentProcessingService).setId(generatePaymentReceiptId()). } . Acquirer Payment Gateway Web Service public class PaymentProcessingService { . It is also responsible for serialising the output of the web service back to SOAP. paymentReceipt..setPaymentInstruction(paymentInstruction).

an unauthenticated request is made via HTTP.receivers.16). 5.e. Just like with the InFlow security phase.PaymentProcessingService </parameter> </service> Figure 5.service. consider the following restriction: on=* * * 1W * ? 2009 (i. This is possible because (as was discussed in step 1) the HTTP connector was left enabled allowing unauthenticated access to some server resources. Only if it was. on the 1st work day of every month in 2009) 101 .gov. Instead of using HTTPS.Chapter 5. 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. proceed to the next step.adfa.RPCMessageReceiver" /> </messageReceivers> <parameter name="ServiceClass"> au.e.20: Axis2 Web Service Conguration (" class="org.apache. a similar approach could be taken to inject additional functionality into the OutFlow security phase.rpc.w3. Periodical Payment Framework .ws.18 extract the X. As with the incoming messages. (b) Following the technique from Figure 5. For example.unsw.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. PaymentReceipt) go through various phases of the Axis2 en- gine (see Figure 5. adding entries to the TRL could be done at this point.509 proxy certicate from the request and obtain a policy statement from it.Implementation <service name="PaymentProcessingService" scope="application"> <description>Payment Gateway: Payment Processing Service</description> <messageReceivers> <messageReceiver mep="http://www. For example. the outgoing responses wrapping the return value of the processPayment method (i.axis2. (c) Add (or update) entry in the global TRL revoking the use of the proxy certicate for the period specied within its policy.

A similar problem has already been discussed in the context of the merchant application in the previous section. Leaving the connes of the Axis2 As such. The end-entity certicate must be signed by a certicate authority (CA).e. However. 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.5. proxy certicates break both of these conditions as they contain two end-entity certicates: the proxy and the certicate that signed it (i. The SSL handshake process is generic and allows X. The solution in that case was to extend the default behaviour of the security 102 .509 proxy certicates to be used instead of the standard X. This technique was successfully used during the testing of the prototype. 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). 6. The end-entity certicate must be the rst and only end-entity certicate within the certicate chain. Unfortunately. Whilst changing certicates is sucient for testing. this approach is inadequate as a long-term solution. 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. issuer of the proxy certicate). and 2.ssl. proxy certicate authenticated requests to the 1. By adding a CA basic constraint to their content each customer certicate becomes a CA certicate.X509TrustManager As such. class) does not support proxy certicates.509 certicates since both are structurally similar. Tomcat server are always rejected. the underlying Java implementation of the certicate chain validation logic as provided by Sun (i. One way to x this is to change customer certicates. 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. The default certicate chain validation implementation makes the following assumptions about client certicates used for authentication: javax.e.e. Acquirer Payment Gateway Web Service An entry in the TRL for the month of March would specify: revoke=* * * 1W MAR ? 2009 (i. an alternative approach is hereby proposed.3.

The However. a custom security provider was needed that would implement a dierent certicate chain validation logic that would recognise proxy certicates as valid. Acquirer payment gateway web service.e.g.Implementation X509KeyManager provider. Grid Security Infrastructure of the Globus toolkit). some problems were also discovered with the default Sun implementation of JSSE. X509TrustManager and related classes is described in Appendix 5. 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. most of the implementation of these three components followed a standard process. Using a similar approach as the merchant web server.1.. even writing this logic from scratch is not an issue as this process is well document in the X. The same approach is also needed here as well. Periodical Payment Framework . instead of the key manager. While it was possible for the merchant to use proxy certicates for authentication. 103 . 2). it is the X509TrustManager default certicate validation logic can be replaced with proxy certicate aware code. Also.Chapter 5. Even though some tweaking of the various components were necessary. Specically. All three components were developed using existing technologies and integrated together via a common transport protocol: HTTP. Similar JSSE implementation issues were encountered at the payment gateway. Firefox plug-in implementing Proxy Certicate Signing Tool. A possible implementation of the D (see section D. Beside the traditional implementation issues encountered during any multi-tiered application integration project. and 3). a lot of eort in implementing the merchant prototype was expanded on solving these issues via a custom security provider. There are plenty of open source and commercial Java libraries that can validate proxy certicate chains (e.4 Summary This chapter presented an overview of the implementation of the three major components of the periodical payment framework: 1). class that needs customising. As such. Alternatively.2). All three were implemented using current.509 Proxy Certicate specication (Tuecke et al. payment gateway) within a multi-threaded environment. Merchant J2EE web application. 2004). 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. specically the class. the default JSSE implementation on the payment gateway web server considered such certicates invalid.

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

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. For example. 6. The focus of this analysis is on the impact of introducing SSL Some discussion on mutual authentication using restricted proxy certicates into the framework.Chapter 6 Performance Analysis This chapter presents a detailed analysis of the performance of the periodical payment prototype discussed in the previous chapter. Having little reference data to start with. PayPal and Google Checkout are both introducing web services over SSL although neither use mutual authentication. As such. This approach is the most logical choice given the lack of benchmark statistics to compare results with. using web services as a communication layer is also presented. although it is not the main focus here. These estimates have been derived through observation only and have been used solely as a starting point. 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. the aim of this exercise was to collect enough empirical data to make reasonable conclusions regarding its overall performance. Unfortunately. 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. The testable architecture of the periodical payment system consists of three distinct tiers: 105 . The real challenge in analysing an online electronic payment application is in nding benchmark data to compare it with.1 Test Methodology and Scope A quantitative approach was chosen for testing the periodical payment prototype.

however. that these individual components of the web service architecture are not by themselves of interest. of course. 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. per minute. The client side browser plug-in. during testing it was observed that creating proxy certicates took approximately thirty seconds. It is in fact the combined eect of each component that will be analysed. executing the Java code. The major focus of this chapter is on the performance of the communication mechanism between the merchant server and the payment gateway. equally important. The acquirer payment gateway web service. That is. and 3. 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. This exchange is. this extension is likely to perform in fraction of this time even on older platforms. take up to a minute. the performance characteristics of the browser plug-in are not analysed in this thesis.1. at times. As such. The test conguration with no SSL authentication is quite useful 106 . how many requests can the payment per second. etc). however. This includes running JavaScript to extract HTTP request header parameters. Instead. It is gateway web service process for any given time interval (e. The performance can be improved by redeveloping this extension using a native XPCOM/C++ language. 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. Test Methodology and Scope 1. Considering that currently payment transactions over the Internet can. When analysing the performance characteristics of the payment gateway service the key question that is of crucial importance is its overall capacity. due to its infrequent use its performance is less likely to cause issues and impact its acceptance. performance data will not be collected for each individual sub-component of the web service. In other words. however. launching the JVM from within the Firefox extension. it is reasonable to assume that comparable performance for this application would be acceptable. returning control back to the calling JavaScript and nally sending a HTTP response message back to the merchant server. 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. The merchant payment processing server. It should be noted. For example.g. 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.6. Realistically. 2.

which was implemented as a web application. As such. Ethernet connection.1 for complete test hardware specication). using a mock server makes it a lot easier to recongure it to either use client-side certicates or not. it was necessary to develop a mock merchant server to simulate processing of payment transactions. To eliminate the complexity of the real merchant server. 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.Chapter 6. 6. As such. 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). These computers were networked directly with each other using 100Mbps 107 .2 Test Conguration 6. Even though the number of concurrent transactions in the test environment cannot be scaled to a realistic number. As was stated previously. Eliminating the additional overheads of the merchant application server meant that the extraction of useful measurements was easier. each test run must simulate execution of multiple concurrent transactions. 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. the results obtained can be used as a starting point with the rest of the data extrapolated to depict a realistic load. 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. server-side certicate authentication test is needed since this form of authentication is prevalent on the Internet today. a linear extrapolation technique could be used to predict the behaviour of the server in a production environment.2. It removes unnecessary overheads added by the web container. On the other hand. Having this mock server simplies both the execution of tests and the collection of data. In addition. Performance Analysis for establishing a baseline/benchmark to compare other results with.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.

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.2. a unique merchant server that uses it as its acquirer).6.0 GHz Intel Pentium M 1.0_02-ea 6. 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. Execution times were logged to a log le. Unique certicates were needed to ensure that the merchant or the payment gateway could not cache credentials and 108 . When testing SSL mutual authentication.0. receiving a response and un-marshalling the response into a Java object. Test Conguration PC Merchant Payment Gateway CPU AMD Athlon 64 (3000+) 2.3 Table 6. Note: the times recorded include obtaining a reference to the web service (done for every call). 6. sending the message to the payment gateway. Validating the response was not included in the calculation.2 presents the most important software packages used to execute both the merchant service and the payment gateway application. • Each merchant thread invoked the payment gateway web service 100 times simulating processing of its users' periodical payments.6. each test was initialised with a set of pre-generated unique proxy certicates (16000 certicates in total) needed for client authentication.2: Software for Merchant and Payment Gateway Applications 6. each thread representing a payment gateway user (i.2.14 1.1: Test Machine Conguration NAME Java Apache Tomcat Apache Axis2 VERSION 1.e. • • All responses were validated to make sure that they are correct.2.2 Software Requirements Table 6. constructing the SOAP message.5GHz RAM 1GB 512MB OS Windows XP Professional Windows XP Home Table 6.

The use of a custom SSL socket factory was only needed when using mutual authentication. 100 service requests times the number of threads: 100 or 120 or 140 or 160). an SSL 109 . Socket Extension (JSSE) provider implementation.2. a custom SSL socket factory was required to replace the standard factory provided by Sun. the use of client-side certicates was disabled. depending on which test was executed (i. the new socket factory was needed to override the SSL session caching behaviour delivering a unique SSL session per socket connection. Performance Analysis reuse them across multiple sessions.2. Normally. When using the standard socket factory. Unfortunately. the performance of the custom proxy certicate validation logic was separately logged.Chapter 6. the standard SSL socket factory implementation was sucient. As discussed in section 5. An Apache Tomcat servlet container was used to host the payment gateway application. below were executed using Tomcat's default SSL conguration. As such. That is. parsing the policy using an XML parser and performing validation of the payment instructions against the policy rules. In total.509 proxy certicate. All tests described Tomcat provides a variety of exible mechanisms for conguring SSL engines.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. JSSE was selected as a starting point to determine a benchmark to work from. up to 16000 incoming messages were expected. It should be noted that the payment gateway delegates SSL certicate authentication to the web server. For other tests.2. This code is also a likely candidate for containing performance problems as it requires processing of an X. 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. 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. In addition.e. this feature breaks the periodical payment principles. as the merchant must use a dierent certicate for each individual connection to the server. It is recognised that for improved performance and scalability an alternative approach would be required. Each certicate contained a unique distinguished name and a policy whose amount value was also dierent to other policies within the test set. it uses Sun's Java Secure While there are alternative providers for SSL with faster implementations.2. 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. extracting the policy from it. 6. Alternatively.

there were no payment policies to verify them against).1. Tomcat was recongured once more to enable server-side certicate authentication only. It includes three sections that describe the three payment gateway congurations under which the tests were executed. Payment gateway service was recongured to allow the merchant application to execute web service methods using server-side certicate authentication only. All information passing between the merchant and the payment gateway in these tests was in plain text.1. 12000.3.3. 3. the following congurations were used: 1. This eectively forced the merchant to provide a proxy certicate when executing a payment transaction. the payment gateway was also able to validate payment instructions using the policies retrieved from client certicates (section 6. In addition. 120.3 Discussion of Test Results 6.3. Under each test conguration the payment gateway was subjected to loads of 100. Just like in the previous test conguration no validation of payment instructions was undertaken. In these tests the communication between the merchant and the payment gateway was encrypted but the payment instructions were executed unveried (i. however. 14000 and 110 . Payment gateway service was congured with SSL disabled. Finally. 2.3. Communication between the payment gateway service and the merchant was in plain text with no security at all.1.3. In addition. and 160 concurrent connections producing in total 10000. each test was executed four times. Tomcat was recongured for tests not requiring SSL by disabling its SSL connector. Payment gateway service was recongured once more to require client-side certicates for authentication. This approach mimics the authentication paradigm currently used online for most payments.e. 140. all communication between the merchant and the payment gateway was encrypted (section 6. To validate consistency of test results and to ascertain payment gateway performance under load.1). Discussion of Test Results hardware accelerator could be used to gain even further improvements in performance by performing all cryptographic operations solely in hardware.6. 6. These tests were required to determine what eect authentication and channel encryption had on performance.1 Test Results and Analysis In this section the test conditions and subsequent results are discussed in more detail.3).2). payment instructions received from the merchant were processed without validation (section 6. In particular.

1. Performance Analysis 16000 requests. 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. a baseline needs to be established. 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).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. it is reasonable to expect better performance gures from the periodical payment framework. 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. Linear Correlation of Test Results Due to the limited resources available for testing. it is sucient to simply quantify the impact on performance by measuring the dierence in execution times between each test run. it takes marginally longer to execute each request. however. 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. As the load on the payment gateway server increases. It remains an exercise for the future to re-run these tests using more capable hardware. For now. 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. that better reects that likely to be used by merchants and payment gateways.3. At this stage it is not important which part of the Axis2 web services framework is causing the most impact. Not only is the cryptographic key exchange required before communication begins but also all sent messages must be encrypted. 6. Given such capable hardware. For example. The outcome of running these tests in this server conguration is predictable. That will be examined later in this chapter. Alternatively. Before the impact of SSL on performance can be measured. 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.Chapter 6. Unfortunately. 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. 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 .

1: SSL Disabled: Average request processing time ment. merchant threads). In conjunction with a linearity test. 120. Considering that performance degradation is unavoidable. 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.1. At this point it is dicult to judge the gradient of the trend line since there is nothing to compare it with.3. the PMCC of 0. slope) of the trend line must also be examined.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. Discussion of Test Results Figure 6. the gradient (i. Linearity of the trend line can be substantiated using the Pearson's Product Moment Correlation Coecient (PMCC). This will be done later in this chapter when the results of all three test congurations will 112 .e. Figure 6.6.e. visual indication that performance degrades linearly as the number of connections rises.1 demonstrates the impact on performance of the payment gateway server by plotting the average processing times for 100. The trend line gradient determines the rate with which performance degrades as the server is overloaded. Drawing a trend line across the graph gives a good.62x − 93. It would be considered an ideal outcome if the trend line exhibits a gradual incline across all three test scenarios. a linear impact on performance is an acceptable outcome. 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. 2006). 140 and 160 simultaneous connections (i. In this case.

Volatility of Test Results There is a signicant number of unique requests that are generated for each test. In theory. Performance Analysis Figure 6. signicant increase. SSL Disabled: Distribution of total request processing time On their own. spread) of the data. times between 140 and 160 simultaneous connections is approximately 300 milliseconds. At its peak. The greater the dispersion (i. Ideally. With such large number of requests it is important to determine how ecient the server is at processing each one.e. the dierence in average processing This is a increases in the number of concurrent threads. the more volatile the performance of the payment gateway server. the results seem somewhat excessive considering the relatively small For example.2: be compared. 113 . the rate with which this occurs is slow proving that the server is stable and capable of handling the increasing load. 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. It is to be expected that as the load on the server increases.Chapter 6. the dispersion of the data grows as well. the payment gateway server is forced to process 160 simultaneous requests (16000 in total). the time it takes to process a single request should not vary greatly. Analysing distributions between all four sets of test results should yield a clear indication of how volatile the performance is under increasing load.

The reasons for such high levels of variance are dicult to isolate. With each additional thread the volatility of the server increases as the execution times are spread over a larger time frame. • Merchant service may also experience performance degradation as the number of threads it needs to execute concurrently increases.2 as outliers. is 1170 milliseconds. the execution times between requests are volatile. As will be explained later. This may equally apply to both the payment gateway and the merchant service. 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. initialisation of threads. The statistical distribution in Figure 6. As predicted it reveals that as the number of threads grows. However.6. Of course. explanations. This has the eect of attening the distribution curve as the server is overloaded. Containing 50% of all requests. these observations help to identify instances when the server redirects its resources to other tasks that are indirectly aecting request processing (e. For example: There are several possible • JVM garbage collection can explain some of the variation in performance of individual requests. The upper outliers demonstrate the extreme scenarios in which the server took an abnormally long time to process requests. Even within the same test results set. the spread of the data does as well. etc). as with any large sampling of data some points will appear to be unreasonably distant from the mean. The reasons for these observations are also discussed later revealing what happens when the load on the server drops. allocation of memory. Discussion of Test Results The box plot diagram in Figure 6. the size of the IQR gives a good indication as to the actual spread of the data. the mean for the initial test case with 100 threads. Furthermore. as it is loaded. These observations are substantiated by the inter-quartile range (IQR) gures.g. The lower outliers likewise provide insight into how the server behaves when it is at its best.3. What is needed is proof that within a single test run 114 .2 compares distributions between the four tests. processing of individual requests within a consistent time frame is also aected producing the high volatility described in the previous section. This is a likely scenario since this service was deployed on a machine with limited RAM and CPU resources. 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). These points are depicted in Figure 6. For example. Other test sets follow a similar pattern as well.2 represents an ever increasing positive skew.

However. This coincidentally.1 and the distribution of Figure 6. less likely to cause problems in a real production environment). which would eventually cause poor performance as the queue backlog increases. Naturally. once these once-o tasks are completed the performance stabilises. as the number of threads grows so do the request processing times. This additional time can be attributed to memory and thread pool allocation and other initialisation procedures. the stability of the server is never impacted. 115 . supports the previous point on increased volatility as evident through the standard deviation trend in Figure 6. making volatility less signicant at the application layer (i.3 are signicantly dierent to the majority of points plotted on the chart.3: SSL Disabled: Average processing time by segments of 1000 requests the payment gateway remains stable.Chapter 6. at the start it is expected that the system would take longer to process requests due to the sudden inux of incoming requests. Clearly. The rst and the last points in each series in Figure 6.2. This means that under a constant load the server is capable of processing requests quickly enough without overlling request queues. the payment gateway behaves in a consistent and stable manner. For example. as the server has to simultaneously handle more requests. for the moment. This variation at those particular points is not surprising and can be easily explained. it is clear that within each series.e. Proving stability of the server under a constant load mitigates the volatility of data at the individual request level.3 depicts average request processing times grouped by 1000 requests. Performance Analysis Figure 6. By excluding the rst and the last point of each line. despite lowering of performance as extra threads are added. A timeline chart in Figure 6.

This can be explained by the decrease in the load on the server as the merchant service completes its payments processing cycle. all merchant requests under this test conguration were processed unauthenticated. Discussion of Test Results Alternatively. on average. 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.2 SSL with Server-Side Certicate Authentication only SSL specication denes the use of server certicates as mandatory and client certicates as optional. validation of payment instructions was disproportionally faster than the overall request processing measurements. This test aims to verify 116 . This is not an issue as it was discovered that. As each request is completed. the remaining requests should be faster since all of payment gateway buers. This means that it is only servers that are required to present their certicates in order to establish SSL sessions with client applications. As such. Since there are no new requests coming in. memory and other resources become available and the load on the machine drops. against expectation.3. The merchant service. validation was adding less than 40 milliseconds to each request while the total request processing time was measured in seconds. The question is. was not required to present its certicate during the SSL handshake. however. the last point in each series is signicantly lower than the others. 6. It is rare to nd use of client certicates in the public domain.1.6. 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. Linear performance degradation with increasing dispersion as the number of threads grows is considered acceptable. This point is further skewed as the number of requests nears parity with the number of concurrent threads. As such. For example. the last bundle of requests will be signicantly quicker. This test conguration aims to mimic the current use of SSL on the Internet. 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 expected that the behaviour of the payment gateway using this conguration should not deviate from the pattern established in the previous section. 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. the payment gateway was congured to use its certicate for establishing SSL sessions with the merchant service.3.

This would be reected by a steeper trend line and higher execution times of each request. the Pearson's Product Moment Correlation Coecient (PMCC) of 0. while the impact on performance is expected.4. The average request processing times for all four tests within this test conguration are plotted in Figure 6. The trend line pro- vides a reasonable. it should still be linearly related to the number of simultaneous connections. visual. is more dicult to predict. per each additional thread.Chapter 6. The equation used to derive the trend line can be used to quantify the impact that additional 117 .4: SSL: Average request processing time that adding the SSL handshake and the encryption of the communication link does not adversely aect this correlation. 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. 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. Due to a more complicated processing life cycle it is possible for the performance to degrade faster. Just like under the previous test conguration. The gradient of the trend line.9877 once again conrms a strong linear correlation between the number of simultaneous connections and the server's performance decay. That is. however. Performance Analysis Figure 6. 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. indication that this correlation is linear.

The equation of the trend line.4. demonstrates that 16 milliseconds are added to the SSL handshake for each addition thread. Discussion of Test Results Figure 6.9879 corroborates these ndings.5: SSL: SSL handshake average processing time simultaneous connections have on the payment gateway server.6. 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. y = 27. In the context of this thesis. 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. y = 16. This value more than doubles the observed measurements from the previous test conguration that recorded 12 milliseconds per additional thread (see Figure 6. The proposed solution is hinged on SSL behaving in a consistent and stable manner without adversely impacting the performance of the payment gateway.37x + 579. This equation. Just like the total mea- surements.7.64x − 354. Removing this gure from the total value of 27 milliseconds leaves only 11 milliseconds remaining.5 presents average times for completing an SSL handshake.1).3. This has the eect of increasing the gradient of the trend line on the graph. 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. The PMCC value of 0. reveals that each additional thread is adding 27 milliseconds to the execution time of each request. which is almost identical to the previous test 118 . Figure 6.

the less volatile the data the easier it is to make reasonable conclusions about the performance of the payment gateway. It is adding over 50% to the processing times per each additional thread. The dispersion of the SSL handshake processing times is of particular importance as it is directly relevant to the solution proposed in this dissertation. examining dispersion of the data in relation to these predictor variables should yield meaningful results.g.1). The results of a multiple regression test comparing the data from the previous section (i.Chapter 6. no authentication) and this one (i. Checking the dispersion of the data to measure volatility can increase condence in the results of this analysis.e. The analysis so far points to a strong relationship between the number of concurrent threads. It is no coincidence that this section focuses on increasing load and SSL authentication as primary variables for analysing variance.e. 2.e. Figure 6. 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. varying either variable has a direct impact on performance of the payment gateway. On the other hand. the authentication method and the number of concurrent threads) are inuencing the criterion variable (i. this is not as signicant as it appears. request execution time).5 seconds for the initial test with 100 threads).2) it is clear that the spread of the data has decreased. This means that during this test run the 119 . 2006). This relationship is best quantied using multiple regression analysis (McClave & Sincich. This indicates that SSL is in fact a major contributor impacting performance as the number concurrent threads grows. server certicate authentication) are presented in Appendix J (see Table J. Performance Analysis conguration result of 12 milliseconds. Considering that the request processing times are measured in seconds (e. The previous section has already conrmed that there is some volatility in the way the payment gateway processes requests.6 plots the distribution of total request processing times on a box plot diagram. adding 16 milliseconds to these times is unlikely to be of signicant concern in a real production environment.e. However. By comparing the IQR of all fours tests against the results of the previous test conguration (see Figure 6. 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. In other words. the authentication method and the performance of the payment gateway. These results conrm that at 99% condence interval both predictor variables (i. That is. increased spread introduces a higher degree of doubt making it more dicult to make concrete conclusions. As such.

This is smaller than before with values ranging from 440 and 1752 milliseconds. 50% of all requests were processed between 2293 (1st quartile) and 2644 (3rd quartile) milliseconds. the server is capable of processing SSL 120 . it is just not as at as it was before. the dierence of only 351 milliseconds. The reduced dispersion of the results is further substantiated by the standard deviation measurements depicted in Figure 6. Standard deviation for non-SSL tests was much higher than what was observed here thus conrming the tighter grouping of data around the mean.3. The dierence between this distribution and the total is marginal with the IQR dierence of only 773 versus 814 milliseconds. the IQR dierence across the four tests was only 814 milliseconds versus 1858 milliseconds obtained during the previous test run. That is. The reduction in dispersion of the data helps to conrm that the payment gateway is capable of handling increased load. This distribution still remains positively skewed. for the initial test with 100 threads. the dierence of 1312 milliseconds. The next step is to check whether the distribution of SSL handshake processing times follow the same pattern. 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. Figure 6.4.7 plots this distribution on a box plot diagram.6: SSL: Distribution of total request processing time payment gateway was more consistent in processing individual requests than before.6. On average. Discussion of Test Results Figure 6. For example. overall dispersion.

and 2. However. the results of these tests can be analysed in the context of: 1. Its ability to process requests within a consistent time frame within each test run (i. Due to the involvement of the SSL handshake.Chapter 6. Furthermore. 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 . within one test run and under increasing load. its stability) is also important. So far. 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. close scrutiny is required to quantify what contribution SSL handshake is making towards the total request processing time. Server's ability to process payment requests sent over an encrypted communication channel.7: SSL: Distribution of SSL handshake processing time handshakes in the same consistent and stable manner as it processes the requests themselves. Performance Analysis Figure 6. Server's ability to establish SSL sessions with the merchant service.e. it has been established that it does have inuence over the server's ability to handle increasing loads. within one test run and under increasing load.

the variation between individual points is less than 100 milliseconds (excluding the rst and the last points as before).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. This diagram proves that SSL is the biggest contributor. By comparing these diagrams it is quite obvious that SSL plays a signicant role in the overall request processing time. Within each series it is clear that the performance of the SSL handshake is stable.3).3. 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. As more resources become unavailable new handshakes have to compete for them with other threads.8: SSL: Average processing time by segments of 1000 requests A timeline chart in Figure 6. The variation from point to point is relatively low. the behaviour of the payment gateway is stable as it is capable of processing requests within a consistent time frame. increasing the number of concurrent threads leads to performance degradation.10 attempts to quantify this contribution by plotting the times spent establishing SSL contexts as a percentage of the total request processing time. Isolating the SSL handshake process from the above diagram reveals the same consistent behaviour (see Figure 6. As before. for the initial test with 100 threads. Discussion of Test Results Figure 6. For example. with 70 to 90 percent of the total time spent on SSL 122 . It proves that for a single test run.9).6. Figure 6. Other tests follow the same trend proving that any volatility in the data described previously is manageable.

However. This means that there is something else beside SSL that is impacting on the server's performance. however. Volatility of the server remains the 123 . linear decay in performance with stable and consistent processing times under a constant load. One likely candidate is the Axis2 web services engine.Chapter 6. Mutual authentication is the basis of the periodical payment framework without which the entire solution does not work.9: SSL: Average SSL handshake by segments of 1000 requests handshake. Proving that adding client certicate authentication does not adversely aect the performance of the payment gateway server is paramount. That is. 6. However. some impact on performance is to be expected due to the increased workload of exchanging and validating client certicates. analysing Axis2 framework to accurately determine its contribution is outside of the scope of this thesis. Performance Analysis Figure 6. some of the responsibility can be attributed to the lack of physical resources (e. Clearly. RAM). notice what eect increasing the number of simultaneous connections has on SSL's contribution to the total time.1. At this stage. It is the biggest and the most complicated component of the periodical payment framework and so far has been treated as a black box. Instead of remaining at the same level or rising it is actually falling as the server is overloaded.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. it is expected that the behaviour of the system will continue to follow the established trend.g. Alternatively.3. it is less likely to be the root cause in this case.

124 . a merchant service used pre-generated proxy certicates to authenticate itself to the payment gateway web service. the  {0} placeholder was dynamically replaced with a value during certicate creation). Discussion of Test Results Figure 6. the value of the amount attribute is also unique to ensure that policies are not cached (i.10: SSL: SSL handshake percentage of total time only unpredictable factor. however. due to thread synchronisation issues) is immediately detectable. This policy is approximately 500 bytes long depending on the value of the amount attribute. This feature assures the correctness of the data collected from these tests. 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. This was done to ensure that tests can be re-run without requiring changes to the proxy certicates used for authentication.g. The contents of the payment policy used within each proxy certicate are depicted in Figure 6. 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. Also.11.e.3. Just like the distinguished name (DN) of the proxy certicate. For this test. because each policy is dierent any attempt by the merchant service to reuse a certicate (e.6.

which is conrmed by Pearson's Product Moment Correlation Coecient (PMCC) of 0. equation used to derive this trend line.OU=ITEE. The only change between this test scenario and the previous one was the introduction of mutual authentication. it is obvious that the rate with which the performance degrades. The trend line provides a visual indication of linear correlation.9. Based on these ndings.9895.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. That" xsi:schemaLocation="policy.O=UNSW.OU=ITEE.xsd" merchant-dn=CN=Merchant. it is conrmed that impact on performance remains linear rather than becoming exponential when using mutual authentication.adfa.e. reveals the extent to which this slope diers from the others. For example. authentication of the proxy certicate) will escalate the  rate of increase as the number of threads grows. 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. By examining the slope of the trend line. The y = 87. as the number of threads increases is higher than what it was" xmlns:xsi="http://www. This time each additional thread adds approximately 87 milliseconds to individual request processing times where is before it was only 27 milliseconds.0" encoding="UTF-8"?> <payment-policy xmlns="policy. This execution time dierence is signicant.unsw.w3. These expectations are conrmed in Figure 6. however.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. it can be expected that the impact on performance of the payment gateway will continue to exhibit increasing linear behaviour.C=AU Performance Analysis <?xml version="1.12. It is also likely that adding a new step to the SSL handshake (i.78x−3561. Unless it can be established that SSL with mutual authentication does not 125 .Chapter 6.O=UNSW.

13 plots the trend line of the SSL mutual authentication handshake. Figure 6. 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. The trend line slope is much atter than in Figure 6. such as the Axis2 web service engine as the likely culprit. 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. which reveals that SSL processing times are rising by a mere 10 milliseconds per additional thread leaving 77 milliseconds unaccounted. Discussion of Test Results Figure 6.12 which can further be substantiated using its equation. Volatility of Test Results Discussion on linear correlation has highlighted the importance of analysing distribution of test results. In fact. SSL is the more stable component of the application leaving unrelated components. This means that SSL is not contributing as much to the general decline in performance as Figure 6. That is.6.12 suggests. the authentication method 126 . questions may have to be raised as to its suitability as a solution.12: SSL (Mutual): Average request processing time cause this decline in performance.745x + 3407.4. 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. 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.3. y = 10.

14 plots the distribution of total request processing times on a box plot diagram. Figure 6. For example. Performance Analysis Figure 6. Appendix J presents the results of a multiple regression test performing this comparison (see Table J. it is reasonable to assume that each variable will contribute to the dispersion of the data analysed in this section. There is a substantial number of requests that were processed much slower than the majority of other requests within this result set. it is possible to establish with 99% condence interval that both predictor variables are aecting the processing time of requests.13: SSL (Mutual): SSL handshake average processing time used to gain access to the payment service and the performance of each request. 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 results of all four tests reveal an elevated dispersion with an average IQR dierence of 1562 milliseconds.2). for the last test with 160 threads some outliers took over 30 seconds to process while the mean was only 10. When these gures were subsequently used for evaluating the 127 . As such. 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). baseline test whose IQR value was 1858 milliseconds. Such high processing times adversely aect the averages. A similar analysis comparing server certicate versus mutual authentication likewise conrms previous ndings. As before. which are used to calculate the trend line. This is higher than the previous test conguration with IQR of 814 milliseconds but it is still not as high as the original.Chapter 6.5 seconds.

especially within the 75th percentile.15 plots the SSL handshake distribution on a box plot diagram. Due to such high volatility. etc). it is important to check how the SSL handshake behaves under these conditions. clearly demonstrates how close its distribution follows the totals in the previous diagram. this is most likely caused by the physical limitations of the test hardware used.14: SSL (Mutual): Distribution of total request processing time rate with which performance decays the resulting slope was aected appearing much steeper than anticipated. The important consideration is 128 . As was mentioned previously.3. The number of outliers. The IQR values are also very similar with an average IQR of 1139 milliseconds matching closely the totals IQR average of 1562 milliseconds. especially within the later test runs.g.6. 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. multi-core CPUs. larget RAM. Discussion of Test Results Figure 6. Clearly. cluster servers. This means that the payment gateway server is equally inconsistent in processing SSL handshakes as it is in processing payment requests. In practical terms. Figure 6. however. this is unlikely to be of signicant importance in a real production environment as this can be mitigated using better hardware (e. This analysis is crucial as it suggests that increasing simultaneous connections with mutual authentication leads to higher volatility.

Conrm the server's ability to handle constant load in a stable and consistent manner. the focus of this section has been on the server's behaviour under increasing load. in principle. The additional step that is required should not.15: SSL (Mutual): Distribution of SSL handshake processing time the server's ability to handle majority of requests consistently. Quantify the contribution that SSL handshake is making to the total request processing time. It is expected that the actual measurements will be elevated but the trend should be comparable. 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. Ideally. Performance Analysis Figure 6. So far. which revealed some unusual departure from the established trend. The aim of analysis in this section is to: 1. the behaviour of the payment gateway under this test conguration should match results obtained from the previous test. and 2. 129 . aect the server's ability to process requests under a constant load.Chapter 6.

This proves that in relation to mutual authentication.16 depicts request processing times grouped by 1000 requests.17 plots the SSL handshake processing times grouped by 1000 requests. A timeline chart in Figure 6.9 to 10. This matches the results of the previous test scenario as The dierence is the amount of time that it takes to process each request. 130 . for these tests this range is wider starting from 4.16: SSL (Mutual): Average processing time by segments of 1000 requests A timeline chart in Figure 6.5 seconds or less.6. It is a crucial component of the application whose performance will dictate whether this solution is viable. demonstrated in Figure 6. With such relatively high processing times it is important to measure the performance of the SSL handshake. Unlike the previous measurements of 2. Not only that but they stay relatively close to each other as well regardless of the increases in the number of simultaneous connections. the dierence in processing times for 100 versus 160 threads for any give point is approximately 0. For example. Discussion of Test Results Figure 6. it is clear that all four test series remain consistent throughout their entire test runs. the payment gateway is capable of handling both constant and increasing loads without losing eciency over time.3.5 to 4. It conrms that within a single test run the payment gateway server is capable of processing requests without losing its eciency over time.8 seconds. This gure diminishes the less threads are used.5 seconds. 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.8. Ignoring the rst and last points for reasons already discussed.

That is. As such. This is the crucial dierence between this test and the previous one which showed much smaller gap between the two processes.17: SSL (Mutual): Average SSL handshake by segments of 1000 requests The times dedicated to SSL handshake. while for 100 concurrent threads. Performance Analysis Figure 6. This diagram reveals that as the number of concurrent threads grows the eect of the SSL handshake diminishes. According to Figure 6. taking approximately 4. As before.5 seconds to execute. 131 .Chapter 6.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. This will be analysed further in the next section when the results of all three test congurations will be compared. 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.18 quanties the contribution made by the SSL handshake towards the total request processing time measured as a percentage of the total time. are signicantly lower than what is spent overall on processing requests. plotting the dierence between these activities can help identify the reasons for this discrepancy. it is reasonable to assume that something else is contributing to this dierence (e.17 the SSL handshake is stable regardless of the number of threads used.3.g. Figure 6. this number drops to around 50% for 160 concurrent threads. 6. however. Axis2 engine). on average 80% was spent performing the SSL handshake.

the only analysis that has been presented used multiple regression to establish the relationship between the number of concurrent threads accessing the payment gateway. it is clear that the last test representing mutual authentication with proxy certicates adds a substantial overhead as compared to the other two. These initial results must be validated here if this solution is to be considered viable. The payment gateway takes approximately twice as long to execute requests that use proxy certicates for authentication than the ones with only server certicates.19 depicts a bar chart plotting the average request processing times for all three test congurations. Discussion of Test Results Figure 6. the authentication method and the server's performance (see Appendix J). the aim of this analysis is to conrm whether using mutual authentication with proxy certicates is a viable solution for the periodical payment problem.6. the behaviour demonstrated in Figure 6. When compared like this. In this diagram. Figure 6. 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. In 132 .18: SSL (Mutual): SSL handshake percentage of total time Specically. The next diagram in Figure 6.19 which showed a distinct doubling in processing times.3. the dierence between It does not reect the mutual and the standard SSL handshake processing times are much closer.20 isolates just the SSL handshake measurements from the total request processing times and plots them on a bar chart. So far.

8 seconds for 160 concurrent threads.19 are contributed by other elements within the system unrelated to SSL. For example. the number of outliers is signicantly higher than for non-mutual SSL. While the dispersion of the data within the IQR for the mutual authentication tests is comparable with the baseline tests (1562 versus 1858 milliseconds). This diagram once again conrms that the tests using mutual authentication take longer to process individual requests.Chapter 6. Performance Analysis Figure 6. This indicates that regardless of the load on the server. As such. This number drops to 1. for the initial test case with 100 concurrent threads the dierence between the two congurations is 2. For example. the performance of the SSL handshake remains stable.21 plots all of the request processing times for each test on a box plot diagram. In actual fact.2 seconds.19: Average request processing time this diagram the dierence is more manageable which does not rise with the number of concurrent threads. For example. Figure 6. 133 . 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. it can be concluded that the extreme measurements depicted in Figure 6. This causes the average for the entire set to rise thus making the server appear slower. To consolidate these ndings the distribution of each test result set can be compared. each one taking up to three times as long to execute. the dierence between the two test congurations decreases as the number of simultaneous connections grows. it is the performance of requests within the 75th percentile and the number of outliers that makes the biggest dierence.

This proves that the SSL component is behaving consistently with volatility rising slowly as the number of concurrent threads grows. The high number of outliers for mutual SSL is still a problem causing elevated mean values within this test conguration. in the context of this dissertation. Discussion of Test Results Figure 6. 134 . This diagram shows a much smaller gap between both the averages and the dispersion of the data. 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. isolating the components of the Axis2 engine that is causing issues is left as an exercise for the future. To that end. However. 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. However. Figure 6. 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. it is logical to attribute some of this performance decay to its internal processes Due to the limited scope of this thesis. both distributions follow a similar pattern with average IQR dierences being much smaller than in Figure 6.22 plots the distribution of SSL handshakes for both test congurations that used SSL on a box plot diagram. As this component provides all of the boiler-plate code required to implement a standards compliant web services stack.3.1 seconds for mutual SSL versus 773 milliseconds).6.21 (1.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.

22: Distribution of SSL handshake processing time 135 .21: Distribution of total request processing time Figure 6.Chapter 6. Performance Analysis Figure 6.

However. 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. despite the high volatility. 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. 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. For example. the SSL component of the application has consistently performed as per expectations. SSL is implemented in hardware. 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.4. in many commercial applications. Introducing mutual authentication has aggravated this situation causing higher than anticipated increases in processing times. production environment. Also. Some issues were discovered with the choice of the web services engine used. It conrmed that the payment gateway is capable of handling both constant and increasing loads without losing eciency. which contributed to a higher than normal dispersion causing increased volatility in behaviour of the payment gateway. 136 . This enterprise strength implementation is likely to improve performance of SSL handshake processing. Alternatively.6. As such. The performance impact that was directly contributed by SSL is manageable and unlikely to cause problems in a realistic. These SSL hardware accelerators are specically designed for improved performance in environments that rely heavily on SSL authentication. That is. 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. Dierences of fewer than two seconds between standard and mutual SSL are insignicant considering the various options that are still available.

This problem exists in the current electronic commerce environment and is not being suciently addressed within the industry despite its popularity. In this thesis. most have failed despite industry interest and support (e. This. this dissertation makes the following contributions to the eld of electronic payments within an e-commerce environment: 137 . A unique solution was implemented using minor extensions to existing technologies that can be seamlessly integrated with the existing nancial infrastructure. 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. 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. The theoretical model presented here was also implemented as a demonstration of its viability. either academic or commercial. standards compliant and industry supported technologies. As such. rst of its kind. No other payment framework so far.g. The payment systems of the past relied on sophisticated. SET). In this dissertation a dierent approach was taken. 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.Chapter 7 Conclusion This dissertation makes a signicant and original contribution in the area of electronic commerce. commercial environment. The working prototype backed up by extensive load testing. custom architectures that required complete infrastructural changes to be useful. It presented a unique solution to the problem of periodical payments. followed by a comprehensive performance analysis oer plenty of reasons for optimism in the future of this approach. To summarise.

followed by future work and nal remarks.1 Periodical Payment Framework The periodical payment framework consists of a series of protocols that denes the communication standards between all participants. 138 . Each proxy certicate carries a periodical payment policy document that encodes the conditions for each payment within a specied time period. • Design of a proxy certicate cancellation protocol that allows customers (for the rst time) to automatically cancel payment agreements without merchant intervention. as is the case now. At the core of this framework are the X. • Design and implementation of a proxy certicate exchange protocol that allows merchants to obtain delegated credentials from customers via HTTP. J2EE for merchant server implementation and acquirer payment gateway web services interface accessible via HTTPS (using X. • 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.7.1.509 restricted proxy certicates that provide the necessary authentication and authorisation tokens for securely processing periodical payment transactions. The following are the four most important contributions made by this framework.509 restricted proxy certicates in order to solve payment credential delegation problem from customers to merchants.1.509 restricted proxy certicates for authentication).1 Contribution 7. This approach is unique as it delivers ne-grained control of delegated payment credentials that goes beyond the current direct debit model. 7. 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. • A complete. The next section will briey describe each of the above contributions highlighting their signicance. Contribution • Application of X. end-to-end framework implementation using Mozilla Firefox extension architecture to develop customer-side user interface.

2 Payment Processing Protocol One of the reasons that X. 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. This approach works well in closed environments where all users are expected to understand this technology and be familiar with how it works. this step is added to the customers shopping experience. 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. Whenever proxy certicate requests are used. 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. it is possible to introduce this technology to the general Internet community without necessarily going through the process of educating users about PKI. Most will simply not understand the concepts and be unwilling to adopt this technology. However. However. they are usually manually downloaded as base64 encoded text and imported into standalone applications that decode them and allow users to issue proxy certicates. 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. In addition. instead of making it a standalone process that is outside of the shopping workow.g. Conclusion 7. Unfortunately.1.509 certicates. Systems that are currently using this technology (e.1 Proxy Certicate Exchange Protocols A protocol for obtaining proxy certicates from remote users simply does not exist.509 proxy certicates are an attractive option for implementing delegation is because they can be used with existing software built to handle standard X. 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. this requires the payment gateway to maintain state information regarding past transactions. the amount of state stored is manageable as only the last transaction is of interest with all older transactions discarded.1.Chapter 7.1. 7. Globus Grid) rely on users to manually issue proxy certicates to recipients of their choosing. it is unrealistic to expect regular Internet consumers to go through the same process. This 139 . The idea is. By keeping the user interface simple and intuitive with unnecessary certicate content hidden. this dissertation proposed an original approach to solving the classic double charging problem.1. The payment protocol presented in this thesis used this to its advantage to greatly simplify the payment process.

1. they are either not used.509 proxy certicates with payment policies makes the process of cancelling payment agreements simple. This dissertation presented a payment cancellation protocol that allows customers to independently request termination of contracts directly from the payment gateway. sign and fax/mail them separately. 7. Most importantly.1.509 proxy certicates in combination with payment policies enabled the creation of all of the sophisticated protocols described in this thesis. they cannot manipulate this process to their advantage once the policies have been signed. the payment cancellation protocol. The control over Usually. 7.4 Periodical Payment Policy Language Direct debit forms of the present are simply incapable of supporting payments within an electronic commerce environment. 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. Closing accounts linked to direct debits is also dicult often leaving customers with little recourse during disputes. or require customers to download. In either case these approaches are insecure and highly inexible. However. it made it possible for each payment transaction 140 .7.1. While payment cancellation is not the most challenging or the most sophisticated part of this dissertation. it is nevertheless one of the most important. Merchants can still control this process by specifying the rules under which contracts can be terminated inside payment policies. The use of X. as in the case of credit cards. a lot of merchants make it dicult for customers to cancel agreements often requiring multiple telephone calls to accomplish this seemingly simple task. As such. for example. 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.1. In this thesis.3 Proxy Certicate Cancellation Protocol The fact is that cancelling direct debits once they are established is dicult. As such. an ability to easily cancel contracts is a feature that has long been desired by consumers.1. There are no electronic standards that dictate how direct debit agreements should be formulated online. it is not in their best interest to allow customers to terminate contracts before they expire due to the loss of potential income. Beside security. Contribution approach ensures that payment gateways are not needlessly burdened with maintaining complex state information keeping this part of the framework relatively simple. Using X. this process rests in the hands of the merchants.

7.e. this dissertation presented a concrete implementation of each component of its architecture. Using a variety of examples. 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. most (if not all) modern browsers are capable of supporting third-party extensions via plug-in interfaces.1. the consumer browser application.2. extensible architecture. The X. Conclusion to be instantly and automatically validated against its policy making it impossible for merchants to overcharge customers. 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 . the merchant electronic commerce application. This prototype shows that it is indeed possible to integrate X.509 proxy certicates across all three tiers. This was extremely important as this dissertation placed high value on policy signatures. 7. this dissertation demonstrated how this language could be used to encode conditions into periodical payment contracts. and the payment gateway web services application. by using this prototype it was also possible to demonstrate what impact strong authentication and encryption has on payment processing. Furthermore. Furthermore.1. the success achieved with the Firefox extension in this dissertation is possible to replicate with other browsers as well.2 Periodical Payment Framework Implementation To demonstrate that the periodical payment framework can work in practice and to measure its performance. i. 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. although the eort required might be greater.509 Proxy Certicate Signing Tool achieves two important goals of this thesis: 1. because the syntax was relatively non-verbose transforming it into a human-readable form was also not an issue. As such. 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. However.Chapter 7. 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.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. The syntax of the periodical payment policy language is simple yet expressive.

In addition. 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 achievement as it shows that digital signatures can be meaningfully applied to electronic content by demonstrating that customers will understand the documents they sign. convert the request into a signed proxy certicate). The implementation of a prototype merchant application established that this is possible and would require only minimal disruption during integration into an operational environment. This is a signicant example as it suggests that this technology could be applied to current applications eciently and cost eectively. issues with SSL session caching were also solved. signicant discoveries were also made regarding how to integrate X. Problems with the existing Sun JSSE provider implementation were identied that lead to development of a custom extension to the SSL key manager. Even though some changes to standard technologies were necessary.2.1. the major goal of this thesis was to investigate ways of integrating periodical payments into existing applications.1.509 proxy certicate authentication into J2EE merchant applications. This extension allows merchants to choose certicates during the SSL handshake based on periodical payment instructions rather than using a generic certicate selection algorithm. this simple prototype has demonstrated the ease with which policies can be transformed into a format accessible to general Internet users. Considering that merchants already have operational payment solutions. the periodical payment framework had to t neatly into the existing. Contribution when a proxy certicate request is detected within a HTTP response header. 2. allowing a single. 7. Using simple JavaScript DOM functions. overcrowded electronic commerce environment.7.e. multi-threaded application to establish SSL sessions with the same remote host using dierent proxy certicates.2 Merchant Electronic Commerce Application This dissertation had to deal with the issue that unlike most new technologies. 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. 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. While more work is still needed to improve the user experience. As a result of this development eort. those changes are isolated to a specic component of the technology stack and can be integrated into existing ap- 142 . These solutions made the end-to-end integration of all three tiers of the periodical payment framework possible.

Web services technology delivers loose coupling between communication participants while enhancing interoperability via a generic service denition language (i. issues with the default Sun JSSE trust manager implementation were discovered that prevented the payment gateway from validating X.2. Conclusion plications declaratively. However.e.509 proxy certicates. Designed to be accessible by multiple merchant applications simultaneously. that introducing mutual authentication using proxy certicates does have an adverse impact on its performance.Chapter 7. In this thesis. 143 . the payment gateway can become a bottleneck unless it can eciently process incoming payment transactions. This analysis demonstrated that both under constant and increasing loads the behaviour of the server remained consistent and stable. While this dissertation used the standard Sun JSSE provider implementation. During development. this dissertation proved linear correlation between the number of simultaneous connections to the payment gateway and its performance. Just like the custom key manager of the merchant. a prototype payment gateway was implemented using Apache Axis2 web services engine. which would not have been the case if the performance degraded exponentially rather than linearly. Most importantly. 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.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. It then takes over the responsibility of validating proxy certicates. Furthermore. WSDL). 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. this thesis presented a comprehensive It demonstrated analysis of its performance providing evidence to support the proposed solution. Even though there was a dierence of approximately 2 seconds between the standard and the mutual authentication. there are other much faster implementations that would reduce SSL handshakes to production acceptable performance times. a custom extension to the default trust manager was subsequently proposed. the new trust manager can be declaratively congured into an existing application. As such. this dierence is manageable. 7. the impact of the SSL handshake and encryption was isolated from the overall request processing measurements. during the performance analysis.1. Considering that this is the most important part of the framework. This nding is signicant as it conrms that such performance issues are manageable with better hardware. which is quite slow.

Future Work Overall. open source SSL library. the issue of performance is best addressed by evaluating alternative web service implementations. it is possible to simplify this part of the periodical payment framework improving performance while reducing complexity. This is unlikely to change in the near future. At present. 7. 144 . The best option for truly testing SSL in a production-like environment would be to congure an SSL hardware accelerator. the aim of future work should be to compare the Apache Axis2 engine to other frameworks oering the same features.2 Future Work This dissertation placed heavy emphasis on web services because currently this technology is leading the way for interoperability between disparate applications. Some performance improvements are also needed for the SSL handshake. This is a pure Java implementation of SSL and its performance is not ideal. It is quite likely that by switching to another web services provider performance gains can be achieved without any code changes. Alternatively. into Apache Tomcat using its Apache Portable Runtime (APR) mechanism. such as overhead justify their use? representational state transfer (REST) architectural style. the entire concept of using web services within the electronic commerce context can also be examined. Apache Tomcat servlet container running the payment gateway application is congured using Sun JSSE provider implementation. All identied performance issues were mostly caused by the lack of hardware resources rather than any underlying problems with the architecture.7. do their extensive performance By taking a dierent approach to web service implementation. 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. Testing the periodical payment framework with a hardware accelerator would provide the most convincing measurements of how it will behave in an operational environment. One such approach is to congure OpenSSL. While web services deliver interoperability. There are various options available to make this part of the framework much faster than what it is now. the prototype acquirer payment gateway performed well under both constant and increasing loads. By integrating an alternative library developed using a native API it is possible to dramatically decrease the time taken by the SSL handshake. Focusing primarily on performance. It demonstrated that using mutual authentication with proxy certicates is a viable approach that can work in a realistic production environment. commonly used by organisations with high Internet trac that rely on SSL for authentication. As such.2.

509 certicates (see Heary. This. This is sucient for testing but would hardly be acceptable in a nal product. the issue of customer credential storage must be eventually addressed. As was briey mentioned in Chapter 4 proxy certicates may sometimes expire before periodical payment contracts for which they have been issued. As such. some improvements are still needed to the framework itself. At the moment. 145 . some investigation is required to test its suitability within a periodical payment context. While smartcard technology has been around for many years. Alternative technologies exist right now that make smartcard use a reality. In the past credential storage was an insurmountable issue. X. In the future. Another potentially promising technology that requires further research is using Subscriber Identity Module (SIM) cards commonly found in mobile phones as cryptographic tokens. One such technology is USB tokens. This technology can be easily adopted for use within the periodical payment framework. This is clearly an issue that must be addressed before the various stakeholders in this eld seriously consider this solution. even most modern computers now are not equipped with smartcard readers needed to make this technology available for general Internet use. 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. that is immediately available. however. relatively old computers running older operating systems will support this standard. Conclusion Improvements are also needed to the consumer platform. A USB token combines both the smartcard and a smartcard reader in a single device. SIM cards are essentially smartcards that are capable of storing customer cryptographic credentials. However. is no longer a problem.Chapter 7. For example. 2008). there are commercial products available on the market right now that make client certicate management easier. It uses an out-of-band channel.509 Proxy Certicate Signing Tool extension is loading a customer's keystore from a le located in a Firefox accessible directory. end-to-end implementation of the periodical payment framework. such as mobile phone short message service (SMS) for authenticating users before issuing them certicates. as a short-term solution. it cannot be ignored. 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. In the mean time. Finally. USB tokens should be integrated into the Firefox extension presented in this thesis thus providing complete. the process of renewing proxy certicates once they have been issued to merchants is an area that must be addressed in the near future. As such. This would not be an ideal solution. 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. While it was out-of-scope for this thesis. SecureAuth for Cisco VPN product provides a user selfservice interface for creating X.

7. remain one eld that has not beneted from this work. For example. For example. Periodical payments ll the security and usability gap that the present direct debit model is incapable of doing due to its paper driven design. The periodical payment framework can be extended to include a renewal service similar to MyProxy presented by Kouril (2005). a proxy certicate) from the payment gateway using the signed policy as proof that the customer agreed to the contract.e. o-line and on the Internet. demonstrate that this topic is still relevant in the current electronic commerce environment. Unfortunately.3. this issue has already been tackled by the Globus team responsible for the grid security architecture discussed in Chapter 2. This framework resolves issues of past implementations by leveraging of the currently available.3 Final Remarks Digital payments within electronic commerce is an area that has seen a great deal of research and development over many years. The growing popularity of this type of payment. 146 . standards compliant and industry-supported technologies. a service like MyProxy makes the use of authentication tokens (e. such as Visa and MasterCard are not directly addressing this particular payment format either. Final Remarks Fortunately. smartcards) dicult. 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. MyProxy exposes a publicly accessible service that uses customer private keys to renew proxy certicates. Neither can the existing solutions oer value due to their fundamental focus that place anonymity and non-relinquishing of control as priority. Using this approach will ensure that life spans of proxy certicates can be eciently managed. however. current attempts rely At on customers' physical presence during payment transactions thus precluding even the possibility of delegation. the same time it does not compromise on either security or performance. 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. The merchant would obtain a signed copy of a payment policy from a customer and then request an authentication token (i. It is clear that existing approaches to electronic commerce by industry leaders. proxy certicates can be obtained from the payment gateway rather than from the customers. The periodical payment framework presented in this dissertation delivers a solution to an existing problem aecting users of the direct debit payment model.g. To make use of smartcards an alternative approach is needed. In fact. Periodical payment framework represents an important change in direction for electronic commerce payments.7. Periodical payments.

can be used to replace the traditional direct debit request (DDR) forms. 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. Most importantly. is a viable solution to this problem. In addition. While using SSL with mutual authentication does impact performance.Chapter 7. this dissertation has validated the choice of X. it is now possible. While it is dicult to predict the future of payment technologies. it was demonstrated that this increase is insignicant when measured against the benets that it provides. 147 .509 restricted proxy certicates. The strong demand for periodical payments with growing consumer awareness of security issues will most denitely drive its development in the future.509 restricted proxy certicates for authentication and authorisation. digital signatures it is possible to place same signicance on signed payment policies as on the current DDR forms. This eectively eliminates the current problems of overcharging. having digitised merchant-customer contracts. it is almost guaranteed that at least some of the ideas presented in this thesis will eventually be introduced into current payment solutions. built using web services and secured by SSL with X. Furthermore. to verify the legitimacy of each payment transaction before processing. it was demonstrated how payment policies can be tailored to support periodical payment cancellation. Conclusion This thesis demonstrated that a periodical payment framework. for the rst time. It was demonstrated how these certicates in combination with Using payment policies.

7. Final Remarks 148 .3.

apache. The verication of an industrial payment protocol: the set purchase phase. CA. URL http://hc. Herreweghen.. Australian Payments Clearing Association. & Waidner.Bibliography Bellare. M. C. In WOEC'96: Proceedings of the 2nd conference on Proceedings of the Second USENIX Workshop on Electronic Commerce . Tsudik. (2000).. 611627. (2002). F. & Kuhn. Berkeley. USA: USENIX Association. USA: ACM. (pp. and deployment of the ikp secure electronic payment system. M... & Massacci. & Kuhn. H. New York. NY. IEEE Journal on Selected Areas in Communications . Sydney. G. L. 18 . rep. M.. Australia. A. 149 . USA: USENIX Association. L.. A growing role to meet members' needs. G. R. & Massacci. (pp. Tamper resistance: a cautionary note. E. V. Hauser.. IEEE Journal on Selected Areas in Communications . London. In CCS '02: Proceedings of the 9th ACM conference on Computer and communications security . (1996). CA.. J. 77).. (1998).. Bellare. Tech. In Proceedings of the 5th International Workshop on Security Protocols . implementation.. J. Design. 7787. M. Steiner. R.. Bella. Jakarta commons httpclient. Herzberg. Krawczyk.. Anderson. A.. Verifying the set registration protocols. G. Hauser. Tsudik... (2003). G. ikp: a family of secure electronic payment protocols. Krawczyk. C. In WOEC'95: Proceedings of the 1st conference on USENIX Workshop on Electronic Commerce . & Waidner. UK: SpringerVerlag. 1220). M. G.. 21 . M. M. Paulson. J. Garay. J.. Low cost attacks on tamper resistant devices. (1995). Paulson. Herzberg. 125136). (pp. H.. Berkeley. F. 11).. Bella. Apache (2008). (pp. R. Steiner... A. A. G. Garay. R. M.x/ APCA (2005).

and digital pseudonyms. Fiat. L. USA: Springer-Verlag New York. URL http://www. Blind signatures for untraceable payments. F. In WOEC'95: Proceedings of the 1st conference on USENIX Workshop on Electronic Commerce . D. Camp. (1993). In CRYPTO '93: Proceedings of the 13th annual international cryptology conference on Advances in cryptology . J. (1981). In AFIPS National Computer Conference . Chaum. (1988). 8490. 28 (10). R. Chaum. 319327). (1994). An ecient o-line electronic cash system based on the representation problem. rep. 10301044. & Pedersen. Improved privacy in wallets with observers. Secaucus. 11). In D. & A. T. DC. Inc. Safeguarding cryptographic keys. Inc. NY. 6484). G. In CRYPTO '88: 8th Annual International Cryptology Conference . Untraceable o-line cash in wallet with observers. Chaum. The legion of the bouncy castle.. ( Brands. 24 (2). Brands. 302318).) Advances in Cryptology Proceedings of Crypto 82 . (1995). Scientic American . Security without identication: transaction systems to make big brother obsolete. L. 89105). USA: USENIX Association. Cramer. In EURO- CRYPT '93: Workshop on the theory and application of cryptographic techniques on Advances in cryptology . 150 . (pp.bouncycastle. (pp. R. (1983). & Pedersen. Sherman (Eds. (1995). S. Rivest..BIBLIOGRAPHY Blakley. S. T. D. USA: Springer-Verlag New York. R. D. D. CA. S. (pp. A. (1985). Untraceable electronic cash.. USA: IEEE Computer Society. (1994). L. Chaum. Tech. (pp. D. NJ. New York. Token and notational money in electronic commerce. Wallet databases with observers. & Tygar. Chaum.. 96101). return addresses. (1992). Chaum. Untraceable electronic mail. J. UK: Springer-Verlag. Com- munications of the ACM . & Naor. In CRYPTO '92: Proceedings of the 12th Annual International Cryptology Conference on Advances in Cryptology . Electronic cash on the internet. D. 329343). Chaum. Achieving electronic privacy. D. BouncyCastle (2009).. (1979). Berkeley. Communications of the ACM . J. P. (pp. P. M. M.. (pp. Brands. L. 199203). In SNDSS '95: Proceedings of the 1995 Symposium on Network and Distributed System Security (SNDSS'95) . Washington. (1993). Sirbu. London. (pp.

org/rfc/rfc2617. 307315). Electronic wallet. G. P. (pp.ietf.ics. thesis. IRVINE. Hostetler. UK: Springer-Verlag. Sepa core direct debit scheme rulebook v3.europeanpaymentscouncil. infrastructure. Proceedings of the 13th Annual International Cryptology Conference on Advances in Cryptology .uci. Proceedings of the thirtieth Australasian conference on Computer science . 292301). Http authentication: Basic and digest access authentication. Desmedt. 457469). J.. 383386).cfm?documents_ id=302 Even. J. (1999). Inc. In CRYPTO '89: Proceedings on Advances in cryptology . URL http://www. C. (2000). Hallam-Baker. (1989).org/rfc/rfc2246. (1999). (pp. In CRYPTO '93: Ferguson. (1994).txt Periodical payment model using restricted proxy certicates.. EPC (2009). Ph.0.. Tech. 131139). UK: Springer-Verlag. Extensions of single-term coins. & Stewart. G. & Schneier. (pp. In ACSC '07: Goldman. & Frankel. In CRYPTO '91: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology . In CRYPTO '83: Proceedings on Advances in Cryptology . GPayments Pty Ltd. Veried by visa overview: The 3-d secure authentication standard. USA: Springer-Verlag New York... Y. N. Y. Darlinghurst. URL http://www. URL http://www. (2007). Leach. Ferguson. (1992). S. rep. Inc.htm Franks. & Goldreich. Y. P. Shared generation of authenticators and signatures (extended abstract). & Allen.. T. GPayments (2002a). Fielding. & Frankel. Australia: Australian Computer Single term o-line coins.BIBLIOGRAPHY Desmedt. UNIVERSITY OF CALIFORNIA.. (1983). (pp. B.D. L. Computer Security Journal . Springer-Verlag. A. The tls protocol version 1. Lawrence. London. Y. O.. (2000). Architectural Styles and the Design of Network-based Software Architectures . NY.ietf. S.4..txt Ten risks of pki: What you're not being told about public key Ellison. Dierks.. (pp. Australia. 17. R. Luotonen. URL (pp. C. N. (1993). London. T.. Threshold cryptosystems. G. 151 .. 16 . New York. 318328).

M. & M'Raïhi.... UK: Springer-Verlag. (2002). A credential renewal service for long-running jobs.networkworld. A. (1996). (1994).. A. GPayments Pty Ltd... R. (pp. A. Low. In GRID '05: Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing . IEEE Computer Society Press. mastercard spa: A comparison of online authentication standards.BIBLIOGRAPHY GPayments (2002b).. (pp. N. London. Neuman. Pki seeks a trusting relationship. (1996). T. In Proceedings of the Virtual Banking Conference .txt Jakobsson. Revokable and versatile electronic money (extended abstract). 157173). Internet Housley. Jakobsson. 7687). (1999).. (2008). (pp. Polk. IEEE/ACM Trans. D. F. Y. C. H. W. Kouril. Anonymous credit cards and their collusion analysis. (2005). M. Kristol. URL http://www. P.. 152 . E. J. S. D. (2001). D. DC. rep. D. M. N. & Yung. Trust management for e-commerce. 4 (6). In SAC '98: Proceedings of the Selected Areas in Cryptography . & Povey. G. S. (1994).509 public key infrastructure certicate and certicate revocation list (crl) prole. B. & Cheung. Web security: The emperors new armour.. USA: IEEE Computer Society.. I. rep. & Solo. M.. D. Ford.. & Tran. & Ts'o. 191 205). NY. Visa 3-d secure vs. The evolution of the kerberos authentication service.client certicates oer a superior defense over otp devices. Josang.. F.. 6368). Sslvpn vulnerabilities . W. Tech. Pedersen. USA: ACM. S. In ACISP '00: Proceedings of the 5th Australasian Conference on Information Security and Privacy . London. Josang.. Heary. Tech. Washington. M.. D. Anonymous internet mercantile protocol. AT&T Bell Laboratories. Kohl. URL http://www. (2000). UK: Springer-Verlag.ietf. J. Low. Mllerud.. 7894). (2000). & Paul. New York. Josang. T. Mix-based electronic payments. Netw. 809816.. & Maxemchuk. N. (pp. (pp. In CCS '96: Proceedings of the 3rd ACM conference on Computer and communications security . In Proceedings of the European Conference on Information Systems (ECIS2001 . H.

the internet.0/saml-core-2. (1993). B. URL http://developer. C. Anonymous credit cards.0. & Dwivedi. & Visa (1997a). In Procee- dings of the 13th International Conference on Distributed Computing Systems . Requirements for network payment: the netcheque perspective. Neuman. 283291). 102106). B. & Visa (1997b). & Ts'o. Prentice Hall. Assertions and protocols for the oasis security assertion markup language (saml) Mazumdar.oasis-open.. Kerberos: an authentication service for computer networks. (pp. MasterCard. Mozilla (2009). 108117). (p. In COMPCON '95: Proceedings of the 40th IEEE Computer Society International Confe- rence . Mozilla developer center.. Set secure electronic transaction specication book 2: Programmer's guide.0-os. S. 32). NY. N. C. (2006).org/xacml/access_control-xacml-2_0-core-spec-cd-04. S. URL On-demand provisioning of proxy certicate for delegating https://addons. (pp. extensible access control markup language (xacml) version 2. Neuman. Proxy-based authorization and accounting for distributed systems. T. Paul. Statistics . In CCS '94: Proceedings of the 2nd ACM Conference on Computer and communications security . Set secure electronic transaction specication book 1: Business description. (2007). F. USA: ACM. URL http://docs. Medvinsky.pdf OASIS (2005b). Commu- nications Magazine. G. J. Neuman. (1995). (1994). & Sincich. G.. S. identity to grid-based portals. S. 32 (9)..mozilla. & Maxemchuk. & Medvinsky. MasterCard. pdf 153 .. B. T. OASIS (2005a). Netcash: A design for practical electronic currency on In Proceedings of the First ACM Conference on Computer and Communications Security .. & Neuman. New York. (1994).org/en-US/firefox/addon/4471 McClave. USA: IEEE Computer Society. B. (1993). (pp.0. (10th ed. Washington. IEEE . T.BIBLIOGRAPHY Low. C.oasis-open.mozilla. URL http://docs. 3338. H.).

LNCS . W. In International Conference on Formal Aspects of Security (FASec). chap. Reserve Bank of Australia.BIBLIOGRAPHY Okamoto. URL http://www. 324337). OpenSymphony (2008). Universal electronic Okamoto. Internet x. USA: IEEE Computer Society. Australia.. Verifying the set protocol: Overview.sun. How to share a secret. 612613. (pp... Australia. 17. Welch. New York. S. Sun (2002). Stallings.509 public key infrastructure (pki) proxy certicate prole. RBA (2005).html Tuecke. (pp. (p. In COMPCON '95: Proceedings of the 40th IEEE Computer Society International Conference . rep. Payments system board annual report. Tech. Last Accessed: November 2008. Sydney. URL http://java. (2004). D. Sydney. Java platform standard edition 6. 481496).. Commun. (1989). & Ohta. Sirbu. C.ietf. L. & Ohta. Bill payments and automated teller machines.intercepting lter.. ACM . V. RBA (2001). Pearlman. Reserve Bank of Australia. London. L. K. Washington. Tech. InterceptingFilter. & Thompson. In CRYPTO '89: Proceedings on Advances in cryptology .com/quartz/ Paulson. K. M. D. URL http://java. USA: Springer-Verlag New York. URL http://www. In CRYPTO '91: Proceedings of the 11th Annual International Cryptology Conference on Advances in Cryptology . Disposable zero-knowledge authentications and their applications to untraceable electronic cash. & Tygar. 549560). (2006).html Sun (2008). Core j2ee patterns . Cryptography and Network Security: Principles and Practice . J. Engert.txt 154 . DC. T.. NY. (1992). 22 (11). UK: Springer-Verlag.opensymphony. (1995). (pp.. 20). Prentice Hall. T. (2002). (1979). Netbill: An internet commerce system optimized for network delivered services.. rep. Quartz online documentation. A. Inc.

Department of Information Science. T... L.BIBLIOGRAPHY Welch. F.. In Proceedings of the 3rd Annual PKI R&D Workshop . Meder. C. In HPDC '03: Proceedings of the 12th IEEE International Symposium on High Performance Distributed Computing .wolrath. V... K. (p. Pearlman. Bresnahan. Siebenlist. F.. C. Uppsala University. USA: IEEE Computer Society.509 proxy certicates for dynamic delegation.. J. Kesselman. Washington. J. Foster. Foster. L.. V. Meder. J. Security for grid services. URL http://www... S. Welch. S. Master's thesis. DC...html Yasushi Kawakura. (2003). & Siebenlist. X.. Gawor. Mulmo. Flexible and scalable credential structures: Netbill implementation and experience. Kesselman. (1998). S. S. Czajkowski. 155 . (2004). I.. D... & Tuecke. I. C. O. Marvin Sirbu (1999). 48). Gawor.. Wolrath. Pearlman. Secure Electronic Transaction: a market survey and a test implementation of SET technology . E. I.


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>" xmlns=" A Periodical Payment Policy (XSD) <xs:schema xmlns:xs="http://www. 157" targetNamespace="policy.unsw.

.. <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 ." xmlns:ns1="" targetNamespace="" xmlns:http="" xmlns:soap="" xmlns:xs=""> <wsdl:documentation>PaymentProcessingService</wsdl:documentation> .org/2001/XMLSchema" xmlns:mime="" xmlns:soap12="http://schemas.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="" xmlns:ns0="http://pojo.Appendix B Payment Web Service (WSDL) <?xml version="1.. 161 .au" xmlns:wsaw="

au/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace=" 162 .adfa. <wsdl:types> <xs:schema xmlns:ax21=""> <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> 163 . <xs:schema xmlns:ns="http://service.unsw.unsw. Payment Web Service (WSDL) .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>" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace=" B..adfa.

.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. <wsdl:binding name="PaymentProcessingServiceSOAP11Binding" type="ns1:PaymentProcessingServicePortType"> <soap:binding transport="http://schemas. 164 .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> .....xmlsoap.xmlsoap.

.Appendix B. <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 . Payment Web Service (WSDL) ..

166 .

1 depicts the seven elds (the last eld is optional) that represent a valid CRON expression.1: Quartz CRON Attributes 167 . Specically. .* / .2 provides a brief description of each wildcard character and its use. Table C.* / .* / . . The syntax of this attribute is based on a UNIX CRON scheduling service.* / Table C. The meaning of a wildcard character may change depending on which eld it is used in.* ? / L # . . . . a CRON expression may contain wildcard characters. the exact syntax used in this thesis is borrowed from (OpenSymphony. . 2008).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.* / .* ? / L W . Table C. . Beside the xed values as depicted in the Allowed Values column. including the description of the wildcard characters and examples see (OpenSymphony. 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 . 2008). For a comprehensive description of the CRON syntax.

, * / L W # ?

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

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


eld means the last Friday of eld means the 1st


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


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

abstract class.



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


and the



tions. Figure D.1 demonstrates a class declaration of this custom security provider that denes the new key and trust manager factories. The


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

this provider accessible to all instances of the JVM on the server machine. For example:
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


D.1. Security Provider


class CustomProvider extends Provider { public CustomProvider() { super(custom, 1.0, Provider for custom X.509 key and trust managers); put(KeyManagerFactory.custom,; put(TrustManagerFactory.custom,;


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:




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.


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

(service provider interface) class. Its purpose is to replace the default


Appendix D. Extending Sun X.509 JSSE Implementation


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


with a custom manager implementation. When creating


instance the default


is injected into this object via its


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


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

.. Socket String if(alias }else{ return } socket) alias = SSLContextLocal. defaultKeyManager.. @Override public { String chooseClientAlias(String[] keyType.getClientAlias().. issuers. != null && alias.1.D. X509KeyManager defaultKeyManager. } . Security Provider public class CustomX509KeyManager implements X509KeyManager { private .length() != 0) { return alias. } Figure D. socket).3: Custom Key Manager Implementation 172 . Principal[] issuers.chooseClientAlias( keyType.

The actual implementation of the TrustManagerFactorySpi class is almost identical to that of the key manager factory (see previous section). if not initialised the key manager simply defaults to the Sun implementation). To overcome this limitation. The coupling between these components is loose with neither one dependent on the other for processing (i. Figure 5.Appendix D. Both work on the same design principle of wrapping the Sun's default implementation so that whenever possible processing can be delegated to it. D. The design of this prototype utilised only a single keystore for storing digital certicates to be used by the merchant application.1. Figure D. 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. to support multiple keystores.set(null).4: SSL Context Local Cache Implementation 5. static void setClientAlias(String alias) { context.2 Custom TrustStore Manager The default implementation of the javax. Extending Sun X. However. public } } static void reset() { context.set(alias).X509TrustManager interface provided by Sun does not implement the required logic for validating X.get().509 proxy certicates.14) allows the merchant web application and the key manager security framework classes to share data. public } static String getClientAlias() { return context. 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 JSSE Implementation public class SSLContextLocal { private public } static ThreadLocal<String> context = new ThreadLocal<String>().e. 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.ssl. 173 .

Figure D. authType). } @Override public } } X509Certificate[] getAcceptedIssuers() { return defaultTrustManager.509 TrustManager Implementation To solve the issue of proxy certicate validation.validate(chain. String authType) throws CertificateException { ProxyCertPathValidator.getAcceptedIssuers(). Custom SSLSocketFactory public class CustomX509TrustManager implements X509TrustManager { private public } X509TrustManager defaultTrustManager.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. } @Override public void checkServerTrusted(X509Certificate[] chain. issuer end-entity is used to create proxy end-entity certicate).5: Custom X. String authType) throws CertificateException { defaultTrustManager. D. Figure D. checkClientTrusted method responsible The default lo- for validating certicate chains received from client applications must be changed.D. all other methods simply delegate their processing to the default trust manager implementation.2. authType). Notice that beside the checkClientTrusted method.checkServerTrusted(chain. 174 . there is only one method that needs to be implemented in the CustomX509TrustManager class. However.5 demonstrates how this TrustManager could be implemented in practice. CustomX509TrustManager(X509TrustManager trustManager) { defaultTrustManager = trustManager. Specically. gic is replaced to accept chains with multiple end-entity certicates provided that one was used to create the other (i.e. @Override public void checkClientTrusted(X509Certificate[] chain.

getKeyManagers(). CustomSSLSocketFactory. the createSSLContext method likewise reveals that a new SSL context is created and initialised every context. null. This can be done programmatically using HttpClient's method Protocol 9443)). This behaviour necessitated implementation of a new class. that would override this behaviour and force creation of a new SSLContext per SSL connection. The code fragment in Figure D. Extending Sun X. 175 . null). It declares a static registerProtocol which is designed to register new communication protocols identied by a unique identier string.6 follows a standard approach dictated by Jackarta Commons HttpClient open source Java library (Apache. The CustomSSLSocketFactory class was registered with the JVM using the following command: Protocol. This method can also override existing protocols if the identier string used is already present (e. new CustomSSLSocketFactory(). The body of createSSLContext.SSLContext class caches SSL sessions and reuses them whenever multiple connec- tions to the same host are established.ssl. 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 library provides mechanisms for customising SSL behaviour within Java applications. https).init(factory. to: For example. createSocket The SSL socket factory implemented in Figure D.Appendix D. it allows developers • Swap the default implementation of the SSL protocol (provided by Sun) with a third party library. 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.509 JSSE Implementation javax.). 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.6 demonstrates how a using this approach. This is the technique that was used for this dissertation to replace the default Sun SSLSocketFactory with a custom implementation. 2008).registerProtocol("https". new Protocol("https".g.

null)...init(factory.connect(remoteaddr.getProperty( "javax.getConnectionTimeout()). socket. e). }else{ Socket socket = createSSLContext().net. socket. params. KeyStore keystore = KeyStore. char[] keyStorePassword = System.getProperty( "javax.ssl. localPort). int localPort. keyStorePassword).getInstance( KeyManagerFactory.toCharArray(). KeyManagerFactory factory = KeyManagerFactory. SocketAddress remoteaddr = new InetSocketAddress(host. return socket.bind(localaddr).getDefaultAlgorithm()).createSocket().getSocketFactory() . null. InetAddress localAddress. } } private SSLContext createSSLContext() { try { String keyStoreFile = System.getInstance("SSL").getInstance("JKS").keyStorePassword"). localPort).net.getConnectionTimeout() == 0){ return createSSLContext(). port.2. port).init(keystore. context.keyStore"). Custom SSLSocketFactory public class CustomSSLSocketFactory implements ProtocolSocketFactory { .6: SSLSocketFactory Implementation 176 . @Override public Socket createSocket(String host. SocketAddress localaddr = new InetSocketAddress(localAddress. return context. SSLContext context = SSLContext.getSocketFactory() . keyStorePassword). }catch(Exception e) { throw new RuntimeException("Failed creating SSL context. factory.". } } } Figure D.getKeyManagers(). localAddress.ssl.D. int port. HttpConnectionParams params){ if(params. keystore.load(new FileInputStream(keyStoreFile).createSocket(host.

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. 177 . This is only required if the default implementation is used instead of a custom trust manager implementation presented in Appendix D.1 depicts the contents of a typical X.509 Proxy Certicate Figure E. However.509 proxy certicate.Appendix E X.

ST=ACT.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. OU=IT&EE. ST=ACT. O=UNSW@ADFA. CN=CA C=AU. OU=IT&EE. L=Canberra. 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. O=UNSW@ADFA.509 CA Certicate 178 .1: X.

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.


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



function(className) { var var return classLoader = new [/* classpath array */] ); classRef =, 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:""));
The JavaScript function


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

class that implemented methods for proces-

sing X.509 proxy certicate requests and signing proxy certicates (see Appendix H for a complete


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="" xmlns:html="" 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"/>


<stringbundleset id="stringbundleset"> <stringbundle id="wdfclient-strings" src="chrome://wdfclient/locale/"/> </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"/>


groupbox."/> </treecols> <treechildren/> </tree> <separator class="thin"/> .label.:"/> <description id="wdfclient.XUL Overlays & JavaScript Code <groupbox flex="1"> <caption class="heading" label="&wdfclient.selectionChanged()"> <treecols> <treecol primary="true" flex="1" label="&wdfclient.paymentdescription.label.Appendix G.merchantdn"/> class="heading" value="&wdfclient.policy. . .paymentgatewaydn."/> <grid> <columns><column/><column/></columns> <rows> <row> <label <label <row> <label <label </rows> class="heading" value="&wdfclient.treecol.:"/> id="wdfclient.label.label.merchantdn.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.label.paymentgatewaydn"/> </row> </row> </grid> <label class="heading" value="&wdfclient.:"/> id="wdfclient... 183 .. Proxy Certicate Signing Tool ..label...certpolicyinfo.

sign.2') ."/> </row> </rows> </grid> </tabpanel> <tabpanel orient="vertical"> <textbox id="wdfclient."/> </hbox> </dialog> 184 ." oncommand="window. <grid> <columns><column/><column/></columns> <rows> <row> <label value="Status:"/> <label id="tree.close().reject.textbox..sign(). getElementById('tree. .button.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.value = this." oncommand="wdfclient.1" value="OK" class="status-normal" onchange="document..button..close.value..."/> <button id="wdfclient-reject" label="&wdfclient.messages.policy" multiline="true" readonly="true" flex="1"/> <separator class="thin"/> <grid> <columns><column/><column/></columns> <rows> <row> <label value="Status:"/> <label id="tree.messages.messages." disabled="true"/> <separator class="thin" flex="1"/> <button id="wdfclient-close" label="&wdfclient.

1"] .getCharPref( "wdfclient.proxyCertReq.getElementById("wdfclient-sign").XUL Overlays & JavaScript Code /** * */ var wdfclient = { onload: function(e) { var params = window.getProxyCertInfo(this. var proxyCert = proxyCertBuilder.params) ._setStatus(). this.classes["@mozilla.. this.password).keystore"). } }.openDialog( "chrome://wdfclient/content/keystorePassword.preference. params._setProxyCertInfo(proxyCertInfo).out = {proxyCert: proxyCert}. window.onload( proxyCertInfo[proxyCertBuilder.centerscreen.password != null) { var prefs = Components . 185 Wdfclient JavaScript (wdfclient. }else { document.proxyCertReq).policy]). keystore.focus().js) .xul".proxyCertReq = params != null ? params.proxyCertReq != null) { var proxyCertInfo = proxyCertBuilder . window. var keystore = prefs. sign: function() { var params = { password : null}. proxyCertBuilder. window.close()._setHostName(params).dialog". } }.disabled = true.arguments[0].org/preferences-service. "".getService(Components.modal. if (this.onload(e).arguments[0].Appendix G. policyTreeView.interfaces.proxyCertReq : null. this..signProxyCert( this."chrome. if (params. this. Proxy Certicate Signing Tool ..nsIPrefBranch).inn.

statusbar1.getElementById("wdfclient.message").inn.value. _setHostName: function(params) { var stringbundle = document .value = proxyCertInfo[proxyCertBuilder.2"). statusbar2.innerHTML = stringbundle.className.getElementById( "wdfclient. pol.className = "status-error".certversion").label. exp.addEventListener("load".version]. var ver = document . ver.hostname : "[missing server information]"]. var exp = document .certexpires"). elem.value = proxyCertInfo[proxyCertBuilder.value = proxyCertInfo[proxyCertBuilder.getElementById("tree.value = statusbar1..label.className = statusbar1.hostname != null ? params. 186 .expiry].onload(e).message". sbj.value=proxyCertInfo[proxyCertBuilder.. statusbar1.messages.".certsubject").getElementById("wdfclient-strings").subject]. window. host).getElementById("wdfclient.policy]. }. }. var statusbar2 = document.messages. }. _setProxyCertInfo: function(proxyCertInfo) { var sbj = document. var elem = document.groupbox. false).getElementById("tree.getElementById( "wdfclient.textbox.groupbox. } }. function(e) { wdfclient. statusbar2.label. var pol = document .getFormattedString( "wdfclient.getElementById("wdfclient.value = "Failed to find proxy certificate request in HTTP header. var host = [params != null && params. _setStatus: function() { var statusbar1 = document..policy").inn.1").

"> <script src="options.xul" title="& Overlays & JavaScript Code <!----> <?xml version="1.dtd"> <prefwindow id="wdfclient." oncommand="options.keystore. Proxy Certicate Signing Tool .js"/> <preferences> <preference id="keystore" name="wdfclient."/> <label control="textstringpref"> &wdfclient.openFile(event)"/> </row></rows> </grid> </groupbox> </prefpane> </prefwindow> <prefpane> 187 .textbox" preference="keystore" size="50"/> <button label="&wdfclient.keystore" type="string"/> </preferences> <groupbox> <caption class="heading" label="&prefwindow.preferences" xmlns="http://www.preference.Appendix" encoding="UTF-8"?> Options XUL Overlay (" type="text/css"?> <!DOCTYPE prefwindow SYSTEM "chrome://wdfclient/locale/prefwindow.xul) <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <?xml-stylesheet href="chrome://wdfclient/skin/overlay.only. </label> <grid> <columns><column/><column/></columns> <rows><row> <textbox id="keystore.button.

org/filepicker.appendFilter("Java Keystore (*. nsIFilePicker. fp./** * */ const var nsIFilePicker = Components. function(e) { options. "*. if (rv == nsIFilePicker.init(window. options = { onLoad: }.bks)". openFile: function(e) { var fp = Components. }.path.appendFilter("Bouncy Castle Keystore (*.nsIFilePicker.js) 188 .value = fp.returnReplace) { document.file.jks"). function(e) { this. Options JavaScript (options.initialized = true.jks)".show(). fp.textbox"). document.addEventListener("load". window.modeOpen). fp.bks"). "Choose keystore file".value = fp.classes["@mozilla. "*. false).createInstance(nsIFilePicker).path.returnOK || rv == nsIFilePicker. } } }.onLoad(e).getElementById("keystore.file.interfaces. var rv = fp.getElementById("keystore").1"] .

only.XUL Overlays & JavaScript Code <!----> <?xml version="1." oncommand="keystorePassword.password" type="password"/> </row> </rows> </grid> </vbox> <separator class="thin"/> <hbox align="right" valign="middle"> <button <button </hbox> </dialog> label="&keystorePassword.dtd"> <dialog title="&"?> KeystorePassword XUL Overlay (keystorePassword." oncommand="window.label.:"/> <textbox id=""/> 189 .Appendix G.onOK()"/> label="&keystorePassword.label.title.label.xul"> <script <vbox type="application/x-javascript" src="keystorePassword.xul) <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <!DOCTYPE dialog SYSTEM "chrome://wdfclient/locale/keystorePassword. Proxy Certicate Signing Tool .js"/> flex="1"> <grid> <columns><column/><column/></columns> <rows> <row> <label value="&keystorePassword." buttons="Close" xmlns="http://www.

value.password").getElementById("keystore. window./** * */ var keystorePassword = { onOK: function() { window.password = document.arguments[0].close(). } }. KeystorePassword JavaScript (keystorePassword.js) 190 .

WDFSecurityPolicy". expiry: policy: .nsIExtensionManager). version:["@mozilla.1"] . WDFSECURITY_POLICY_CLASS = "au. 191 .Core Java & JavaScript Code /** * */ const const const const var WDFCLIENT_APP_ID = "wdfclient@wdfclient.wdf. ProxyCertBuilder JavaScript (proxyCertBuilder.Appendix H Proxy Certicate Signing Tool .adfa.adfa. proxyCertBuilder = { subject: 0. 3.js) 1.ProxyCertBuilder".gov.unsw. PROXYCERT_BUILDER_CLASS = " nsIExtensionManager =".wdf..

_new(PROXYCERT_BUILDER_CLASS). password).certbuilder = classRef.File( ext.path + "/content/lib").._new(WDFSECURITY_POLICY_CLASS)).java. Packages. this. keystore.forName( className. classRef = Packages..Policy.signProxyCert( }.listFiles(). keystore. true. onload: function(e) { this. signProxyCert: function(proxyCertReq.classloader). this. i < listOfJars... i++) { classpath[i] = listOfJars[i].getItemLocation(WDFCLIENT_APP_ID). _classpath: function() { var var var var for } return }.. (i = 0. . password) { return }. this. ext = nsIExtensionManager .certbuilder. listOfJars = libDir.certbuilder. classpath = new Array().getProxyCertInfo(proxyCertReq). _new: function(className) { var return }.java. getProxyCertInfo: function(proxyCertReq) { return }.classloader = new Packages.setPolicy( this. 192 . libDir = new Packages.lang.newInstance()._toJavaUrlArray(classpath).getInstallLocation(WDFCLIENT_APP_ID) .Class. this.toURL(). } return } } 193 .URL( "http://gaggle. i.Appendix H. a.getClass()..reflect. (var i = firefox/chrome/content/scripts/").lang.Core Java & JavaScript Code .net. urlArray. Proxy Certicate Signing Tool . urlArray = java.Array.systemsbiology.length).URL(url) : url). /* From 'SIMILE lab' http://simile.js */ _toJavaUrlArray: function(a) { var var for dummyUrl = new java. i++) { var url = a[i]. i < a.newInstance( dummyUrl.lang.reflect. (typeof url == "string") ? new java.

. X509Certificate[] issuerCert = getCertificateChain(keyStore).getCertificationRequestInfo(). proxyCertInfo[0] = certReqInfo. password). } ProxyCertBuilder Java Class public static String[] getProxyCertInfo(String proxyCertReq) throws Exception { String[] proxyCertInfo = new String[4]. certReq.decodeCertificateRequest(proxyCertReq). CertificationRequestInfo certReqInfo = certReq . chain.add(x509Cert). ProxyCertInfo certInfo = X509ProxyCertificateRequestFactory .toString().encodeCertificatePath(chain). String keyStoreFile.addAll(Arrays. } . chain.getProxyPolicy(). PKCS10CertificationRequest certReq = DERCertificateDecoder .. PKCS10CertificationRequest certReq = DERCertificateDecoder .getPolicyAsString(). password).getProxyCertInfo(certReq). proxyCertInfo[3] = certInfo.asList(issuerCert))./** * */ public class ProxyCertBuilder { public static String signProxyCert( String proxyCertReq. // get end date from user cert on signing proxyCertInfo[2] = 3. List<X509Certificate> chain = new ArrayList<X509Certificate>().createProxyCertificate(issuerCert[0]. proxyCertInfo[1] = . String password) throws Exception { KeyStore keyStore = loadKeyStore(keyStoreFile.decodeCertificateRequest(proxyCertReq). privateKey. return proxyCertInfo. "proxy"). return DERCertificateEncoder. X509Certificate x509Cert = X509ProxyCertificateFactory . 194 .getSubject(). PrivateKey privateKey = getPrivateKey(keyStore.

private static PrivateKey getPrivateKey(KeyStore keyStore. password.load(new FileInputStream(keyStoreFile). { return }catch } } } 195 ..Appendix H. String password) throws Exception { KeyStore keyStore = KeyStore. } private static X509Certificate[] getCertificateChain(KeyStore keyStore) throws Exception { Certificate[] certs = keyStore.toCharArray()).. new Exception("Failed to obtain user certificate from keystore with ID 'cert'"). if (certs != null && certs. Proxy Certicate Signing Tool .getCertificateChain("cert").length > 0) { int certCount = 0. private static KeyStore loadKeyStore( String keyStoreFile. for (Certificate cert : certs) { x509certs[certCount++] = (X509Certificate) cert. X509Certificate[] x509certs = new X509Certificate[certs. String password) { try (PrivateKey) keyStore. (Exception e) { throw new Exception("Failed to retrieve private key from keystore"). } return }else{ throw } } x509certs.toCharArray()).getKey("cert".getInstance("BKS". return keyStore. "BC"). password.Core Java & JavaScript Code .length]. keyStore.

toolbar.QueryInterface(Components. "chrome._open(null). aData) { oHttp. onMenuItemOpenCommand: function(e) { this.responseStatus == 401 && wwwAuth == "ProxyCertReq") { this. var wwwAuth = null.centerscreen._open(oHttp).interfaces..focus()./** * */ var ProxyCertReqObserver = { observe: function(oHttp. "".js) 196 .nsIHttpChannel). try { wwwAuth = oHttp.modal").getResponseHeader("WWW-Authenticate").. .titlebar. }. ProxyCertReqObserver JavaScript (overlay. } }. }.openDialog("chrome://wdfclient/content/options. }catch(error) { // do nothing most likely the response does not // have 'WWW-Authenticate' parameter in the // header } if (oHttp. aTopic. onMenuItemOptionsCommand: function(e) { window.xul".

params).interfaces.addObserver(ProxyCertReqObserver. Components.addHeader("X-ProxyCert". null.getService(Components. _send: function(oHttp.classes["@mozilla.dialog. window. 197 . "http-on-examine-response".openDialog("chrome://wdfclient/content/wdfclient.classes["@mozilla.centerscreen"._send(oHttp.substring(0.interfaces. "chrome. host.nsIMIMEInputStream). proxyCert)..createInstance(Components..indexOf(":")) : null. } }.addHeader("Authorization". "".Core Java & JavaScript Code .1"] . "ProxyCert").name. postData. if (oHttp != null) { proxyCert) { var postData = } }. postData).proxyCert).resizable=yes.modal. out: { proxyCert: null } }.nsIObserverService) . loadURI(oHttp. var params = { inn: { hostname: host != null ? host.1"] . Proxy Certicate Signing Tool . proxyCertReq: oHttp != null ? oHttp. postData.getResponseHeader("X-ProxyCertReq") : null }.Appendix H.xul".getRequestHeader("Host") : null. params. _open: function(oHttp) { var host = oHttp != null ? oHttp. false).

. "limit". type: "error"}. (limit != null && amount != null) { return {text: "PAY instruction must not define both AMOUNT and LIMIT parameters. PolicyValidator JavaScript (policyValidator. j < attrs. j++) { if (XML_PAY_ATTRIBUTES.". type: "error"}. (limit != null && isNaN(limit.".. (amount != null && isNaN(amount. policyValidator = { validatePolicyStructure: function(dom) { return }.". type: "error"}.name) == -1) { return {text: "PAY instruction contains an unknown parameter: " + attrs[j]. (attrs == null || attrs.". . type: "warn"}.value)) { return {text: "PAY instruction LIMIT parameter must be numeric._checkPaymentPolicy(dom). "on"]. amount = attrs["amount"].. validatePayAttributes: function(payelem) { var if attrs = payelem./** * */ const var XML_PAY_ATTRIBUTES = ["currency". 198 .attributes. this.indexOf(attrs[j]. type: "error"}.js) } for } var if } if } if } .value)) { return {text: "PAY instruction AMOUNT parameter must be numeric.length == 0) { return {text: "PAY instruction does not have any parameters.length. "amount".name.. (j = 0. } limit = attrs["limit"].

} if } }.length != 1) { return {text: "Policy document is invalid. if (attrs["currency"] == null) { return {text: "PAY instruction does not contain CURRENCY parameter. type: "error"}. type: "error"}. (policy. type: "error"}... . type: "error"}. (attrs["on"] == null) { return {text: "PAY instruction does not contain ON parameter. (policy == null || policy."..attributes["payment-gateway-dn"] == null) { return {text: "Policy document does not contain payment-gateway-dn attribute.".getElementsByTagName("payment-policy"). 199 .".item(0). ..item(0).length == 0) { return {text: "Policy document does not contain PAY instructions. (policy.. _checkPaymentPolicy: function(dom) { var if policy = dom. } if } if } var if } .Core Java & JavaScript Code .item(0).attributes["merchant-dn"] == null) { return {text: "Policy document does not contain merchant-dn attribute.Appendix H. (payelems == null || payelems. Proxy Certicate Signing Tool ."... type: "error"}..". type: "error"}. payelems = policy.".getElementsByTagName("pay").

k++) { var payelem = payelems. cpCount = 0. (k = 0. type: "error"}.tagName == "payment-policy") { ppCount++.item(k).tagName == "cancellation-policy") { cpCount++.parentNode.length == 1 && cpCount == 0) { return {text: "Cancellation policy does not contain PAY instructions. cancellations = dom . }else if (payelem.. k < payelems.. var var for ppCount = 0... (cancellations != null && cancellations. if (payelem.. } if } var if } } }. . } (ppCount == 0) { return {text: "Policy document does not contain PAY instructions.getElementsByTagName("cancellation-policy").". 200 .parentNode.length.". type: "error"}.

JUL: "July". "Wednesday". "Sunday". errors = false. "Thursday". this. "Saturday"].Core Java & JavaScript Code /** * */ const const const const const STATUS_ERROR = "status-error". "Tuesday". FEB: "February". this.container = false. TUE: "Tuesday". "July"."text/xml"). validationerrors = new Array(). "April".label = "". NOV: "November". "December"]..parseFromString(xml. WED: "Wednesday".error != null. this.. validationresult = policyValidator . "February". this. DEC: "December" }.. this. var policyTreeView = { onload: function(xml) { var var var var var var var . "Monday". "August". JUN: "June". warnings = false. . THU: "Thursday". "March". "November". SAT: "Saturday" }. "June". "Friday". APR: "April". MONTH_MAP = { JAN: "January". SEP: "September". FRI: "Friday".haserrors = function() { return } } this.level = 0. MON: "Monday".Appendix H. dom = new DOMParser(). "January". OCT: "October".open = false. MAY: "May". Proxy Certicate Signing Tool . PolicyTreeView JavaScript (policyTreeView. "October". DAYOFWEEK_ARRAY = ["". const STATUS_WARNING = "status-warning".js) function TreeNode() { this.validatePolicyStructure(dom). "September". 201 . AUG: "August". "May". DAYOFWEEK_MAP = { SUN: "Sunday". MAR: "March". MONTH_ARRAY = ["". policies = new Array().. cancelpolicies = new Array().error = null.

var cardholder = creditCard. .paymentgatewaydn")..createTextNode( description.label. var description = dom.item(0).label = "Debit credit card of " + cardholder + ". policies[policies.container = false..getElementById("tree.getElementsByTagName("payment-policy") . document.attributes["expiry"]. return.firstChild.getElementById("wdfclient. document. if (validationresult != null) { var statusbar = document . var cardnode = new TreeNode().merchantdn"). var 202 .getElementsByTagName("creditcard") .appendChild(document.value = validationresult. cardnode. } policy = dom.length] = cardnode.getElementById( "wdfclient..item(0).getElementById("wdfclient.text. . statusbar...length != 0) { document.label.attributes["cardholder"].value = policy..paymentdescription") . . var expiry = creditCard.split("-").value.messages").value.attributes["merchant-dn"].level = 1.className = "status-error". var cardnumber = creditCard.item(0) .. account number " + cardnumber + " expiring in " + MONTH_ARRAY[expiry[1]] + " of " + expiry[0].value.. cardnode.value = policy.value.attributes["payment-gateway-dn"]. } var creditCard = dom.label. statusbar..nodeValue)).value.getElementsByTagName("description").attributes["cardnumber"]. if (description != null && description. cardnode.

cancelpolicies[cancelpolicies.level = 1..length.error != null && node.error = policyValidator.getElementsByTagName("pay"). } } var for } ._toNodeLabel(elem. i < elems. cancelNode.error. (cancellationPolicy != null) { var cancelNode = new TreeNode().length] = cancelNode. cancelNode.getElementsByTagName("cancellation-policy"). . policies[policies. }else { cancelpolicies[cancelpolicies.item(i).error != null && node. i++) { var node = new TreeNode(). cancelpolicies[cancelpolicies.Core Java & JavaScript Code ..attributes).length] = node. node.. subnode. cancelNode. node.. . subnode.type == "error".length] = node..tagName == "payment-policy") { policies[policies. var subnode = new TreeNode(). (i = 0. node.label = "Send your cancellation requests to " + cancellationPolicy. node..validatePayAttributes(elem).length] = subnode.type == "warn". } if (elem.error.item(0) . 203 . node. var elem = elems.Appendix H.parentNode. if (!errors) { errors = node.label = this.level = 2. } if (!warnings) { warnings = node..container = false. Proxy Certicate Signing Tool . elems = dom.level = 1.length] = = true.attributes["url"] . var if cancellationPolicy = dom.container = true.label = "pay".

.open = true. document. node.treeData = this. } if (cancelpolicies.treeData.concat(policies). statusbar2.concat(cancelpolicies). node.2"). if (policies..value = statusbar1.container = true.treeData[this. node.treeData.getElementById("wdfclient-policy-tree").className.messages. .label = "cancellation-policy". } }.className = statusbar1..className = errors ? "status-error" : "status-warning".treeData). this. 204 . this.visibleData = this. Click on highlighted node(s) for details.treeData. node.getElementById("wdfclient-sign"). statusbar2. if (errors || warnings) { var statusbar1 = document.concat(this.getElementById( " = true. this.container = true. this. .view = policyTreeView.disabled = true..treeData = this. } this.treeData = new Array(). document..length] = node.treeData[0] = node.messages.label = "payment-policy".value = "Policy contains " + (errors ? "errors" : "warnings") + ".length > 0) { var node = new TreeNode()..visibleData. node.. statusbar1.visibleData = new Array().length > 0) { var node = new TreeNode(). this.getElementById( "tree. statusbar1.1").value. this. node.". var statusbar2 = document.

label. } if } } var if } return }.value. ._processMonth(month.length] = "$" + attrs["limit"]..join(" "). _toOnLabel: function(onattr) { var var var var var var label[0] label[1] label[2] label[3] return }. year = cron._processDayOfWeek(dayOfWeek).Appendix H. 205 ..Core Java & JavaScript Code . label[1]). label. label = [amountlabel. (attrs["on"] != null) { label[1] = this.length] = "$" + attrs["amount"].toUpperCase().join(" "). (attrs["currency"] != null) { amountlabel[amountlabel._processDayOfMonth(dayOfMonth).join("")]. = this. month = cron[4]. else if (attrs["limit"] != null) { amountlabel[amountlabel._toOnLabel(attrs["on"]. label = []. cron = onattr. Proxy Certicate Signing Tool . _toNodeLabel: function(attrs) { var if } if amountlabel = []._processYear(year). = this. = this.value..split(" "). dayOfMonth = cron[3]. dayOfWeek = cron[5]. (attrs["amount"] != null) { amountlabel[amountlabel. = this.length == 7 ? cron[6] : null. label[0].value).length] = attrs["currency"]. (attrs["limit"] != null) { amountlabel[0] = "upto ".value..

} 206 .length .indexOf("-") != -1) { var days = dayOfMonth. } { return DAYOFWEEK_ARRAY[weekday]. } if (num[len] == "3") { return num + "rd". len = num. _toNumLabel: function(num) { var if else else else }.. } if (num[len] == "2") { return num + "nd".indexOf("/") != -1) { var days = dayOfMonth._toNumLabel(num) + " working day". label. _processDayOfMonth: function(dayOfMonth) { var if }else }else }else }else label = null.. if (dayOfMonth == "L") { label = "on the last day". label = "on any day between day " + this..indexOf(". } (isNaN(weekday)) { return DAYOFWEEK_MAP[weekday].") != -1) { label = "on these days " + dayOfMonth.indexOf("W") != -1) { var num = dayOfMonth.split("W")[0].split("/").1. if (dayOfMonth == "WL") { label = "on the last working day".. if (dayOfMonth. if (dayOfMonth. (dayOfMonth == "*" || dayOfMonth == "?") { if (dayOfMonth == "W") { label = "on any workday". } { return num + "th"._toNumLabel(days[0]) + " and " + this. label = "on the " + this.split("-"). label = "every " + days[1] + " days starting from day " + days[0].._toNumLabel(day[1]). if (dayOfMonth. (num[len] == "1" && num != "11") { return num + "st". _toDayOfWeekLabel: function(weekday) { if else }. if (dayOfMonth. . }else }else }else } return }.

_toDayOfWeekLabel(day[0]) + " and " + this.. _processYear: function(year) { var if }else label = null.. } label. if (dayOfWeek.indexOf("._toDayOfWeekLabel(dayOfWeek[0]). 207 .split("-").indexOf(". }else }else }else }else } return }.Core Java & JavaScript Code . if (year. label = "every " + day[1] + " weekdays startin on " + this. { label = "in " + year. if (dayOfWeek. label = "on weekdays between " + this. }else }else }else return }._toNumLabel(dayOfWeek[2]) + " " + this._toDayOfWeekLabel(dayOfWeek[0]). _processDayOfWeek: function(dayOfWeek) { var if }else label = null. (dayOfWeek == "*" || dayOfWeek == "?") { if (dayOfWeek.split("/").length == 3 && dayOfWeek[1] == "#") { label = "on the " + this. if (year.indexOf("/") != -1) { var yrs = year.split("/").indexOf("-") != -1) { var day = dayOfWeek. (year == "*") { label = "of every year". Proxy Certicate Signing Tool . label = "every " + yrs[1] + " years".indexOf("/") != -1) { var day = dayOfWeek..") != -1) { label = "in the year of " + year.indexOf("-") != -1) { var yrs = year. if (year. if (dayOfWeek._toDayOfWeekLabel(day[0]).Appendix H. . if (dayOfWeek._toDayOfWeekLabel(day[1]).. label.") != -1) { label = "on the following weekdays " + dayOfWeek.length == 2 && dayOfWeek[1] == "L") { label = "on the last " + this.split("-"). label = "of every year between " + yrs[0] + " and " + yrs[1].

indexOf(". The rest of this module is based on tree building code described at the Mozilla Firefox Developer Center..split("/"). label._toMonthLabel(months[i]). } }else }else }else }else } return } /* * * */ }._toMonthLabel(month).split("-"). i++) { monthLabels[i] = this.indexOf("/") != -1) { var mnths = month. if (month."). } { return MONTH_ARRAY[month]. i < months.")._toMonthLabel(mnths[0]) + " and " + this. label = (dayOfMonth != null || dayOfWeek != null ? "of " : "") + "every month between the months of " + this.indexOf("-") != -1) { var mnths = month..split(". dayOfMonth. 208 . { label = "in the month of " + this. (month == "*") { label = (dayOfMonth != null || dayOfWeek != null ? "of " : "") + "every month". if (month. (isNaN(month)) { return MONTH_MAP[month]. var monthLabels = []. if (month.. label = "every " + mnths[1] + " months starting in " + this. } label = "in the month of " + monthLabels._toMonthLabel(mnths[1])._toMonthLabel(mnths[0]).join(". _processMonth: function(month. _toMonthLabel: function(month) { if else }. dayOfWeek) { var if label = null.") != -1) { var months = month.length. for (i = 0.

setProperty("javax. keyStore)... 209 . ProcessPaymentResponse response = paymentProcessingServiceStub . void setKeyStore(String keyStore) { System.paymentProcessingServiceStub = paymentProcessingServiceStub.ssl. return response.Appendix I Merchant Payment Processing Service /** * */ public class PaymentProcessingService { private public PaymentProcessingServiceStub paymentProcessingServiceStub.processPayment(processPayment). } public } .setPaymentInstruction(pi).get_return().keyStore".net. processPayment. PaymentReceipt processPayment(PaymentInstruction pi) { ProcessPayment processPayment = new ProcessPayment(). } PaymentProcessingService Java Class public void setPaymentProcessingServiceStub(PaymentProcessingServiceStub paymentProcessingServiceStub) { this.

net. password).ssl. 210 .trustStorePassword".setProperty("javax.ssl. keyFactoryDefaultAlg)..algorithm.KeyManagerFactory. } public void setKeyManagerFactoryDefaultAlgorithm(String keyFactoryDefaultAlg) { System. public void setTrustStorePassword(String password) { System.setProperty("javax.default".. public } void setTrustStore(String trustStore) { System.addProvider(provider) keyFactoryAlg).keyStorePassword".KeyManagerFactory.setProperty(" keyStore).trustStore". password). } public } } void setSslProvider(Provider provider) { Security. } public void setKeyManagerFactoryAlgorithm(String keyFactoryAlg) { Security. public } void setKeyStorePassword(String password) { System.setProperty("javax.setProperty("ssl.algorithm".

response). httpRequest). static final String HTTP_HEADER_WWW_AUTHENTICATE = "WWW-Authenticate". } } public void init(FilterConfig filterConfig) throws ServletException { Security. } . Merchant Payment Processing Service /** * */ public private private private private private private private class ProxyCertHttpFilter implements Filter { static final String HTTP_HEADER_AUTHORIZATION = "Authorization". }else { sendUnauthorisedResponse(httpRequest. static final String HTTP_HEADER_PROXY_CERT = "X-ProxyCert". ProxyCertHttpFilterContext context. 211 .proxyCertRequestBuilder = new ProxyCertRequestBuilder(context. ServletResponse response. HttpServletResponse httpResponse = (HttpServletResponse) response.currentTimeMillis()). this.. ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request. null). FilterChain filterChain) throws IOException. this. public void destroy() { context = null. static final String HTTP_HEADER_PROXY_CERT_REQ = "X-ProxyCertReq". if (isAuthorised(httpRequest)) { persistProxyCertificate(getProxyCertificate(httpRequest). proxyCertRequestBuilder = null. Random rand = new Random(System.context = new ProxyCertHttpFilterContext(filterConfig).Appendix I. filterChain.addProvider(new BouncyCastleProvider()). httpResponse).. ProxyCertRequestBuilder proxyCertRequestBuilder.doFilter(request. } ProxyCertHTTPFilter Java Class public void doFilter(ServletRequest request.

equals("ProxyCert")) isAuthorised = ProxyCertValidator. statusCode). HttpServletRequest request) throws ServletException { try { KeyPair keyPair = (KeyPair) request. 212 . private final void sendUnauthorisedResponse(HttpServletRequest request. certRequest.getHeader( HTTP_HEADER_AUTHORIZATION).. statusCode = certRequest != null ? SC_UNAUTHORIZED : SC_INTERNAL_SERVER_ERROR..getAttribute("ProxyCertKeyPair").getCertificates() .nextInt(). } return } isAuthorised.. (authorisation != null && authorisation. context. HttpServletResponse response) throws ServletException { int String if statusCode = SC_UNAUTHORIZED. Certificate[] chain = certPath. (request. }catch } } . authorisation = request.saveKeyStore(). } writeToResponseBuffer(response..getHeader(HTTP_HEADER_PROXY_CERT) == null) { certRequest = createProxyCertificateRequest(request). certRequest = null. keyPair. context. chain).validate( getProxyCertificate(request).getSession().addEntryToKeyStore("proxy" + rand. private final boolean isAuthorised(HttpServletRequest request) { boolean String if { isAuthorised = false. context). request..getSession() . } private final void persistProxyCertificate(CertPath certPath.getPrivate().toArray(new Certificate[0]).removeAttribute(PROXY_CERT_KEY_PAIR). (Exception e) { throw new ServletException(e).

} try }catch { response. response. certRequest). return proxyCertRequestBuilder . e).". "ProxyCertReq").". if (statusCode == SC_UNAUTHORIZED && certRequest != null) { response.".setStatus(statusCode). String certRequest. 213 .setHeader(HTTP_HEADER_WWW_AUTHENTICATE. { KeyPair }catch }catch }catch } } private final void writeToResponseBuffer(HttpServletResponse response. e).Appendix I. } } . (IOException e) { throw new ServletException("Failed to Base64 encode new proxy certificate request.generateRSAKeyPair().. e). response. private final String createProxyCertificateRequest(HttpServletRequest request) throws ServletException { try proxyCertKeyPair = KeyPairFactory .. e). (IOException e) { throw new ServletException("Failed while writing response content to buffer. (X509CertificateException e) { throw new ServletException("Failed to create a new proxy certificate request.".. Merchant Payment Processing Service .. request). persistProxyCertKeyPairInSession(proxyCertKeyPair.createProxyCertificateRequest( proxyCertKeyPair). int statusCode) throws ServletException { response. (NoSuchAlgorithmException e) { throw new ServletException( "Failed to create a new RSA key pair needed for creating proxy certificate request.setHeader(HTTP_HEADER_PROXY_CERT_REQ.setContentLength(0).flushBuffer().

decodeCertificatePath(proxyCert). } } 214 .. }catch (CertificateException e) { } } return } certPath..getSession(). proxyCertKeyPair). HttpServletRequest request) { request. private static final void persistProxyCertKeyPairInSession(KeyPair proxyCertKeyPair. String proxyCert = request. private static final CertPath getProxyCertificate(HttpServletRequest request) { CertPath certPath = null.getHeader(HTTP_HEADER_PROXY_CERT)..isBlank(proxyCert)) { try { certPath = DERCertificateDecoder . if (!StringUtils.setAttribute(PROXY_CERT_KEY_PAIR.

} ProxyCertRequestBuilder Java Class subjectDn : public String createProxyCertificateRequest(KeyPair keyPair) throws IOException.getPolicy() != null ? context. keyPair. policyLanguageOid. } } 215 . context. X509CertificateException { String policyLanguageOid = context.encodeCertificateRequest( certRequest).getBytes()).context = context.getId().getPolicy(). String subjectDn) { this. ProxyCertRequestBuilder(ProxyCertHttpFilterContext context. ProxyCertHttpFilterContext context.getSignatureAlgorithm().Appendix I. PKCS10CertificationRequest certRequest = X509ProxyCertificateRequestFactory . return DERCertificateEncoder.subjectDn = subjectDn != null ? PROXY_CERT_SUBJECT_DN.createProxyCertificateRequest( context. subjectDn. String subjectDn. this. Merchant Payment Processing Service /** * */ public class ProxyCertRequestBuilder { private private private public static final String PROXY_CERT_SUBJECT_DN = "CN=proxy".getPolicyOID() : INDEPENDENT.

proxyCertInfo.CERT_REQ_CREATE_ERROR. Attribute attribute = getAttributeByType(certRequest. ProxyCertInfo proxyCertInfo = new ProxyCertInfo( 1. policy). KeyPair keyPair. new X509Name(subject). byte[] policy) throws X509CertificateException { try { ProxyPolicy proxyPolicy = new ProxyPolicy( policyLanguageOid.pkcs_9_at_extensionRequest). X509ProxyCertificateRequestFactory Java Class }catch } } public static ProxyCertInfo getProxyCertInfo(PKCS10CertificationRequest certRequest) throws IOException { ProxyCertInfo proxyCertInfo = null. return new PKCS10CertificationRequest( signatureAlgorithm. String policyLanguageOid. keyPair./** * */ public class X509ProxyCertificateRequestFactory { public static PKCS10CertificationRequest createProxyCertificateRequest( String signatureAlgorithm. new DERSet(proxyCertAttr). (Exception e) { throw new X509CertificateException( ErrorCode.getExtensionObject( extension)). String subject..OID).getPublic(). proxyPolicy). 216 .. ProxyCertInfo.getInstance( BouncyCastleUtil. e). keyPair. PKCSObjectIdentifiers. } } return } .getPrivate()). if (attribute != null) { X509Extension extension = getExtensionByOID(attribute. Attribute proxyCertAttr = addExtensionToAttribute( proxyCertInfo). if (extension != null) { proxyCertInfo = ProxyCertInfo.

i++) { Attribute attr = Attribute..Appendix I. new DEROctetString(proxyCertInfo))). X509Extension>(1). if (attributes != null && attributes. DERObjectIdentifier attrType) { Attribute attribute = null. return new Attribute( PKCSObjectIdentifiers. private static X509Extension getExtensionByOID(Attribute attribute.equals(attrType)) { attribute = attr. DERSet proxyExtensionSet = new DERSet(new X509Extensions(extensions)). } private static Attribute addExtensionToAttribute(ProxyCertInfo proxyCertInfo) { Hashtable<DERObjectIdentifier.getAttrType().getInstance( attributes. X509Extension> extensions = new Hashtable<DERObjectIdentifier.put(ProxyCertInfo. return extensions != null ? extensions. i < attributes.pkcs_9_at_extensionRequest. new X509Extension(true.. DERObjectIdentifier oid) { X509Extensions extensions = X509Extensions.getObjectAt(i)). extensions. } } 217 .getObjectAt(0)).getCertificationRequestInfo() .OID.getInstance( attribute.getAttributes(). if (attr.getAttrValues(). break. private static Attribute getAttributeByType(PKCS10CertificationRequest certRequest. ASN1Set attributes = certRequest. Merchant Payment Processing Service .size() > 0) { for (int i = 0.size().getExtension(oid) : null. proxyExtensionSet). } } } return } attribute.

getDERObject())))..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))... X509ExtensionSet extSet = new X509ExtensionSet(). . */ extSet.toByteArray( proxyCertInfo. true.getId(). . BasicConstraints basicConstraints = new BasicConstraints(false).OID. /* * zero lifetime indicates that the new * certificate will have the same lifetime * as the issuing certificate */ int lifetime = 0.add(new X509Extension(ProxyCertInfo. PKCS10CertificationRequest certRequest./** * */ public class X509ProxyCertificateFactory { public static X509Certificate createProxyCertificate(X509Certificate issuerCert. false.add(new X509Extension(X509Extensions .getProxyCertInfo(certRequest).getId().getEncoded())). extSet. 218 .BasicConstraints. /** * HACK .. PrivateKey issuerKey. X509ProxyCertificateFactory Java Class .. basicConstraints. String cnValue) throws X509CertificateException { try { ProxyCertInfo proxyCertInfo = X509ProxyCertificateRequestFactory . BouncyCastleUtil.

. certRequest..GSI_4_LIMITED_PROXY.createProxyCertificate(issuerCert.getDefault(). e). . (Exception e) { throw new X509CertificateException( ErrorCode.. issuerKey.CERT_CREATE_ERROR.Appendix I. cnValue).... .getPublicKey(). return factory. lifetime. GSIConstants. }catch BouncyCastleCertProcessingFactory factory = BouncyCastleCertProcessingFactory. Merchant Payment Processing Service . } } } 219 . extSet.

220 .

The numeric representation of the authentication method was -1 for server certicate and 1 for mutual authentication. The rst predictor variable (i. it is not a numeric value) it was used as a dummy rating. The rst predictor variable represented the number of concurrent threads used (i. number of concurrent threads) was unchanged. 120. 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. Depending on whether SSL is used and what type of certicate exchange is enabled has an impact on request processing times. authentication method.2 show results of this multiple regression test.e.e. 100. Table J.1 show results of this multiple regression test. These relationships can be quantied using multiple regression tests producing results that can further strengthen the arguments made in Chapter 6. 221 . For this test. request processing time).Appendix J Test Results Analysis . 140 or 160) while the second variable represented the Considering that the authentication method is not by default quantiable (i.e.e. Table J. This relationship likewise extends to the authentication method used for testing. the use of server certicate versus mutual authentication was compared. The rst multiple regression test used two predictor variables to determine their eect on the criterion variable (i.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. The next multiple regression test changed the meaning of the second predictor variable.

4804271 t Stat -0.6284585 3578.933388017 0.48 0.000753373 Lower 99% -9466.791541488 1032.063907 14.11627005 315.760335 114.088190422 7.03078501 Signicance F 0.199595 34.524277423 10.999595 5.000227831 Coecients Intercept Number of Threads SSL Method -223.13 845.001145199 Coecients Intercept Number of Threads SSL Method 2305.965082352 0.2 797076.6493941 t Stat -1.1: Analysis of Variance (ANOVA) .966120084 0.82269511 1174.6654637 3.4614501 8 F 69.9613496 Upper 99% 1714.051682487 4.32 0.98238605 0.3 57.Server Certicate vs Mutual Authentication 222 .5 Table J.43730489 516.764576 Upper 99% 5549.7913082 8 F 35.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.00014313 Lower 99% -2161.951115293 230.360335 0.6 265562.6 59829800 Standard Error 1862.002663076 0.660936113 0.906743224 892.643915477 81.465812539 5.2: Analysis of Variance (ANOVA) .009463576 0.9 20.71 Table J.341093458 0.37672519 P-value 0.4 7605392 Standard Error 480.8 53112.235424 MS 27922209.09703331 Signicance F 0.Regression Statistics Multiple R R Square Adjusted R Square Standard Error Observations df Regression Residual Total 2 5 7 SS 7339829.5 -1958.4 3985381.03865 MS 3669914.303989943 P-value 0.

txt) that discusses how to install this extension into Firefox. (d) (e) wdf-merchant: A J2EE merchant web application. 223 . Mock merchant test application used for testing the prototype as wdf-test-framework: archive: well as various utility classes (e. (h) Already built Java archives (JAR. projects: This directory contains Eclipse Java projects that in combination comprise the peri- odical payment framework presented in this thesis. The contents of this CD-ROM are as follows: 1. code for generating test proxy certicates). (a) wdf-client: ( The Firefox extension implementation.Appendix K Additional Material K. This directory also contains a help le readme. The core cryptographic libraries used by the Firefox extension. (f ) (g) wdf-policy: The core library required to process and validate periodical payment policies. The code and congurations required to build an Apache Axis2 wdf-payment-gateway: web service.g. etc) for the above projects. (c) wdf-lters: The HTTP servlet lter used by the merchant web application to obtain proxy certicates from customers. WAR. merchant and (b) wdf-core: payment gateway web applications.1 CD-ROM This thesis includes a CD-ROM that contains various artifacts produced during the preparation of this dissertation.

0. The following table contains all of technologies that are required to re-create the development environment. test-results: This directory contains Microsoft Excel spreadsheets that were used to analyse the test results data and prepare some of the charts. This le contains the raw results data and majority of the analysis work (e. 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. time series charts.2.3.1: Development Environment Tools It should be noted that while newer versions of these tools are available no testing was done using them.06 0.K.14 1.pdf : K. at this stage it is unknown how the existing code base will behave in an upgraded 224 .2 Note on Development Environment Various technologies were used in the process of validating the ideas presented in this dissertation. This le contains the results of multiple regression tests. (a) results. Note on Development Environment 2.0.0_02ea 3.8g 3. As such.6. (b) (c) test-user-certs: This directory contains the pre-generated user proxy certicates.6. test-data: prototype.xls: etc). (b) results-mulitpleregression.8 Table K. 3. 4. Pearson's Product Moment Correlation Coecient calculations. This directory contains keystore/trustore les for the merchant and test-server-certs: the payment gateway application servers.9.0 6.5 2.3 1.g. Tool JDK Eclipse Europa Apache Tomcat Apache Axis2 Apache Ant Apache Maven OpenSSL Mozilla Firefox Version 1.xls: This thesis. averages. thesis.

folder contains a Each project pom. 225 . Additional Material environment.Appendix K.rdf le of the Firefox extension will be required to get it working on the newer version of the browser. It is expected that some changes maybe required to get the code working on the newer platform (e.xml le. Building the periodical payment framework from source requires Apache Maven. This le denes all library dependencies that each project requires for both compilation and execution.g. etc). changing maximum version inside install.