aipp: a fast-complied e-payment protocol

3 downloads 0 Views 530KB Size Report
Netscape Communication Corporation. ... MasterCard and Visa Corporation, 1997. Secure ... NACHA (National Automated Clearing House Association). Internet ...

ISBN: 972-8924-09-7 © 2006 IADIS

AIPP: A FAST-COMPLIED E-PAYMENT PROTOCOL Salvatore Garruzzo DIMET, Università Mediterranea di Reggio Calabria Località Feo di Vito, 89060 Reggio Calabria, Italy

Giuseppe M.L. Sarnè DIMET, Università Mediterranea di Reggio Calabria Località Feo di Vito, 89060 Reggio Calabria, Italy

Luigi Palopoli DEIS, Università della Calabria Via Pietro Bucci, 87036 Rende (CS), Italy

ABSTRACT The E-Commerce development requires new generations of payment means able to solve the issues introduced by the presence of network-based activities. In this paper a payment protocol, called AIPP, complying with the FAST project and employed together with single-use account identifiers, is presented. The main aims of AIPP are to realize a safe and well accepted payment mechanism, in order to reinforce the confidence between customers and merchants and to avoid the exchange of sensible information. Some results obtained using a prototypal implementation of AIPP are presented. KEYWORDS

E-Commerce, FAST, Agent, XML.

1. INTRODUCTION The E-Commerce (EC) is a great Web opportunity (He et al, 2003), mainly for: the absence of time and space boundaries; simple and fast market access; goods offers with low costs or without fixed price; more sale terms. Conversely, its main weakness are the customer-merchant distrust and the acceptance of existing epayments (for a real or perceived unsatisfactory security and their complexity, expensively, lack diffusion and often absence of anonymity and purchases privacy). To solve these issues, absent in traditional scenarios (Asokan et al, 1997), (Pinheiro, 2004), many e-payment systems have been proposed where: actors identities are authenticated and validated; payments and their effects guaranteed; operations, frauds and legal risks minimized. Usual systems are cryptographic techniques (O’Mahony et al, 2001), third parties as trusted authenticators, Financial Institutions (FIs) to assure fund availability and their transfer (Pinheiro, 2004). In our context the payment schemes of interest belong to three categories: i) Credit card-based systems, e.g. First Virtual (Stein et al, 1994), i-KP (Bellare et al, 1995), SET (MasterCard and Visa Corporation, 1997), etc.; ii) Electronic cash payment systems, e.g. eCash, NetCash (Neumann and Medvinsky, 1995), etc.; iii) Electronic checks and account transfers, e.g. electronic check project (FSTC), ISAP project (NACHA), NetBill, NetCheque (Neumann and Medvinsky, 1995), FAST project (FSTC, 2000), etc. Actually, credit cards are the most used e-payment system, but the transfer of their data to the merchant to be stored there could be risky without the use of a sure protocol as SET, weakly accepted for its heavy, or SSL connections (Freier et al) for the only transfer risk. The electronic cash systems cannot be used for law and crime prevention regulation/legislation (Asokan et al, 1997). The latter schemes are popular for their aptitude to integrate usual financial instruments in a secure Internet transaction context and can be realized either completely in secure software or in secure hardware.

406

IADIS International Conference Applied Computing 2006

In this scenario, existing FIs, to avoid profits erosion by new competitors, have promoted innovative business models as the Financial Agents Secure Transaction (FAST) project (FSTC, 2000), that exploits the agent technologies (AT). Note that in the EC, the AT role is significant, as proved by the significant number of models, architectures and surveys present in the literature (Guttman et al, 1998), (He et al, 2003), (Jennings and Wolridge, 1995), (Liu and Ye, 2003), (Ye et al, 2001). In this paper it is proposed a safe and potentially well acceptable e-payment protocol, called AIPP (Agent Internet Payment Protocol), FAST complied that adopts standard protocols, existing services and single-use account identifiers (Shamir, 2002). In this way, the business actors, with no common authentication mechanism, can be authenticated, agreements and their effects guaranteed and financial privacy and confidentiality preserved. The paper is organized as follows: in Section 2 describes the FAST project and the AIPP protocol; in Section 3 the performance of an AIPP prototype are shown, discussed and some conclusions reported.

2. FAST PROJECT AND AIPP PROTOCOL The FAST team has developed five FIs centric payment schemes for different scenarios (without specifying any detailed protocol) (FSTC, 2000) based on user's accounts located into FIs and agent technologies to take advantage from existing infrastructures. The main benefits are: i) customers (Cs) and merchant (Ms) accessing to their on-line accounts, with usual procedures, are authenticated by their FIs (FAST is not an authentication model and does not explicitly require cryptographic techniques); ii) Payments occur only via FIs to guarantee funds availability, transfer and effects; iii) Interoperability among accounts located in different FIs as banks it is easy, differently it can be difficult; iv) Payments are carried out by agents to replace Cs and Ms in most uninteresting and/or complex tasks. The problems of the security of FIs’ communication, as those of viruses or hackers attacks defense are beyond FAST project objectives. The AIPP protocol employs the FAST “pre-negotiation” scheme (FSTC, 2000) involving a customer, a merchant, their trusted FIC and FIM, and their agents c, fiC, m and fiM. Communications occur only asynchronously between agents (c-m, c-fiC, fiC-fiM and fiM-m), without multiple Internet connections (other connected parties are only external risk factors), exchanging a low amount of information. Agents are XML (eXtensible Markup Language) (W3C, 2004) based to overcome several heterogeneity problems (platforms, languages, applications and communication modalities) and to transfer business information in a consistent way. The FI typologies are limited to banks, card issuers or relevant FIs, where payers and payees have an on-line access to their accounts. The native FAST safety is increased by funds transfer over interbanking networks, single-use account identifiers (for financial privacy), a nonce (i.e. an agent sender marker) and, for each agent communication, a Time To Live (TTL), as message deadline, and limiting to manage sensible information on-line. Furthermore, to promote Cs and Ms trust, AIPP allows to the FIs to be third parties in the transaction respecting user's privacy. Before proceeding with describing the protocol, the used message notation and their data contents are illustrated. Note that the subscripts identify sender and addressee while data is an XML document, whose content depends on the specific action being carried out (see Table 1). As previously specified, the AIPP agents are XML based to overcome several heterogeneity problems and to transfer business information in a consistent way. In such field, a new generation of specifications XML-based has been developed (they are flexible, cheap and easy to implement and maintain (Chaib-Draa and Dignum, 2002)), but liking other areas specific agreements must be established on the tag semantic. Actually, more XML specifications exist without any shared standard (see (Hassembling and Welgand, 2001) for a more complete list). More in detail: • REQ_INVc,m(data): it requires an invoice for a good offered by M; • INVm,c(data): it contains the invoice required with REQ_INVc,m(data); • POc,m(data): it is the purchase order w.r.t. INVm,c(data); • PEx,y(data) (resp., PAx,y(data)): it notifies the payment execution (resp., abort) w.r.t. POc,m(data); • MTO c, fi (data): it is an irrevocable money transfer order w.r.t. INVm,c(data); C



A_MTO c, fi (data) (resp., R_MTO c, fi (data)): it notifies the MTO acceptance (resp., rejection) w.r.t. MTO c, fi ( data); ACT_CODx,y(data): it contains the MTO activation code w.r.t. INVm,c(data); NEW_AIx,y(data): it contains a new single-use account identifier for the next purchase or sell. C

C

C

• •

407

ISBN: 972-8924-09-7 © 2006 IADIS

Table 1. Message content. Subscripts identify sender and addressee; superscript identifies the element origin Message Message content REQ_INVc,m {HS(ASIdc, NNCc, TTLc), PS(GIdM, TC, B, MSN, VADSet), CS(Cr, UM, CUc), DS(DIdM)} INVm,c {HS(ASIdm, NNCm, TTLm, GIIdm), PS(GIdM, TC, B, MSN, VADSet), CS(Cr, UM, CUc, Prc, Txc), DS(DIdM, DCc), FS(FIIdM, FIAdM, FIAIM)} POc,m {HS(ASIdc, NNCc, TTLc, GIIdm), FS(FIIdC, FIAdC, FIAIC)} PEx,y {HS(ASIdx, NNCx, TTLx, GIIdm), FS(MTOIdC)} PAx,y {HS(ASIdx, NNCx, TTLx, GIIdm), FS(FIIdM, FIAdM, FIAIM, H(INVm,c))} {HS(ASIdc, NNCc, TTLc, GIIdm), FS(MTOIdC)} MTO c, fi {HS(ASIdc, NNCc, TTLc, GIIdm), FS(MTOIdC)} A_MTO c, fi {HS(ASIdc, NNCc, TTLc, GIIdm), FS(MTOIdC)} R_MTO c, fi ACT_CODx, {HS(ASIdx, NNCx, TTLx, GIIdm), FS(MTOIdC, H(INVm,c))} NEW_AIx,y {HS(ASIdx, NNCx, TTLx), FS(FIAIx)} C

C

C

A data XML document is structured in five sections and more in detail: • HS, the Header Section denoted by a tuple encoding the Agent Sender Identifier, Nonce, Time To Live and Good Invoice Identifier (assigned by m). • PS, the Product Section denoted by a tuple encoding the Good Identifier (assigned by M), Typology Code (a NAICS code, see below), Brand (of the good), Model Serial Number (a manufactory identifier) and Value Added Data Set (a set, possibly empty, of benefits, e.g., Extended Warranty Time, Extensive Service, Special Gift, Coupon, etc.). • CS, the Commercial Section, denoted by the tuple encoding the Currency, Unit of Measurement, Commercial Unit of goods, Price and Tax. • DS, the Delivery Section, denoted by the tuple encoding the Delivery Identifier (assigned by M), Delivery Cost and Address (i.e., the personal or the Internet address data). • FS, the Financial Section, denoted by a tuple encoding the Financial Institution Identifier, Financial Institution Internet Address, Financial Institution (single-use) Account Identifier, Money Order Transfer Identifier and Hash (that is a one way hash operation on INVm,c(data), e.g., exploiting the MD5 or SHA algorithm). The NAICS (North America Industry Classification), introduced above, classifies hierarchically the businesses for industrial sectors. In AIPP, is used the 6 digits NAICS code; it is also the Agent Ontology Domain common to all the agents that can employ the only portion needed to support user interests. Now all AIPP steps can be described w.r.t. a good g ∈ M and when all purchase details are known. Note that each reply message must arrive within a TTL time for to be valid. More specifically: 1. The payment process starts when C sends a REQ_INVc,m to m via c to purchase a g ∈ M. 2. m replies to c with INVm,c. 3. If INVm,c is valid, c logs into FIC, authenticating C, and then: 3.a) c sends to fiC an MTO c, fi C and an ACT_COD c, fi C of INVm,c (this latter must be provided by m to fiC via fiM to guarantee M authentication and all purchase effects respecting customer's privacy). 3.b) If there are sufficient C funds the MTO is accepted and fiC sends to c an A_MTO fi C , c as a notification and a NEW_AI fi C , c with a new single use account identifier for the next purchase; otherwise fiC aborts the payment process and notifies it to c with a R_MTO fi C , c . The ci—fiC session ends. 4. If A_MTO fi C , c is valid then c sends the POc,m to m. 5. If POc,m is valid, m logs into FIM, authenticating M, and then: 5.a) m sends to fiC via fiM the ACT_COD m, fi M of INVm,c. 5.b) fiM replies to m with NEW_AI fi M , m , a new single use account identifier for the next sell. The m—FIM session ends. 6. fiM transmits to fiC the ACT_COD fi M , fi C . 7. If ACT_COD fi M , fi C is valid and it is the same as that provided by c, then: 7.a) fiC effects the c's MTO to M via fiM; 7.b) fiC sends to c a PE fi C , c . Otherwise: 7.a) fiC aborts the payment process and sends to c a PA fi C , c .

408

IADIS International Conference Applied Computing 2006

8.

If the money has been transferred from fiC to fiM and accepted, then: 8.a) fiM notifies it to m with PE fi M , m and M can deliver the purchased good. Otherwise: 8.a) fiM returns the money to C via fiC (this occurs if the payment is not accepted by m); 8.b) fiM sends the PA fi M , m to m; C) fiC sends a R_MTO fi C , c to c.

3. EXPERIMENTS AND CONCLUSION A Java prototype of the AIPP framework, complying FIPA (Foundation for Intelligent Physical Agents), has been developed using the JADE platform (Bellifemine et al, 2001) to test its effective capability to perform epayments. In particular, AIPP has been completely implemented as a behaviour class added to each AIPP agent. Agent communications exploit the Agent Communication Markup Language (ACML) (Grosof and Labrou, 2000) (the XML version of the FIPA-ACL), that offers some significant advantages among which: i) The XML encoding allows us to use existing XML parsers for ACL messages; ii) Agents are easily enrichble with a large variety of features, i.e. SSL; iii) The XML allows to incorporate links into ACL messages. In the following, a small B2C scenario is illustrated. The simulation was realized by employing an entry-level single CPU (CPU: Intel Pentium 4 “Prescott” 3 GHz; RAM 2Gbyte; OS: Linux) “merchant” server. A rough estimate of the AIPP computational efficiency have been simulated with single and continue sequences of payment processes. From such tests it results that, on the C side, AIPP has a low impact on the computational performance running only one payment at a time. On the contrary, the merchant's agent is able to satisfy a large volume of concurrent payment processes and referred to different customer agents. Further, AIPP performances are influenced by: i) computational resource of the M's server absorbed by other concurrent applications; ii) the Internet load influences. The first one has been taken into account in the tests by simulating some different application loads as percentage of CPU load, whereas the network load has been simulated by setting some delays in the communications (tests were carried out on a 100 Mb LAN). Figure 1a shows the seconds spent by the M's server to complete a sequence of 1000 payment transactions for different applications and network loading, while, in Figure 1b, the incidence for single step of a single payment transaction (without any CPU load and network delay) is defined. Note that they have only an indicative meaning both for the initial scenario assumption and the compulsory rough simulation of the interactions among Cs and Ms with their respective FIs. Concluding, in this paper AIPP has been described, a FAST complying payment protocol able to realize a secure centralized payment scheme over the Internet, based on existing FIs and single-use account identifier, where payments occur only among FIs by preserving financial anonymity, confidentiality and benefiting of an existing authentication mechanism. Furthermore, some results of experimental simulations, carried out using a JADE-based prototypal implementation, have been shown. We think that AIPP can realize flexible payment processes, which might meet higher acceptance and trust than other schemes. In AIPP the users have not to change habits or employ heavy and complex security protocol but, however, the security is not lower than that obtained by each user from their own FIs. In a wider future perspective, the AIPP agents support could be exploited with other EC activities, as those described by behavioural models, i.e., the Consumer Buyer Behavioural (CBB) model (Guttman et al, 1998).

Figure 1. The AIPP prototype performance

409

ISBN: 972-8924-09-7 © 2006 IADIS

REFERENCES Asokan N. et al, 1997. The State of the Art in Electronic Payment Systems. IEEE Computer Magazine, Vol. 30, No. 9, pp. 28-35. Bellare M. et al, 1995. iKP – A Family of Secure Payment Protocols. Proceedings of the First USENIX Workshop on Electronic Commerce. New York, USA, pp. 89-106. Bellifemine F. et al, 2001. Developing Multi-Agent Systems with a FIPA-compliant Agent Framework. Software— Practice and Experience, Vol. 31, No. 2, pp. 103-128. Chaib-Draa B. and Dignum F., 2002. Trends In Agent Communication Language. Computational Intelligence, Vol. 18, No. 2, pp. 89-101. eCash Technologies Incorporated. Available from http://www.ecash.net/, February 3, 2005. Foundation for Intelligent Physical Agents (FIPA). FIPA ACL Message Structure Specification. Available from http://www.fipa.org/specs/fipa00061/, February 3, 2005. Freier A.O. et al. The SSL Protocol version 3. Netscape Communication Corporation. Available from http://wp.netscape.com/eng/ssl3/ssl-toc.html, February 3, 2005. FSTC, 2000 (Financial Services Technology Consortium). Financial Agent Secure Transaction (FAST), Phase 1 Final Report (White Paper). Available from http://www.fstc.org/projects/fast/phase1/fastdocs1.cfm, February 3, 2005. FSTC (Financial Services Technology Consortium). Electronic Check Project. Available from http://www.echeck.org/, February 3, 2005. Grosof B. and Labrou Y., 2000. An Approach to using XML and a Rule-based Content Language with an Agent Communication Language. Issues in Agent Communication. Lecture Notes in Computer Science, Springer-Verlag, Vol. 1916, pp. 96-117. Guttman R.H. et al, 1998. Agent-Mediated Electronic Commerce: A Survey. The Knowledge Engineering Review, Vol. 13, No. 2, pp. 147-159. Hassembling W. and Welgand H., 2001. Languages for Electronic Business Communication: State of the Art. Industrial Management & Data System, Vol. 102, No. 5, pp. 217-226. He M. et al, 2003. On Agent-mediated Electronic Commerce. IEEE Transaction on Knowledge and Data Engineering, Vol. 15, No. 4, pp. 985-1003. Java Agent DEvelopment (JADE). http://jade.tilab.com/, February 3, 2005. Jennings N.R. and Wolridge M.J., 1995. Applying Agent Technology. International Journal of Applied Artificial Intelligence, Vol. 9, No. 4, pp. 351-361. Liu J. and Ye Y., 2003. Introduction to E-Commerce Agents: Marketplace Solutions. Security Issues, and Supply and Demand. Proceedings of the E-Commerce Agents: Marketplace Solutions, Security Issues, and Supply and Demand. Lecture Notes in Computer Science, Springer-Verlag, Vol. 2033, pp. 1-9. MasterCard and Visa Corporation, 1997. Secure Electronic Transaction (SET), Specification–Books 1, 2 and 3. Available from http://www.dice.ucl.ac.be/crypto/standards/SET/set_bk1.pdf or set_bk2.pdf or set_bk3.pdf, February 3, 2005. NACHA (National Automated Clearing House Association). Internet Secure ATM Payments (ISAP). Available from http://internetcouncil.nacha.org/Projects/previous_projects.html, February 3, 2005. NetBill. Available from http://www.ini.cmu.edu/netbill/index.html, February 3, 2005. Neumann B.C. and Medvinsky G., 1995. Netcheque, Netcash and the Characteristics of the Internet Payment Services. Proceedings of MIT Workshop on Internet Economics, Massachusetts. North America Industry Classifications (NAICS). Available from http://www.naics.com/, February 3, 2005. O’Mahony D. et al, 2001. Electronic Payment Systems for E-Commerce, 2nd ed. Artech House, Norwood, MA, USA. Pinheiro R., 2004. Preventing Identity Theft Using Trusted Authenticators. Journal of Economic Crime Management, Vol. 2, No. 1. Available from http://www.jecm.org/archives/04_vol2_issue1_art2.pdf, February 3, 2005. Shamir A., 2002. SecureClick: A Web Payment System with Disposable Credit Card Numbers. Proceedings of the 5th International Conference on Financial Cryptography. Lecture Notes in Computer Science, Springer-Verlag, Vol. 2339, pp. 232-242. Stein L.H. et al, 1994. The Green Commerce Model. Technical report. First Virtual Holding Incorporated. Available from http://citeseer.ist.psu.edu/stein95green.html, February 3, 2005. W3C, 2004. Extensible Markup Language (XML) 1.1. Available from http://www.w3.org/TR/2004/REC-xml1120040204/, February 3, 2005. Ye Y. et al, 2001. Agents in Electronic Commerce. Electronic Commerce Research, Special Issue on Agents in Electronic Commerce. Kluwer Academic Publishers, Vol. 1, No. (1-2), pp. 9-14.

410