A Scheme for Analyzing Electronic Payment Systems

Transcription

1 A Scheme for Analyzing Electronic Payment Systems Lucas de Carvalho Ferreira IC/Unicamp and DEX/UFLA DEX, Campus da UFLA Lavras MG Brasil Ricardo Dahab IC/Unicamp Caixa Postal Campinas SP Brasil Abstract This paper presents a scheme for the design, analysis and comparison of electronic payment systems. Three systems are described in detail through this scheme. Keywords: payment systems, analysis and design of payment systems. 1 Introduction The field of electronic commerce and especially electronic payment systems has flourished in the past few years. The possibilities opened by the popularization of the Internet have forced many companies and research teams to turn their eyes to this new commercial universe. The first problem that has to be addressed before the Internet could become a huge marketplace is finding a way to securely transfer monetary value over the network. In recent years, many systems have been proposed and implemented that allow two parties to transfer monetary value on a network of computers. Some of these protocols had significant implications on the way people do commerce on the Internet and new protocols are being deployed that may have much stronger implications in the development of the electronic marketplace. With a number of payment systems available, people now need ways to analyze these systems and choose the one most suitable to their needs. Some work has been done in the direction of clarifying and classifying the way electronic payment systems work [2, 11, 7, 1, 3, 8]. Some of these works describe payment systems characteristics and their intrinsic requirements [2, 3, 7], while others classify payment systems by their functional behavior [8]. We believe a more integrated approach should be used to achieve a broader understanding of electronic payment systems. We will here extend previous work on the classification of electronic payment systems and build a functionality model for those systems. This model was based on the analysis and understanding of several designs of electronic payment systems and seems to be comprehensive enough to be used with most existing systems. We first present our proposed scheme for classifying and analyzing electronic payment systems; then we show how this scheme can be used to understand three important payment systems; a summary of the analysis of many known systems is shown in the tables of Appendix A. 2 Proposed Scheme In this section we present the scheme we built to analyze payment systems characteristics. Figure 1 presents the scheme and its four subparts, each serving a single purpose: (i) describe payment systems typification through common characteristics; (ii) present desirable requisites of payment systems; (iii) describe system functioning from the user s perspective; (iv) present implementation aspects of the system. The next subsections present each of these subparts in detail. 2.1 System Typification All electronic payment systems present characteristics that help us classify and understand the systems and their applications. We identified the following characteristics: Exchange Model Token-based. Here transactions are made by the exchange of tokens of predefined value, much like coins or bank notes. In these systems, users must buy tokens from a central authority before being able to start a payment transaction. Token-based systems are also called cash-like systems.

2 Typification Exchange Model Central Auth. Contact Amounts Hardware Available Roles Role Inversibility Privacy System Desir. Requisites Integrity Robustness Economic Viability Scalability Interoperability Auditability Divisibility Functioning Long Term Relationship Withdrawal Transaction - Authentication - Payment - Acknowledgement - Conclusion Settlement Implementation Cryptographic Primitives Network Connections Payment Order Format Payment Values Hardware Off-line. Systems of this type allow users to make transactions without contacting the system s central authority at the exact moment each transaction occurs. Some time in the near future, the payee must contact the central server to settle things up, but this contact may be delayed until the user believes it is appropriate. The payee must be able to verify payment validity without help. An example is project CAFE payment system. Micro-payments. Only very small values are involved, typically from US$ to a few dollars. Small to medium payments. These values may be transferred on the Internet with a good level of security, usually US$ 1.00 to US$ Big payments. Larger values (over US$ ) require greater security than the Internet can provide today. Figure 1. Four Aspects that Characterize Electronic Payment Systems Notational. Payment transactions in notational systems are done by the settlement of balances in accounts managed by the system s central authority. In this kind of system, users exchange documents which enable value transfers, such as payment orders, and define the value of each of these documents. Familiar examples of such systems are bank cheques. Notational systems are sometimes called credit/debit systems. Hybrid. Some systems make use of signed tokens that have their value specified by the user at the time of the transaction. Central Authority Contact On-line. The central authority must be contacted during each transaction, in order to bless all value transfers. These systems are usually built over the Internet and must cope with the (possibly high) cost of on-line network connections needed for each transaction. Examples are Internet based systems (E-cash, First Virtual, SET) and debit card based systems (Visa Electron, Carte Bleue). Specific. Systems need special hardware, like tamper-proof devices or smart cards. General purpose. Only common computers are needed. Systems may be implemented on any platform and do not require special hardware. Possible Roles Each party in the transaction must take one of the roles specified in the system. Usual roles are payers, payees (users) or banks. Role Inversibility Unchangeable roles. Each user has a predefined role such as buyer, seller or bank. To act in two different roles, users have to register at least twice, once for each role. Interchangeable roles. These systems allow users to assume different roles when convenient. Thus, they allow transferring values among users. However, in general, no system allows users to become the bank. PrivacyExistent. In this case, systems protect, to some extent, user s privacy, allowing anonymous purchases, secure transfer or protection of critical information. Some systems guarantee that critical information will be available only to those parties that need it.

3 Non-existent. Systems do not use cryptographic techniques to protect information transfers. External means must be used if necessary. Divisibility It must be possible to change a high valued token for smaller valued ones. Four divisibility levels are used to classify payment systems: 1. users are able to divide their own tokens, without necessarily engaging in a purchase/sale transaction. 2. the central authority may be contacted to make change online. 3. the payee may hand some change back. 4. there is no divisibility. It may be a notational system. 2.2 Desirable Requisites There are requisites that would be desirable in a general model of electronic payment systems. However, attention should be payed to the fact that in some contexts, some of these requisites could be unnecessary or undesired. Usually, only a subset of them is considered for a specific application. Integrity. The system must provide the means to detect or prevent unauthorized data modification. Robustness. The system should behave as expected under unforeseen circumstances, not allowing the loss of information or of currency, or enter an inconsistent state, should a problem occur. Robustness may be achieved through the use of ACID transactions [2]. Economic Viability. Cost of transactions must be compatible with the values transferred through the system. Scalability. A system must be able to cope with the addition of new users and with the increase of the quantity of money involved in its operation without a significant loss of performance. Interoperability. A system must make possible the exchange of money with other systems. For example, it must be possible to exchange a cheque for cash. Auditability. The system must provide auditing facilities so that errors or misuse may be detected. 2.3 System Functionality Description Electronic payment transactions consist of the following steps: Establishment of Long Term Relationship. Initially, a user makes contact with a financial institution responsible for managing the payment system and establishes a long term relationship with it. This financial institution is called a bank or controlling entity. The registration with the bank may involve opening an account, acquiring some piece of software or even initialization of authentication methods, such as public key generation and certification. Withdrawal. In this stage, a user obtains from the bank the monetary means necessary to engage in payment transactions. This is accomplished by transferring electronic coins, charging a smart card or issuing a credit certificate. Transaction. This is the main stage of any payment system, in which the transfer of values actually occurs. It typically involves four consecutive substeps: 1. Authentication. It may be necessary for the parties of a transaction to identify themselves, to ensure that each is an authorized user of the system. 2. Payment. The payer sends electronic money to the payee. 3. Acknowledgment. The payee may send the payer a receipt corresponding to the transaction. 4. Conclusion. If all parties agree on the outcome of the transaction, it can be ended without problems. If there is any disagreement, a dispute resolution protocol may be started. Settlement. The payee sends the electronic money to the bank to be converted into real money, or deposited into an account, or in some cases, the payee may choose to receive the value in electronic currency of the same kind or ask for it to be converted to another kind of electronic currency. 2.4 Implementation Aspects Some aspects of an electronic payment system are linked to its implementation, and are shown in the system specification. This section presents some important implementation aspects in the analysis of a payment system. Cryptography. Describes all cryptographic algorithms that are used in the system, specially: symmetric ciphers, asymmetric ciphers, digital signatures, certificates and ing. Network connections. Quantity and type of network connections needed by the system.

4 Token or payment order format. Shows the contents and organization of the tokens or payment orders used in the system. 3 Three systems in detail In this section, we use the scheme outlined above to get a better understanding of three popular electronic payment systems, that were chosen because they represent different kinds of payment systems and illustrate the benefits attained by the use of the scheme. 3.1 PayWord PayWord is a micro-payment system designed by R. Rivest and A. Shamir [10]. It is efficient for repeated payments to the same vendor, ni=h(ni?1);i1; and is designed to reduce the use of public-key algorithms through the use of functions and fast symmetric ciphers. The system is based upon the use of chains to represent monetary value. A chain is a sequence n0;n1;:::;nk, where his a strong cryptographic function andn0is a random number. The chain is used backwards, fromnkton0. Since hmust be hard to invert, it is computationally infeasible to obtainnifromni+1. To make a payment, the user must first generate a chain, signnk, and send it to the vendor. Then, each monetary unit spent corresponds to the valuexof the chain such thath(x)is the previously spent value, currently held by the vendor System Typification Exchange model: token based. Users have certificates that enable them to generate chains to be used as payment tokens. All chains are user-vendor specific. Central Authority Contact: off-line. The broker gives each user a certificate which enables generation of tokens. Brokers may sign certificates and redeem tokens off-line. Payment Values: micro-payments. The system avoids the use of asymmetric ciphers at the cost of lowering security, and is only adequate for payments under US$ Hardware: general purpose. The system is software based and makes no use of specialized hardware. Available Roles: buyer, vendor, broker. Brokers manage buyer accounts and emit certificates. Vendors must register with the brokers to be able to settle received tokens. Role Inversibility: unchangeable roles. The actions and relationships of a user are strongly dependent on the current role of that user. A user may register as vendor and buyer but only act as one of them at a particular transaction. Privacy: non-existent. PayWord does not provide privacy and the user must be identified in each payment. Data in transit is not protected. Divisibility: level 4. The system s design does not include divisibility but the designers suggest that chain values could be negotiated Desirable Requisites Integrity: partially guaranteed. Digital signatures are used to maintain certificate integrity. Tokens are not protected by integrity mechanisms. Robustness: no particular mechanism specified. Economic Viability: viable. System designers tried to reduce the use of digital signatures and avoided the use of asymmetric ciphers, thereby lowering the overall cost of the system. We believe this system s cost is adequate to be used with micro-payments. Scalability: high. This system is highly scalable, specially since all operations involving brokers may be done off-line. Interoperability: not specified. The system s design does not account for interoperability. Auditability: guaranteed. All players in the system are identified and certificates are needed to engage in a payment transaction System Functionality Description Establishment of Long Term Relationship: Each buyer must choose a broker and ask for a certificate. This certificate enables the buyer to generate chains and to use those chains to make payments. The buyer agrees to pay for all chains signed using his private key. Withdrawal: The buyer must generate a chain, sign the last value, and present it to the broker. This signature indicates that the buyer agrees to pay for each of the values in the chain. The values must be used from

5 the last generated to the first and the commitments (signed values) are vendor specific. Transaction: 1. Authentication: The buyer must be identified and must send the vendor the commitment for a chain and his certificate, j?k so that the vendor can verify his signature on the commitment. 2. Payment: Each time a buyer makes a payment, he must send one of the values in the chain to the vendor. The number of monetary units paid in each payment may be calculated by wherenkis the value transferred for this payment, andnjis the last value the vendor knows of. The vendor must verify the validity of each payment by applying the function as many times as needed to get the last known value of this chain. 3. Acknowledgement: There is no receipt in this system. 4. Conclusion: This system does not have a conclusion stage. Settlement: The vendor redeems the received chains by contacting a broker and sending him the buyer s commitment and the last known value of the corresponding chain. The broker will generate all values of the chain up to the one appended to the commitment in order to verify the chain. If the commitment signature is good and the broker could generate all values in the signed chain, the vendor will receive the corresponding value Implementation Aspects Cryptography: Digital signatures: are used but no specific algorithm is mentioned. Certificates: all public keys must be certified. The algorithm is not specified. Hashing: are used to generate chains. No algorithm specified. Network connections: One connection. Only the buyer and the vendor need to be in contact during each transaction. Token format: chains with signed root. Each of the values of the chain is a token. 3.2 E-cash Digicash s E-cash [5] is one of the most popular electronic payment systems in use today. It is an Internet based system with full user anonymity by the use of blind signatures[4]. The central authority must apply a signature on a blinded user generated token. This system is already in use by several banks from the United States, Germany and Finland. Of this date, Digicash has not yet made available full specifications of E-cash, so this analysis makes use of unofficial data available on the payment system (as in [9]) System Typification Exchange model: token based. E-cash tokens are called coins, which are numbered and have an expiry date. The bank must blindly sign all coins. Central Authority Contact: on-line. The bank that signed a coin must be contacted to verify its validity during a transaction. Payment Values: small payments. This system was designed to be used in the Internet, and the coins must be stored in users computers. Although the system makes use of strong cryptographic algorithms and would probably be secure even for large payments, the general lack of security in coin storage precludes the use of E-cash for large values. Hardware: general purpose. The system may be implemented on any kind of computer platform. Available Roles: user and bank. Users may buy or redeem tokens from the bank. Role Inversibility: interchangeable roles. All users of the system may act as payer or payee. Only the bank role cannot be played by any user. Privacy: existent. E-cash is based on blind signatures and guarantees payer s anonymity. Only in case of dispute the payer must be identified; the bank and the payee are always identified. The order description is sent unencrypted and may be seen or tampered with by an external observer. Divisibility level 2. Divisibility is attained by depositing coins and withdrawing smaller valued coins Desirable Requisites Integrity: guaranteed. Coin integrity is guaranteed by the use of digital signatures.

6 Robustness: Some mechanisms are provided. The payer and payee must agree on the order contents and price. The transactions are independent if there is no double spending of coins and the system allows the user to recover lost coins. Economic Viability: viable. The cost of operating the system is compatible with the values considered. Scalability: potentially low. Users who want to participate in a payment transaction must have accounts in the same bank, so bank E-cash servers are possible bottlenecks of the system. Banks must also maintain a list of used coins and may be overwhelmed by the size of this list. Interoperability: not possible. There is no interoperability as E-cash banks operate independently, working only with their own coins. Auditability: possible. Users must sacrifice their anonymity to prove involvement in a transaction. Banks must maintain logs of all deposits to potentially identify the users involved in the transactions System Functionality Description Establishment of Long Term Relationship: Each user must have an account with an E-cash bank and ask it to open a special E-cash account. From this account, users may withdraw and deposit E-cash coins. The user must also acquire and install E-cash s software. Withdrawal: The user must generate electronic coins, blind them and send them encrypted to the bank together with a signed request indicating which kind of coins are needed. The bank blindly signs them, associating with each coin a user specified value. The bank withdraws the total value of those coins from the user s account and sends the coins back to the user. The user unblinds the coins and may start using them. Transaction: 1. Authentication: The payee presents a payment request to the payer containing: amount, description and its ID. 2. Payment: The payer sends coins and a of the payment instructions to the payee, encrypted with the bank s public key. The payee then contacts the bank that signed these coins to check them against a spent coin list and to verify the payment instructions. The payee will then proceed to the settlement stage if the coins have not already been spent. 3. Acknowledgement: There is no receipt in this system. 4. Conclusion: There is no conclusion stage in this system. Settlement: After receiving a positive acknowledgment of coin and payment instruction verification, the payee has two possibilities of action: deposit the coins or generate new coins of same total value of the verified coins and ask the bank to blindly sign them Implementation Aspects Cryptography: Symmetric cipher: Triple-DES: used together with the asymmetric cipher in the secure envelope model to protect data transfers. Asymmetric cipher: RSA. Digital Signature: RSA, used to sign message es. Hashing: SHA. Network connections: 2 connections. One connection is needed for communication between payer and payee and another is needed so that the payee may present the coins to the bank for validation. Token format: All coins have: serial number, keyversion and bank s signature. The serial number must have a special form so the bank may identify valid numbers and the keyversion is used to determine value, currency and expiry date. The system also makes use of payment instructions containing the bank ID, amount, currency, number of coins, timestamp, payee ID, product description and a payer secret. This information is used to prevent coin stealing and to enable users to prove payments. 3.3 Internet Keyed Protocol Designed by IBM s research labs to be an adequate system for transactions using credit cards or account numbers on open networks, such as the Internet, ikp [6] is, in reality, a system that may be used to securely transmit account numbers on the Internet. This system has three distinct levels: on the first one, only controlling authorities must have a certified public/private key pair; on the second level, all vendors must also have such a certificate; on the third and last level, all participants must have a certified key pair. This level hierarchy allows for a gradual deployment of the system, with an increasing level of security.

7 3.3.1 System Typification Exchange model: notational. ikp is based on traditional payment processing systems for credit or debit card transactions and, as such, is a notational system. Central Authority Contact: on-line. The entity that processes credit card transactions (acquirer) or the bank responsible for the debit account must be contacted during each transaction. This entity will interface the ikp system with the traditional banking or credit card system, where the actual accounts are managed. Payment Values: small to medium payments. Credit card transaction cost makes the system too expensive to work with microtransactions and credit (debit) card transactions have an upper limit. So, the system should be used for small to medium transactions. Hardware: general purpose. The system may be implemented on any kind of computer platform. Available Roles: payer, payee and controlling entity. Payer and payee must be registered with one of the system controlling entities (issuers and acquirers). Role Inversibility: unchangeable roles. As in traditional credit card systems, the roles are fixed. A party enrolled as a vendor (or payee) can not use this system to make payments to other parties. Privacy: existent. The payer s identity (card number) is protected from the payee and the controlling authority has no access to the order contents. Message security and privacy is guaranteed by extensive use of cryptography, but the system does not allow anonymous transactions. Divisibility level 4. This is a notational system Desirable Requisites Integrity: guaranteed. This system makes use of digital signatures and certificates to protect message integrity and all implementations must take care of locally stored data integrity. The initial message is not encrypted so an intruder can intercept and modify the initial invoice, causing denial of service. In levels 2 and 3, all vendors must have a certified key pair and could sign this invoice to prevent forgery. Robustness: guaranteed. All ACID properties are guaranteed for each transaction. Economic Viability: viable. This system is viable for values in the range of common credit card or cheque transactions. Those are the transactions this system aims at making possible over the Internet. Scalability: high. ikp is as scalable as traditional credit card systems. Many banks and credit card associations may take part of the system and use the same certifying infrastructure. Interoperability: not planned. The authors have not planned integration with other systems. Auditability: possible. Logs and digital signatures allow accurate system auditing to detect fraud or malfunction. In level 3 (3KP), the system allows nonrepudiation of all transactions System Functionality Description Establishment of Long Term Relationship: Each user must choose one of the controlling authorities of the system and register with it. In a level 2 or 3 system, users may be asked to generate asymmetric encryption keys to be certified. All users get the master key from the certification hierarchy so they are able to verify certificates. Each user must get the system s software applications. Withdrawal: none. Transaction: 1. Authentication: In level 2 or 3 systems, each user must identify itself by sending its certificate to the other party. In level 1 systems, the parties only exchange data needed to initialize the transaction such as transaction ID and invoice. The vendor (payee) must tell the payer which acquirer was chosen to process this transaction by sending its certificate. 2. Payment: The payer gets the invoice, verifies it and composes a payment order with value, product description, account or credit card number and, optionally, a PIN. This payment order is encrypted with the acquirer s public key. 3. Acknowledgement: There is no receipt in this system. 4. Conclusion: On receipt of the payment order, the payee contacts the acquirer to verify the transaction validity. The acquirer will inform the outcome of the transaction and the payee must send this information to the payer. Settlement: Settlement is done automatically when the transaction is verified, in the conclusion step.

8 3.3.4 Implementation Aspects Cryptography: Asymmetric cipher: RSA. Digital Signature: RSA with the same keys. Certificates: PKCS format. ing: MD5. Network connections: 2 connections. One connection is needed for communication between payer and payee and another is needed so that the payee may present the payment order to the acquirer. Payment order format: Each payment order includes the payment value, a of identification information shared with the payer and payee, the payer s account number, a random number chosen by the payer and, optionally, a password or PIN. These data are encrypted with the acquirer s public key. 4 Conclusion This paper presents a systematic way to analyze and compare electronic payment systems. The main points of the analysis scheme are typification, desirable requisites, functioning and implementation aspects. Now and in the near future, many payment systems will be available to end users, vendors or financial institution and there will be a strong need for tools that enable people to choose which payment system is best suited to their needs. One of the main contributions of this work is to provide a systematic way to, after having enrolled all the requisites of an application, get an insight on the suitability of a system or to choose one from many systems. We strongly believe the analysis and comparison of payment systems should be done in light of the target application (i.e. information or hard goods sales, pay-per view etc.). Another contribution of this work is in giving a systematic view of the way payment system s work. This result may be used to help when designing a new payment system, especially to identify overlooked aspects of the design. We do not believe that there will ever be a universal payment system (i.e. a system suited to all needs) and so the comparison and analysis of payment systems must be done in the context of the intended application or future use. References [1] N. Asokan, M. Steiner, and M. Waidner. The state of the art in electronic payment systems. IEEE Computer, pages 28 35, September [2] L. J. Camp and M. Sirbu. Critical issues in internet commerce. IEEE Communications Magazine, pages 58 62, May [3] L. J. Camp, M. Sirbu, and J. D. Tygar. Token and notational money in electronic commerce. In USENIX Association, editor, Proceedings of the first USENIX Workshop of Electronic Commerce: July 11 12, 1995, New York, New York, USA, pages 1 12, Berkeley, CA, USA, July USENIX. [4] D. Chaum. Blind signatures for untraceable payments. In D. Chaum, R. L. Rivest, and A. T. Sherman, editors, Advances in Cryptology - Proceedings of Crypto 82, pages Plenum, [5] Digicash web site. URL: [6] P. Janson and M. Waidner. Electronic payment systems. Activity Paper 211ZR018, Semper/IBM Zurich Research Lab, May [7] B. C. Neuman. Security, payment and privacy for network commerce. IEEE Journal on Selected Areas in Communications, 13(8): , october [8] T. Okamoto and K. Ohta. Universal electronic cash. In J. Feigenbaum, editor, Proceedings of Crypto 91, LNCS 576, pages Springer-Verlag, [9] D. O Mahony, M. Peirce, and H. Tewari. Electronic Payment Systems. Artech House, [10] R. L. Rivest and A. Shamir. Payword and micromint: Two simple micropayment schemes. URL: rivest/rivestshamirmpay.ps, [11] A. Schoter and R. Willmer. Digital money online: A review of some existing technologies. Technical report, Intertrader Ltd., February Acknowledgements The second author is partially suported by research grant PRONEX-FINEP 107/97

9 A Summary of other systems A.1 Typification Exchange Central Auth. Amount Hardware Roles Invers. Privacy divisib. Fisrt Virtual notational online micro general BVS no no 4 Globe ID notational online small general BVS no yes 4 Payme token online small general UE yes yes 2 SET notational online small to medium general BVE no yes 4 PayWord token off-line micro general BVE no no 4 MicroMint token off-line micro general UE yes no 4 CAFE hybrid off-line small specific PRE yes yes 1 E-cash token online small general UB yes yes 2 ikp notational online small to medium general PRE no yes 4 Millicent token off-line micro general BVE no yes 3 NetBill notational online micro general BVE no yes 4 NetCash token online small general BVE yes yes 2 NetCheque notational online small general BVBk yes no 4 CyberCash notational online small general BVS no yes 4 Letters in the Roles column mean: B buyer V vendor S central server U user E controlling entity P payer R payee (receiver) Bk bank A.2 Desirable Characteristics Integrity Consistency Viability Escalab. Interoper. Audit. Fist Virtual Globe ID Payme p SET PayWord p p p p MicroMint p CAFE E-cash ikp Millicent NetBill NetCash NetCheque CyberCash p p p p p p

10 A.3 Implementation Aspects Cryptography Net connections Payment orders Fist Virtual 3 account number Globe ID asymmetric cipher 2 not specified signature Payme symmetric cipher (IDEA) 2 token value asymmetric cipher (RSA) serial number digital signature (RSA) Bank s identity validity bank s signature SET symmetric cipher (DES) 2 credit card data asymmetric cipher (RSA) transaction ID digital signature (RSA) value certificate (X.509) product description PayWord digital signature 1 chain value certificate MicroMint Hashing 1 function collision CAFE digital signature (Schnorr) 1 public keys vendor ID date value E-cash symmetric cipher (Triple-DES) 2 serial number asymmetric cipher (RSA) keyversion digital signature bank s signature (SHA) ikp asymmetric cipher (RSA) 2 of general data digital signature (RSA) account number Certificate (PKCS) random number (MD5) Millicent (MD5) 1 vendor ID value serial number buyer ID validity authenticity certificate NetBill symmetric cipher (DES) 2 Kerberos ticket asymmetric cipher (RSA) account number Certificate Hashing (SHA) NetCash symmetric cipher 2 issuer ID asymmetric cipher issuer address digital signature validity certificate serial number value issuer s signature NetCheque symmetric cipher 1 value currency date buyer s account number vendor ID buyer s signature CyberCash symmetric cipher (DES) 2 credit card number asymmetric cipher (RSA) digital signature (RSA) value of item s description