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
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.
Ricardo Dahab
IC/Unicamp
Caixa Postal 6176
13083–970 Campinas SP
Brasil
rdahab@dcc.unicamp.br
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 payment systems; a summary of the analysis of many known
systems is shown in the tables of Appendix A.
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 functional-
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.
Typification
tem’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.
Functioning
Exchange Model
Long Term
Relationship
Central Auth.
Contact
Amounts
Withdrawal
Transaction
Hardware
- Authentication
- Payment
- Acknowledgement
- Conclusion
Available Roles
Role Inversibility
Settlement
Privacy
Payment Values
System
Desir. Requisites
Integrity
Robustness
Economic Viability
Scalability
Interoperability
Auditability
Implementation
Cryptographic
Primitives
Network Connections
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
Payment Order
Format
Divisibility
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).
Off-line. Systems of this type allow users to
make transactions without contacting the sys-
Micro-payments. Only very small values are
involved, typically from US$ 0.001 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$
500.00.
Big payments.
Larger values (over US$
500.00) require greater security than the Internet 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 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.
Privacy
Existent. 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.
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.
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.
2.3 System Functionality Description
Cryptography. Describes all cryptographic algorithms
that are used in the system, specially: symmetric ciphers, asymmetric ciphers, digital signatures, certificates and hashing.
Electronic payment transactions consist of the following
steps:
Network connections. Quantity and type of network connections needed by the system.
Token or payment order format. Shows the contents and
organization of the tokens or payment orders used in
the system.
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.
3 Three systems in detail
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.
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, 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
n0 ; n1 ; : : : ; nk , where
ni
=
?1 ); i 1;
h(ni
is a strong cryptographic hash function and n0 is a random
number. The chain is used backwards, from nk to n0 . Since
h must be hard to invert, it is computationally infeasible to
obtain ni from ni+1 .
To make a payment, the user must first generate a hash
chain, sign nk , and send it to the vendor. Then, each monetary unit spent corresponds to the value x of the chain such
that h(x) is the previously spent value, currently held by the
vendor.
h
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 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$
1.00.
Hardware: general purpose. The system is software based
and makes no use of specialized hardware.
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.
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 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.
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 signature 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
where nk is the hash value transferred for this
payment, and nj 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 conclusion stage.
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]).
3.2.1 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.
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 corresponding chain. The broker will generate all hash
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.
Hardware: general purpose. The system may be implemented on any kind of computer platform.
3.1.4 Implementation Aspects
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.
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: hash chains with signed root. Each of the
values of the chain is a token.
Available Roles: user and bank. Users may buy or redeem
tokens from the bank.
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.
3.2.2 Desirable Requisites
Integrity: guaranteed. Coin integrity is guaranteed by the
use of digital signatures.
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.
3.2.3 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.
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 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 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 Protocol
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 hash 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.
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.
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.
3.3.2 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.
3.3.3 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 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
transaction is verified, in the conclusion step.
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 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.
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 commerce. 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 Electronic 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, Advances 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. Activity 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 Communications, 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 Payment 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/RivestShamirmpay.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
Fisrt Virtual
Globe ID
Payme
SET
PayWord
MicroMint
CAFE
E-cash
iKP
Millicent
NetBill
NetCash
NetCheque
CyberCash
Exchange
notational
notational
token
notational
token
token
hybrid
token
notational
token
notational
token
notational
notational
Central Auth.
online
online
online
online
off-line
off-line
off-line
online
online
off-line
online
online
online
online
Amount
micro
small
small
small to medium
micro
micro
small
small
small to medium
micro
micro
small
small
small
Hardware
general
general
general
general
general
general
specific
general
general
general
general
general
general
general
Roles
BVS
BVS
UE
BVE
BVE
UE
PRE
UB
PRE
BVE
BVE
BVE
BVBk
BVS
Letters in the Roles column mean:
B
S
E
R
buyer
central server
controlling entity
payee (receiver)
V
U
P
Bk
vendor
user
payer
bank
A.2 Desirable Characteristics
Fist Virtual
Globe ID
Payme
SET
PayWord
MicroMint
CAFE
E-cash
iKP
Millicent
NetBill
NetCash
NetCheque
CyberCash
p
p
Integrity
Consistency
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Viability
p
Escalab.
p
p
p
p
p
Interoper.
p
p
p
p
p
p
p
p
Audit.
p
p
p
p
p
p
p
p
p
p
Invers.
no
no
yes
no
no
yes
yes
yes
no
no
no
yes
yes
no
Privacy
no
yes
yes
yes
no
no
yes
yes
yes
yes
yes
yes
no
yes
divisib.
4
4
2
4
4
4
1
2
4
3
4
2
4
4
A.3 Implementation Aspects
Cryptography
Fist Virtual
Globe ID
Payme
SET
asymmetric cipher
signature
hash
symmetric cipher (IDEA)
asymmetric cipher (RSA)
digital signature (RSA)
Net connections
3
2
Payment orders
account number
not specified
2
token value
serial number
Bank’s identity
validity
bank’s signature
credit card data
transaction ID
value
product description hash
symmetric cipher (DES)
asymmetric cipher (RSA)
digital signature (RSA)
certificate (X.509)
hash
digital signature
certificate
hash
Hashing
digital signature (Schnorr)
2
symmetric cipher (Triple-DES)
asymmetric cipher (RSA)
digital signature
hash (SHA)
asymmetric cipher (RSA)
digital signature (RSA)
Certificate (PKCS)
hash (MD5)
hash (MD5)
2
symmetric cipher (DES)
asymmetric cipher (RSA)
Certificate
Hashing (SHA)
symmetric cipher
asymmetric cipher
digital signature
certificate
hash
2
NetCheque
symmetric cipher
hash
1
CyberCash
symmetric cipher (DES)
asymmetric cipher (RSA)
digital signature (RSA)
hash
2
PayWord
MicroMint
CAFE
E-cash
iKP
Millicent
NetBill
NetCash
1
hash chain value
1
1
hash function collision
public keys
vendor ID
date
value
serial number
keyversion
bank’s signature
2
hash of general data
account number
random number
1
vendor ID
value
serial number
buyer ID
validity
authenticity certificate
Kerberos ticket
account number
2
issuer ID
issuer address
validity
serial number
value
issuer’s signature
value
currency
date
buyer’s account number
vendor ID
buyer’s signature
credit card number
value
hash of item’s description