Security For Electronic Commerce / IS&T 5149 Marc Pasquet GREYC Laboratory (ENSICAEN – Université Caen Basse Normandie - CNRS) 6 boulevard Maréchal Juin 14000 CAEN - FRANCE
[email protected] (+33) 231538152 (+33) 231538110 Christophe Rosenberger * GREYC Laboratory (ENSICAEN – Université Caen Basse Normandie - CNRS) 6 boulevard Maréchal Juin 14000 CAEN - FRANCE
[email protected] (+33) 231538135 (+33) 231538110 Félix Cuozzo ENSICAEN 6 boulevard Maréchal Juin 14000 CAEN - FRANCE
[email protected] (+33) 231538107 (+33) 231538110
Security For Electronic Commerce I N T R O D U C T I O N E-commerce permits a dematerialized financial transaction between a customer and a merchant (Schafer et al., 2001). It uses a complex architecture involving many aspects in computer science (security, database management) and in electronics (smartcards, tokens) (Tang et al., 2004). E-commerce is in a constant growth (Herrmann & Herrmann, 2004). To be used by the majority of individuals, electronic transactions must be secured to increase the confidence in the e-commerce. Security is necessary in commercial relationships for many reasons. First, the customer must be sure that the goods he is buying will be the expected ones and will be well delivered at his address. Second, the merchant must be sure to be paid. If the customer uses banknotes or electronic payment, two or more partners are involved in that transaction: the customer’s bank and the merchant’s one. The two banks must be sure of the customer’s identity and of the merchant’s one in order to avoid banking frauds. In the transaction process, many security systems are used to ensure the confidentiality, authentication and integrity of exchanges. The security is guaranteed by using specific procedures and hardware. The objective of this chapter is to present how the classical security concepts are applied for an electronic payment and especially to limit the fraud. The background section first gives a general idea of the problem generated by the electronic commerce. Second, we present briefly the Public Key Infrastructure approach that is generally used for authentication within this context. The main trust introduces two protocols that have been developed: SSL (Secure Sockets Layer) and TLS (Transport Layer Security), to create a secure channel where all transactions are encrypted by using specific architectures and algorithms. For the payment part of the transaction process, banks have been considered that SSL and TLS are not sufficiently secure. The main reason is that the cardholder is not authenticated by the issuer bank and the responsibility stays on the merchant side. Banks have so tried to implement different architectures to meet these requirements. These different methods: use of token with SET (Secure Electronic Transaction) or a smartcard such as C-SET developed in the last fifteen years, began to converge to the 3D-secure (Three Domains Security) protocol. These methods to secure the distant payment was adopted together by the card scheme Visa© and MasterCard©. The last, but not the least problem, concerns the distant authentication of the client by its bank that is described in the future trends.
B A C K G R O U N D
We first make a brief description of the e-commerce issues. 1- E-commerce description In order to better understand how the e-commerce works, Figure 1 shows the different partners and the different exchanges between them. A financial transaction between a customer and a merchant is in fact a transaction between the issuer and the acquirer banks. The payment is achieved through many authorization requests (customer authentication, bank transfer authorization) involving many security and cryptographic concepts.
Figure 1: The different partners and flux in e -commerce payment
In order to help the e-commerce development, some good practices are necessary to be applied: The risk control. The risk is partly taken by: o The merchant to not finally been paid; o The consumer to not receive the goods or the services; o The consumer bank in case of a systemic attack. This risk assumed by these different partners must be as low as possible. The risk is as much loss of confidence in the system, as waste of money.
The facility of use for the consumer. The reference model is the face to face commerce and an ideal solution for the e-commerce must not create more constraints;
The use of international standards. In one hand, Internet protocol is the base for e-commerce and in the other hand, the banking payment systems with chip or/and stripe cards, should also be used for e-payments;
The deployment of the different measures with a communication between banks and merchants. The constraints and the added value must be studied with a great attention. If one of the four partners of the transaction (the customer and his bank and the merchant and his bank) is not interested in one architecture implementation, the system will have much more difficulties to be developed.
As conclusion, it is necessary to: Well balance the responsibilities between the four partners; Adapt the security level to the risk level; Integrate the legal constraints. 2- The security problematic Additionally, in order to help the electronic commerce development, banks have to implement different solutions (Furnell & Karweni, 2000):
Visual cryptogram: To improve the identification process, the EMV (Eurocard MasterCard Visa) cards include one the back a three figures code, call CVX2, that the consumer must give to complete a payment transaction;
Authorization: More than 7% of authorizations come from the e-commerce and that part increases every year;
Individual supervision of frauds: Coming from consumers or merchants;
PKI (Public Key Infrastructure) for data protection: To create the better possible protection for the different exchanges between all the transaction partners;
Authentication services: To avoid the risk at the consumer level (CAP (Chip Authentication Program ©MasterCard), SET, 3D-secure).
3- The Public Key Infrastructure A Public Key Infrastructure (PKI) includes a set of physical components (computers, cryptographic algorithms and equipments, smartcards), human procedures (verifications, validations) and software (systems and applications) to manage the life cycle of electronic keys or certificate. A certificate can be considered as proof of the existing relation between the identity of a customer or merchant and a public key. The major element is the Certifying Authority (CA) which signs the certificate, the Registration authority (RA) which creates the pairs of Keys and the Repository which stores the certificates. Figure 2 shows the different transactions in a PKI infrastructure (Chanson & Cheung, 2002). There exist many certifying authorities (EuroPKI, E-certify Corporation, ID.Safe, Identrus, E-Commerce PKI CA, SwisSsign…).
Figure 2: The different parts of the PKI
A Public Key Infrastructure delivers a set of services for its users (Critchlow & Zhang, 2004). The main services are: Users recording (or computers); Users identification and authentication; Pairs of keys generation (an encrypted message with a public key can be decrypted only with the corresponding private key); Public key certification; Certificate management (generation, renewal, revocation, publication, storage). A PKI generates electronic certificates used for cryptographic operations such as encryption and electronic signatures which offer some security guaranties for etransactions such as: Confidentiality: Only the legitimate addressee of a message can read this message; Authentication: When a message is sent, the sender identity is perfectly known; Integrity: It is possible to know if a message has been deteriorated or falsified; Non- repudiation: The message sender cannot deny he sent it.
M A I N
T R U S T
We focus in this part on existing solutions to secure e-payment. 1- SSL and TLS The SSL security transaction process in HTTPS (Hyper Text Transfer Protocol Secured) communication is detailed in Figure 3 (Nabi, 2005; Guitart et al., 2007).
Figure 3: Security process. A= merchant site, B= customer PC
The Pair of keys (public and private) has been received from one of the PKI Registration Authority. The security process continues by using the secret key AB (see Figure 4) all along the transaction. When the customer is ready to pay, he clicks on the corresponding option and one form asks him to give his card number, the expiration date and the CVX2 writes on the back of the card. The merchant sends an authorization request to his bank and waits for an authorization response to conclude the transaction. The SSL is limited for a payment use: Vulnerability to attack when keys less than 128 bits are used; The customer identification is not always done; SSL is not well protected in case of man in the middle attack. The attacker is able to receive the totality of presumably protected flow.
Figure 4: The different flux in SSL payment Very similar to the protocol SSL version 2, the TLS (Transport Layer Security) protocol is promoted by Microsoft on its Windows browsers for the HTTPS communication. Only few differences can be pointed (Kwon et al., 2001): Encryption with the AES (Advanced Encryption Standard) algorithm (256 bits key) instead of the DES (Data Encryption System) algorithm; More rigorous in the certificates use and less vulnerable to the man in the middle attack. 2- Trusted partner and electronic purse To protect the customer during the transaction, another solution is possible: use of a trusted partner that stores your banking information, debit your account and pays for you without giving any information about your smartcard or your account to the merchant (Hawk, 2004). There are many methods like Digicash or PayPal that provide a digital cash implementation (see Figure 5). However, the limits of that type of payments are very quickly reached: You must be registered to the right trusted partner accepted by the merchant or having several trusted partners to pay freely on the Web.
Figure 5: The different flux in PayPal payment
The electronic purse is a similar solution: It is a preloaded account evaluated in monetary units stored in the system of cashing of a non banking operator; The access to this electronic purse is done using one software installed on the customer’s PC to pay online. 4- SET To limit the risk that the customer can repudiate his payment transaction, a set of companies (Visa, MasterCard, GTE, IBM, Microsoft, Netscape, SAIC, Terisa system, Verisign) have developed, in the eighties one solution called SET (Secure Electronic Transaction). The customer’s bank sends him a certificate issued from one CA of a PKI which is stored on his computer. When he wants to make a payment on the Web, the customer must sign with the PKI keys as shown in Figure 6 (Rennhard et al., 2004).
Figure 6: The different flux in SET payment
SET has not been deployed so much but was at the origin of C-SET then to 3D secure (Visa) and SPA UCAF (MasterCard) and finally to the 3D Secure generalization (Brlek et al., 2006). The idea developed by C-SET was to use banking smartcards and there certificates, through small card readers connected to the customer's computer, to secure the payment transactions. The price of that card reader working as a POS (point of sale) was a limit to the deployment of that solution. 5- 3D-secure The current solution to solve the problem of electronic payments, is 3D secure (3D– Secure Functional Specification, 2001) developed by VISA and used by MASTERCARD which has gave up from SPA UCAF.
3D Secure is not only an authentication method, it is a payment architecture on Internet, launched by Visa in 2001. The commercial trademarks are « Secure Code » for MasterCard and « Verified by Visa » for Visa. The term 3D is the contraction of “Three Domains”: Acquiring domain (bank acquirer and merchant); Issuer domain including the customer authentication; Interbank field which makes it possible the two other fields to communicate on Internet. 3D Secure describes the different processing between the three domains to carry out a payment by bank smartcards and distributes the responsibilities in a balanced way between these domains: The customer’s bank authenticates its client; The merchant’s bank authenticates its merchant; The interbank domain makes it possible the merchant to start the customer's authentication using services of directories (MasterCard or Visa). In the 3D-Secure authentication diagram, the first stage is the recording of the cardholder by his bank. Figure 7 presents the different communications for a transaction in the 3Dsecure architecture. The recording procedure contains a series of questions, after which, the cardholder chooses a password, for example, which will ensure his authentication by its bank for each transaction.
Figure 7: The different communications in 3D -secure payment
In 3D-secure, the security of transactions lay on the banks and not on the merchant. The merchant benefits from the same level of payment guaranty as in the face to face trade in card payment. More than that, there is a responsibility transfer from the customer towards the issuer (or “Liability Shift”). During the payment phase, the bank issuer becomes
responsible for the authentication of its cardholder as a preliminary step in the authorization request. However, the programs “Secure Codes” and “Verified by Visa” leave the bank issuer free to choose the authentication method of their cardholder. Those complex exchanges are transparent for the merchant and the customer and secure very well the e-commerce. The last problem is the customer authentication by his bank issuer. This will concern the future trends described in the next section of this short article.
F U T U R E
T R E N D S
We present in this part several issues concerning the perspectives of security in ecommerce. 1- Authentication In fact, with 3D-secure, the authentication problem from the customer / merchant domain is replaced by the customer / issuing bank domain. The problem seems easier to solve because there are a constant relationship between the cardholder and his bank (Torres et al., 2005). Many solutions have been proposed to meet this need for safety, some based on biometrics (Jain & Pankanti, 2006), others on the use of the couple reader - smartcard, allowing a dynamic authentication of the cyber-consumer. Whatever the chosen solution, the cost of the system of security is a key element, at the same time for the bank and the customer. For the bank, they are concretely the technical and organizational costs of integration, deployment, management and maintenance. On his side, the customer is interested by a simple tool of use at a moderate cost. It must represent a compromise between the security constraints and a convivial use of the tool of security of the bank-customer exchanges. Actually, bank payment chain uses mainly two types of proof together to create a strong authentication: A smartcard to identify the cardholder and so to authenticate the smartcard with the use of cryptographic keys and certificates ; A password to authenticate the cardholder. The MasterCard initiative CAP integrates this type of strong authentication. We present in the two next sections, two possible solutions that are explored in research works within this context. 2- Sopas Project Connected a simple terminal to the computer is realized in a project called SOPAS where we are involved in. This project consists in developing a card reader with just a keyboard with 12 keys and a screen with two lines of 10 characters. The card reader is connected to the cardholder's computer by the USB port. A set of development software is installed on the computer. When the smartcard is introduced in the card reader, the screen indicates to
type a PIN code. Then, the smartcard generates a token sent to the ACS as shown in Figure 8.
Figure 8: Sopas secured solution for authentication
To create a reader as simple as possible, it is necessary to use the new ISO 7816 specifications for cards which have an I2C bus and a USB bus at one’s disposal. All the certificates are calculated by the smartcard. The different protocols are indicated in Figure 9.
Figure 9: Protocols in SOPAS solution
3- Dynamic Tokens Another solution consists in using a smartcard reader unconnected which generates a dynamic token that the customer has to enter on the computer keyboard. It is enough for the smartcard holder to insert its card, which can be a debit/credit card, in a pocket EMV reader in conformity with the CAP standards, such as ActivReader Solo (TM) of ActivCard, and to compose its code PIN there. A dynamic on time-password is generated since the card and can be used to check or sign a transaction. This password or signature is then subjected to the bank through its Web site (or by telephone where it is confirmed by an operator) of authentication with an aim of checking the identity of the cardholder and the specific parameters of the transaction.
C O N C L U S I O N There are currently a great increase of the use of payment in the e-commerce because many of their needs tend to be satisfied. Under none circumstance, it is possible to create an absolute secured system, but new developments seem to be strong enough to protect correctly the e-commerce. The 3D-secure solution is now well implemented and will become a leader in the next few years for 3 main reasons: It is a method recommended by the card scheme Visa and MasterCard;
There is a responsibility transfer from the customer towards the issuer ( “Liability Shift”); Banks are free to choose the authentication method which is the visible part of the iceberg that is seen by the client of the bank and can allow the banks to create a differentiation from their concurrent.
The authentication part is in progress (Walton, 2005) but there are today none solution that can be considered as an emerging leader. The new authentication methods will be developed with three main principles: the solution must be secure, cheap and easy manipulate by an user. Today, many solutions are very secure but expensive, certain are complex for the cardholder and certain are not enough secure. Many research and development laboratory are working today one that problematic and we can expect some good solutions in a close future.
R E F E R E N C E S Brlek, S., Hamadou, S., & Mullins, J. (2006). A flaw in the electronic commerce protocol SET. Information Processing Letters, vol. 97, pp 104–108. Chang, K. I., Bowyer, K. W., & Flynn, P. J. (2005) An Evaluation of Multimodal 2D+3D Face Biometrics . IEEE Transactions on Pattern Analysis and Machine Intelligence, (4), vol. 27, pp. 619 -624. Chanson, S. T., & Cheung, T. -W. (2002). Design and Implementation of a PKI-Based End-to-End Secure Infrastructure for Mobile E -Commerce. World Wide Web archive, Kluwer Academic Publishers Hingham, MA, USA, vol. 4, pp. 235 253 Critchlow, D., & Zhang, N. (2004). Security enhanced accountable anonymous PKI certificates for mobile e-commerce. Computer Networks, vol. 45, pp. 483–503. Furnell, S.M., & Karweni, T. (2000 ). Security implications of Electronic Commerce: A Survey of Consumers and Businesses , Internet Research, vol. 9, no. 5 pp 372-382. Guitart, J., Carrera, D., Beltran, V., Torres, J., & Ayguade, E. (2007). Designing an overload control strategy for secure e-commerce applications. Computer Networks, vol. 51, pp 4492–4510. Hawk, S. (2004). A Comparison of B2C E-Commerce in Developing Countries. Electronic Commerce Research, vol. 4, pp 181–199. Herrmann, G., & Herrmann, P. (2004). Introduction: Security and Trust in Electronic Commerce. Electronic Commerce Research, vol. 4, pp 5–7 Jain, A.K., & Pankanti, S. (2006). A touch of money [biometric authentication systems]. IEEE Spectrum magazine, vol. 43. pp. 22-27.
Kwon, E.-K., Cho, Y.-G., & Chae, K.-J. (2001). Security Enhancement on Mobile Commerce. Lecture Notes In Computer Science, Springer -Verlag, vol. 2105 , pp. 164 – 176. Nabi, F. (2005). Secure business application logic for e -commerce systems. Computers & Security, vol. 24, pp 208-217. Rennhard, M., Rafaeli, S., Mathy, L., Plattner, B., & Hutchison, D. (2004) Towards Pseudonymous e-Commerce. Electronic Commerce Research, Springer, vol. 4, pp. 83-111. Schafer, J.B., Konstan, J.A., & Riedl, J. (2001). E-Commerce Recommendation Applications. Data Mining and Knowledge Discovery, vol. 5, pp 115–153. Tang, J.J., Waichee, F.A., & Veijalai, J. (2004). Supporting Dispute Handling in E-Commerce Transactions, a Framework and Related Methodologies . Electronic Commerce Research, vol. 4, pp 393–413. Torres, J., Izquierdo, A., Ribagorda1, A., & Alcaide, A. (2005). Secure Electronic Payments in Heterogeneous Networking: New Authentication Protocols Approach. Lecture Notes in Computer Science , vol. 3482, pp. 729 -738. Visa Corporation. (2001) 3D–Secure Functional Specification, Chip Card Specification v1.0. Walton, R. (2005). Identity infrastructure: security considerations . Computer Fraud & Security, pp 4-8.
Terms and Definitions EMV: Eurocard, MasterCard and Visa specifications define the electronic payment transaction and its security. CAP: Chip Authentication Program (©MasterCard), CAP provides one line chip-based cardholder authentication within the SecureCode™ (3D-secure) program. PKI: Public-Key Infrastructure. The use of cryptography with public key on large scale, creates the need to manage large lists of public keys, for entity often repartee on the network. The Public-Key Infrastructure manages that problem. CA: The Certifying Authority (CA) signs the certificates. RA: The Registration authority (RA) creates the pairs of Keys SET: Secure Electronic Transaction was a solution developed by a set of companies (Visa, MasterCard, GTE, IBM, Verisign...) to limit the risk that the customer can repudiate an e-commerce electronic payment transaction.
3D-SECURE: The current solution to solve the problem of e-commerce electronic payments, 3D-secure is used by VISA and by MASTERCARD.
