References


References

  1. EMVCo, EMV 2000 Integrated Circuit Card Specification for Payment Systems, BOOK 3 ”Application Specification , Version 4.0, December 2000, http://www.emvco.com/specifications.cfm.

  2. K. Boehle, "CashWorld 2001: Some Impressions and Lessons on the Future of Internet Payments", Internet draft, http://epso.jrc.ec.

  3. Garfinkel, S., and G. Spafford, Web Security, Privacy & Commerce , Second Edition, Sebastopol: O'Reilly & Associates, 2001.

  4. Boyan, J., "The Anonymizer ”Protecting User Privacy on the Web", in CMC Magazine , September 1997, http://www.december.com/cmc/mag/1997/sep/boyan.html.

  5. VeriSign, "Securing Your Web Site for Business", http://www.verisign.com/products/site/index.html.

  6. MasterCard, "A White Paper: Using EMV for Remote Authentication", http://www.mastercardintl.com/newtechnology/smartcards/emv/RA_Entire_Manual.pdf.

  7. ISO 7498-1, "Information Processing ”Open Systems Interconnection ”Basic Reference Model ”Part 1: The Basic Model", 1994.

  8. Fummy, W., "Internet Security Protocols", in B. Preneel and V. Rijmen (eds.), State of the Art in Applied Cryptography , Berlin, Germany: Springer LNCS 1528, 1998, pp. 186 “208

  9. Atkinson, R., Security Architecture for the Internet Protocol , Request for Comments (RFC) 1825 (PS), August 1995.

  10. Atkinson, R., IP Authentication Header , Request for Comments (RFC) 1826 (PS), August 1995.

  11. Atkinson, R., IP Encapsulating Security Payload (ESP) , Request for Comments (RFC) 1827 (PS), August 1995.

  12. O'Mahony, V., M. Pierce, and H. Tewari, Electronic Payment Systems for E-commerce , Second Edition, Norwood, MA: Artech House, 2001.

  13. SETCo, "SET Secure Electronic Transaction 1.0 Specification ”The Business Description", May 1997, http://www.setco.org/set_specifications.html.

  14. SETCo, "SET Secure Electronic Transaction 1.0 Specification ”The Programmer's Guide", May 1997, http://www.setco.org/set_specifications.html.

  15. SETCo, "SET Secure Electronic Transaction 1.0 Specification ”The Formal Protocol Definition", May 1997, http://www.setco.org/set_specifications.html.

  16. IBM Research, "iKP ”A Family of Secure Electronic Payment Protocols", in The First USENIX Workshop on Electronic Commerce , New York, 1995.

  17. Freier, A. O., P. Karlton, and P. C. Kocher, The SSL 3.0 Protocol , Internet-Draft, November 1996.

  18. Dierks, T., and C. Allen, The TLS Protocol ”Version 1.0 , Internet-Draft, November 1997.

  19. SETCo, "External Interface Guide to SET Secure E-Commerce", http://www.setco.org/download.html.

  20. Visa, "Visa Authenticated Payment Program, 3-D Secure TM ", http://www.international.visa.com/fb/paytech/secure/main.jsp.

  21. MasterCard, "Secure Payment Application (SPA TM )", http://www.mastercardintl.com/newtechnology/ecommercesecurity/spa/.

  22. Visa EU E-Commerce, "3-D SET", http://www-s2.visa.com/pd/eu_shop/ merchants /faqs/main.html.

  23. SETCo, "The On-line PIN Extensions to SET Secure Electronic Transaction ¢ Version 1.0", http://www.setco.org/extensions.html.

  24. SETCo, "The Common Chip Extension to SET Secure Electronic Transaction ¢ Version 1.0", http://www.setco.org/extensions.html.



Appendix A: Security Framework

Overview

This appendix describes a possible security framework. It facilitates the qualitative understanding of security issues encountered in the analysis and design of electronic payment systems. This process is schematized in Figure A.1.

click to expand
Figure A.1: Definition of a security framework.

A top-down approach can be used in the description of this security framework, following the steps listed below.

Step 1: Interface decomposition Each electronic payment system is composed of a number of interfaces, with each interface opposing two parties. Generally, the main interfaces are cardholder-merchant, merchant-acquirer, acquirer-card association, card association-issuer, and issuer-cardholder. Depending on the particular features of each payment system, other interfaces could be identified.

Step 2: Threat analysis On each identified interface, the two parties have established a business relationship, which determines a set of transactions to be performed between them. For the completion of each transaction, messages are exchanged from one party to another according to a well-established protocol. The threat analysis identifies the consequences of possible protocol deviations on the business interests of each party. The parties participating in the protocol are first concerned about the threats generated by third parties, which are not eligible to participate in the protocol. If the two parties are mutually distrustful, they have to protect themselves from threats arising due to the misbehavior of each party during the participation in the protocol. Appendix B defines some of the security threats that can be identified in any interface between two communicating parties.

Step 3: Security services Each threat can be countered by a security service, which is a generic solution towards reducing or eliminating the impact of a threat on the business interests of the parties. The definition of the security requirements is the second step in the construction of the security framework, mapping security services to threats. Appendix C describes the security services that can counter the identified threats: confidentiality, entity authentication, data origin authentication and integrity, timeliness, and non- repudiation .

Step 4: Security mechanisms Each security service is implemented through an adequate security mechanism. The attribute adequate refers to the tradeoff between providing the required level of security and the cost of implementing the corresponding security mechanism. This means that the choice of a security mechanism is biased by economical considerations: the level of strength of the security mechanism must be in accordance with the value of the assets to be protected by parties. Risk management is the process of selecting the security mechanism in a cost-effective way.

The main security mechanisms used in the design of the protocols underlying payment systems' functionality are described in Appendix D, including symmetric and asymmetric enciphering , cryptographic hash functions, digital signatures, public key certificates, cardholder verification mechanisms, static and DDA mechanisms.

Step 5: Cryptographic primitives A security mechanism can be implemented with one or several cryptographic primitives. The choice of one cryptographic primitive or another is also determined by a trade-off, this time between the level of strength of the primitive against known classes of attacks and the costs determined by the implementation of the primitive. These costs are related to key management as well as software and hardware platforms needed to implement the primitive. In many cases, the choice of a cryptographic primitive is strongly influenced by subjective factors, among which are export regulations dictated by national security reasons, claimed intellectual rights protected by patents, and protectionist measures.

Appendix E is dedicated to block ciphers, their operating modes, and the main representatives. Appendix F presents a tutorial on the RSA public key encryption system and the RSA digital signature scheme. The interested reader can find more information on cryptographic primitives in [1].