A Scheme for Analyzing Electronic Payment Systems
Lucas de Carvalho Ferreira
IC/Unicamp and DEX/UFLA
DEX, Campus da UFLA
37200-000 Lavras MG
Brasil
lucasf@ufla.br
Ricardo Dahab
IC/Unicamp
Caixa Postal 6176
13083–970 Campinas SP
Brasil
rdahab@dcc.unicamp.br
Abstract
This paper presents a scheme for the design, analysis and comparison of electronic payment systems. Three sys-tems are described in detail through this scheme.
Keywords: payment systems, analysis and design of pay-ment systems.
1
Introduction
The field of electronic commerce and especially elec-tronic payment systems has flourished in the past few years. The possibilities opened by the popularization of the Inter-net have forced many companies and research teams to turn their eyes to this new commercial universe. The first prob-lem that has to be addressed before the Internet could be-come a huge marketplace is finding a way to securely trans-fer 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 proto-cols had significant implications on the way people do com-merce on the Internet and new protocols are being deployed that may have much stronger implications in the develop-ment 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 elec-tronic 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 be-lieve a more integrated approach should be used to achieve a broader understanding of electronic payment systems.
We will here extend previous work on the classifica-tion of electronic payment systems and build a funcclassifica-tional-
functional-ity 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 pay-ment 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 ana-lyze 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 sys-tem. 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.
Withdrawal Transaction - Authentication - Payment - Acknowledgement Settlement - Conclusion Functioning Long Term Relationship
System
Implementation Primitives Format Network Connections Payment Order Cryptographic Hardware Typification Amounts Available Roles Role Inversibility Privacy Exchange Model Central Auth. Contact Integrity Robustness Economic Viability Scalability Interoperability Auditability Divisibility Desir. RequisitesFigure 1. Four Aspects that Characterize Elec-tronic Payment Systems
Notational. Payment transactions in notational
systems are done by the settlement of balances in accounts managed by the system’s central au-thority. 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
to-kens that have their value specified by the user at the time of the transaction.
Central Authority Contact
On-line. The central authority must be
con-tacted 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. Exam-ples are Internet based systems (E-cash, First Virtual, SET) and debit card based systems (Visa Electron, Carte Bleue).
Off-line. Systems of this type allow users to
make transactions without contacting the
sys-tem’s central authority at the exact moment each transaction occurs. Some time in the near fu-ture, the payee must contact the central server to settle things up, but this contact may be de-layed until the user believes it is appropriate. The payee must be able to verify payment valid-ity without help. An example is projectCAFE
payment system.
Payment Values
Micro-payments. Only very small values are
involved, typically from US$ 0.001 to a few dol-lars.
Small to medium payments. These values
may be transferred on the Internet with a good level of security, usually US$ 1.00 to US$ 500.00.
Big payments. Larger values (over US$
500.00) require greater security than the Inter-net can provide today.
Hardware
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 hard-ware.
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
prede-fined 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 conve-nient. Thus, they allow transferring values among users. However, in general, no system allows users to become the bank.
Privacy
Existent. In this case, systems protect, to some
extent, user’s privacy, allowing anonymous pur-chases, secure transfer or protection of critical information. Some systems guarantee that crit-ical information will be available only to those parties that need it.
Non-existent. Systems do not use
crypto-graphic techniques to protect information trans-fers. 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, with-out 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 applica-tion.
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
compat-ible with the values transferred through the system.
Scalability. A system must be able to cope with the
addi-tion of new users and with the increase of the quantity of money involved in its operation without a signifi-cant loss of performance.
Interoperability. A system must make possible the
ex-change 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 insti-tution responsible for managing the payment system and establishes a long term relationship with it. This financial institution is called a bank or controlling
en-tity. The registration with the bank may involve
open-ing an account, acquiropen-ing 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
sys-tem, 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 prob-lems. If there is any disagreement, a dispute res-olution 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 specifi-cation. This section presents some important implementa-tion aspects in the analysis of a payment system.
Cryptography. Describes all cryptographic algorithms
that are used in the system, specially: symmetric ci-phers, asymmetric cici-phers, digital signatures, certifi-cates and hashing.
Network connections. Quantity and type of network
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
PayWordPayWord is a micro-payment system designed by R. Rivest and A. Shamir [10]. It is efficient for repeated pay-ments to the same vendor, and is designed to reduce the use of public-key algorithms through the use of hash functions and fast symmetric ciphers.
The system is based upon the use of hash chains to represent monetary value. A hash chain is a sequence
n 0 ;n 1 ;:::;n k, where n i =h(n i?1 );i1;
his a strong cryptographic hash function andn
0is a random
number. The chain is used backwards, fromn kto
n 0. Since hmust be hard to invert, it is computationally infeasible to
obtainn ifrom
n i+1.
To make a payment, the user must first generate a hash chain, signn
k, and send it to the vendor. Then, each
mone-tary unit spent corresponds to the valuexof the chain such
thath(x)is the previously spent value, currently held by the
vendor.
3.1.1 System Typification
Exchange model: token based. Users have certificates that
enable them to generate hash 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 to-kens off-line.
Payment Values: micro-payments. The system avoids the
use of asymmetric ciphers at the cost of lowering se-curity, and is only adequate for payments under US$ 1.00.
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 ven-dor and buyer but only act as one of them at a partic-ular transaction.
Privacy: non-existent.PayWorddoes 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.
3.1.2 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
re-duce 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.
3.1.3 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 hash 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 hash chain, sign
the last value, and present it to the broker. This signa-ture indicates that the buyer agrees to pay for each of the values in the chain. The values must be used from
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 hash chain and his certificate, 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 hash chain to the vendor. The number of monetary units paid in each payment may be calculated by
j?k
wheren
k is the hash value transferred for this
payment, and n
j is the last value the vendor
knows of. The vendor must verify the validity of each payment by applying the hash 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 con-clusion stage.
Settlement: The vendor redeems the received hash chains
by contacting a broker and sending him the buyer’s commitment and the last known hash value of the cor-responding chain. The broker will generate all hash values of the chain up to the one appended to the com-mitment in order to verify the chain. If the commit-ment signature is good and the broker could generate all values in the signed chain, the vendor will receive the corresponding value.
3.1.4 Implementation Aspects Cryptography:
Digital signatures: are used but no specific
algo-rithm 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: hash chains with signed root. Each of the
values of the chain is a token.
3.2
E-cashDigicash’sE-cash[5] is one of the most popular elec-tronic 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 ofE-cash, so this analysis makes use of unofficial data available on the payment system (as in [9]).
3.2.1 System Typification
Exchange model: token based. E-cashtokens 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
de-signed 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 ofE-cashfor large values.
Hardware: general purpose. The system may be
imple-mented 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-cashis based on blind signatures and guarantees payer’s anonymity. Only in case of dis-pute 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.
3.2.2 Desirable Requisites
Integrity: guaranteed. Coin integrity is guaranteed by the
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
sys-tem 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 bankE-cashservers are possible bot-tlenecks 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
interoperabil-ity asE-cashbanks 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 poten-tially identify the users involved in the transactions.
3.2.3 System Functionality Description
Establishment of Long Term Relationship: Each user must have an account with anE-cashbank and ask it to open a specialE-cashaccount. From this account, users may withdraw and depositE-cashcoins. The user must also acquire and installE-cash’s software.
Withdrawal: The user must generate electronic coins,
blind them and send them encrypted to the bank to-gether with a signed request indicating which kind of coins are needed. The bank blindly signs them, as-sociating 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 us-ing them.
Transaction:
1. Authentication: The payee presents a payment request to the payer containing: amount, de-scription and its ID.
2. Payment: The payer sends coins and a hash of the payment instructions to the payee, encrypted with the bank’s public key. The payee then con-tacts the bank that signed these coins to check them against a spent coin list and to verify the payment instructions. The payee will then pro-ceed 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.
3.2.4 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
hashes.
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 num-bers 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 hash and a payer secret hash. This information is used to prevent coin stealing and to enable users to prove payments.
3.3
Internet Keyed ProtocolDesigned by IBM’s research labs to be an adequate sys-tem for transactions using credit cards or account numbers on open networks, such as the Internet,iKP[6] is, in real-ity, 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 pub-lic/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 hier-archy allows for a gradual deployment of the system, with an increasing level of security.
3.3.1 System Typification
Exchange model: notational. iKPis 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
pro-cesses credit card transactions (acquirer) or the bank responsible for the debit account must be contacted during each transaction. This entity will interface the
iKPsystem 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
imple-mented 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 en-rolled 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 author-ity has no access to the order contents. Message se-curity and privacy is guaranteed by extensive use of cryptography, but the system does not allow anony-mous transactions.
Divisibility level 4. This is a notational system. 3.3.2 Desirable Requisites
Integrity: guaranteed. This system makes use of
digi-tal signatures and certificates to protect message in-tegrity and all implementations must take care of lo-cally 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
guaran-teed for each transaction.
Economic Viability: viable. This system is viable for
val-ues 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 associa-tions 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 al-low accurate system auditing to detect fraud or mal-function. In level 3 (3KP), the system allows non-repudiation of all transactions.
3.3.3 System Functionality Description Establishment of Long Term Relationship:
Each user must choose one of the controlling author-ities of the system and register with it. In a level 2 or 3 system, users may be asked to generate asym-metric 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 certifi-cate to the other party. In level 1 systems, the parties only exchange data needed to initialize the transaction such as transaction ID and in-voice. The vendor (payee) must tell the payer which acquirer was chosen to process this trans-action by sending its certificate.
2. Payment: The payer gets the invoice, verifies it and composes a payment order with value, product description hash, 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
3.3.4 Implementation Aspects Cryptography:
Asymmetric cipher: RSA.
Digital Signature: RSA with the same keys. Certificates: PKCS format.
hashing: 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 hash 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 en-crypted 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 system-atic view of the way payment system’s work. This result may be used to help when designing a new payment sys-tem, especially to identify overlooked aspects of the design. We do not believe that there will ever be a universal pay-ment 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.
Acknowledgements
The second author is partially suported by research grant PRONEX-FINEP 107/97
References
[1] N. Asokan, M. Steiner, and M. Waidner. The state of the art in electronic payment systems. IEEE Computer, pages 28–35, September 1997.
[2] L. J. Camp and M. Sirbu. Critical issues in internet com-merce. IEEE Communications Magazine, pages 58–62, May 1997.
[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
Elec-tronic Commerce: July 11–12, 1995, New York, New York, USA, pages 1–12, Berkeley, CA, USA, July 1995. USENIX.
[4] D. Chaum. Blind signatures for untraceable payments. In D. Chaum, R. L. Rivest, and A. T. Sherman, editors,
Ad-vances in Cryptology - Proceedings of Crypto 82, pages
199–203. Plenum, 1982. [5] Digicash web site.
URL: http://www.digicash.com, 1997.
[6] P. Janson and M. Waidner. Electronic payment systems. Ac-tivity Paper 211ZR018, Semper/IBM Zurich Research Lab, May 1996.
[7] B. C. Neuman. Security, payment and privacy for network commerce. IEEE Journal on Selected Areas in
Communica-tions, 13(8):1523–1531, october 1995.
[8] T. Okamoto and K. Ohta. Universal electronic cash. In J. Feigenbaum, editor, Proceedings of Crypto 91, LNCS 576, pages 324–337. Springer-Verlag, 1992.
[9] D. O’Mahony, M. Peirce, and H. Tewari. Electronic
Pay-ment Systems. Artech House, 1997.
[10] R. L. Rivest and A. Shamir. Payword and micromint: Two simple micropayment schemes.
URL: http://theory.lcs.mit.edu/ rivest/RivestShamir-mpay.ps, 1995.
[11] A. Schoter and R. Willmer. Digital money online: A review of some existing technologies. Technical report, Intertrader Ltd., February 1997.
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 p p p p Globe ID p p p p Payme p p p SET p p p p p PayWord p p p MicroMint p p p CAFE p p p p p p E-cash p p p p iKP p p p p p Millicent p p p p NetBill p p p p NetCash p p p p NetCheque p p p p CyberCash p p p p
A.3
Implementation Aspects
Cryptography Net connections Payment orders
Fist Virtual 3 account number
Globe ID asymmetric cipher 2 not specified
signature hash
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 hash
hash
PayWord digital signature 1 hash chain value
certificate hash
MicroMint Hashing 1 hash 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
hash (SHA)
iKP asymmetric cipher (RSA) 2 hash of general data
digital signature (RSA) account number
Certificate (PKCS) random number
hash (MD5)
Millicent hash (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
hash value
issuer’s signature
NetCheque symmetric cipher 1 value
hash currency
date
buyer’s account number vendor ID buyer’s signature
CyberCash symmetric cipher (DES) 2 credit card number
asymmetric cipher (RSA) value
digital signature (RSA) hash of item’s description
