6.

2 Payer Anonymity
The simplest way to ensure payer anonymity with respect to the payee is for
the payer to use pseudonyms instead of his or her real identity. If one wants
be sure that two different payment transactions by the same payer cannot be
linked, then payment transaction untraceability must also be provided.
6.2.1 Pseudonyms
First Virtual Holdings, Inc. started to operate the first Internet payment system
that was based on the existing Internet infrastructure, that is e-mail,
TELNET, S/MIME, and FINGER. Although they did not use cryptography
at the beginning, they later realized that in some cases it was necessary. For
example, authorization messages exchanged between First Virtual and
merchants before shipment must be protected to prevent large shipments to
fraudulent customers.
Under the First Virtual system, a customer obtains a VirtualPIN
(VPIN), a string of alphanumeric characters which acts as a pseudonym for a
credit card number. The VirtualPIN may be sent safely by e-mail. Even if it
is stolen, an unauthorized customer cannot use it because all transactions are
confirmed by e-mail before a credit card is charged. If someone tries to use a
customer s VirtualPIN without authorization, First Virtual will be notified
of the stolen VirtualPIN when the customer replies fraud to First
Virtual s
request for confirmation of the sale (Figure 6.3). In such a case, the Virtual
PIN will be canceled immediately. This mechanism also ensures confidenti
ality of payment instruction with respect to the merchant and potential
eavesdroppers.
Figure 6.3 illustrates a First Virtual (FV) payment transaction. A cus
tomer sends his order to the merchant together with his VPIN (1). The mer
chant may send VPIN authorization request to the FV payment provider (2).
If the VPIN is valid (3), the merchant supplies the ordered services to the
customer (4) and sends the transaction information to the FV provider (5).
In the next step (6), the FV provider asks the customer whether he is willing
to pay for the services (e.g., via e-mail). Note that the customer may refuse to
pay (No) if the services were delivered but do not fulfill his expectations. If
the services were not ordered by the customer, he responds with Fraud.
That aborts the transaction and revokes (i.e., declares invalid) the VPIN. If
the customer wants to pay, he responds with Yes (7). In this case the
amount of sale is withdrawn from his account (8a) and deposited to the mer
chants account (8b), involving a clearing transaction between the banks (9).

The payment transaction described above involves low risk if the services
include information only. Even if a fraudulent customer does not pay for
the services delivered, the merchant will not suffer a significant loss [4], and
the VPIN will be blacklisted immediately. As mentioned before,
cryptographically protected authorization messages must be exchanged between
First Virtual and merchants before large shipments.
6.3 Payment Transaction Untraceability
Currently there is only one mechanism providing perfect anonymity and
thus perfect payment untraceability. However, this mechanism (blind
signature) is used for digital coins and will be discussed in the next chapter. Here,
two mechanisms that allow partial payment transaction untraceability are
described. Specifically, they make it impossible for a merchant to link
payment transactions made with the same payment instrument, assuming that
he does not conspire with the acquirer (or payment gateway).
6.3.1 Randomized Hashsum iniKP
The iKP mechanism described in this section is only a part of a more complex
protocol fully described in Section 6.4.1. When initiating a payment
transaction, the customer chooses a random number R
C

and creates a onetime pseudonym ID
C

in the following way:

BAN is the customers bank account number (e.g., debit or credit card
number).h
k
(.) is a one-way hash function that is collision resistant and
reveals no information about BAN if R
C
is chosen at random. The merchant
does not obtain BAN, but only ID
C
, from which he cannot compute BAN.
In each payment transaction the customer chooses a different random
number so that the merchant receives different pseudonyms. Thus it is
impossible for the merchant to link two payment transactions with the same
BAN.
6.3.2 Randomized Hashsum in SET
In SET (see also Section 6.4.2) a merchant also obtains only the hashsum of a
payment instruction. The payment instruction contains, among other
information, the following data (PANData, see [6]):
Primary account number, PAN (e.g., credit card number);
The cards expiry date (CardExpiry);
A secret value shared among the cardholder, the payment gateway,
and the cardholders certification authority (PANSecret);
A fresh nonce to prevent dictionary attacks (EXNonce).
Since the nonce is different for each payment transaction, the merchant
cannot link two transactions even if the same PAN is used.
6.4 Confidentiality of Payment Transaction Data
Payment transaction data generally consists of two parts: the payment
instruction and the order information.
A payment instruction can contain a credit card number or an account
number. The primary purpose of protecting its confidentiality is to prevent
misuse by unauthorized principals, including dishonest merchants (see also
Section 4.2.4.1). In many cases, however, the information contained in a
payment instruction uniquely identifies the payer. Consequently, protecting
it from unauthorized or dishonest principals also means protecting the payers
anonymity.
Order information can specify the type and amount of goods or
services ordered and the price to be paid, or just contain the order number. It
is often not desirable that the payment gateway (or the acquirer) learn about
a customers shopping behavior. In such cases the order information must be
made unreadable for the gateway.
Although a payment instruction and order information must sometimes be
made unreadable to different parties, there must still be a connection between
them that can be easily verified by the customer, the merchant,
and the payment gateway. Otherwise, in a case of dispute, the customer
could not prove that the payment instruction he sent to the merchant really
related to a particular order.
6.4.1 Pseudorandom Function
TheiKP [5] is a family of payment protocols (i=1, 2, 3) developed at IBM
Research. They support credit card-based transactions and are together with
CyberCash,
Secure Transaction Technology (STT, by Microsoft and Visa),
and secure electronic payment protocol which is based on 3KP (SEPP, by
MasterCard) the most important ancestors of SET. The 1KP (see also
Section 6.6.1) mechanism described in this section provides confidentiality
of order information with respect to payment gateways (or acquirers), as well
as confidentiality of payment instruction with respect to merchants. It also
provides customer anonymity with respect to merchants.
When initiating a payment transaction, a customer chooses a random
Number R
C
and creates a one-time pseudonym ID
C
in the following way:

BAN is the customers bank account number (e.g., debit or credit card
number). h
k
(.) is a one-way hash function that is collision resistant and
reveals no information about BAN if R
C
is chosen at random (e.g., HMAC,
see Part 1). In other words, behaves like apseudorandom
function.
The merchant can see only the pseudonym, so he obtains no information
about the customers identity. Since R
C
is different for each transaction, he
cannot link two payments made by the same customer. The only attack he
can try is to compute the hashsums of all possible combinations of a random
number and an account number (dictionary attack), but this would hardly be
feasible because, for a sufficiently long random number, there are too many
combinations. The acquirer obtains R
C
, so he can compute ID
C
and verify
that it is correct. The pseudonym should be used only once, that is, for only
one payment transaction.
Confidentiality of order information with respect to the acquirer is
achieved in a similar way. To initiate a payment transaction, the customer
chooses a random number, SALT
C
which should be different for each
transaction, and sends it to the merchant in the clear (i.e., unprotected). Using the
same hash function as before, the merchant prepares the description of the
order information (DESC) for the acquirer in the following way:

The acquirer can see that the hashsum is different for each payment
transaction, but he does not have enough information to computeDESC.It
is, however, possible to eavesdrop on the communication line between the
customer and the merchant on which SALT
C
is sent in the clear. If the
number of possible DESC values is not too high, the acquirer can compute
all possible hashsums for a given SALT
C
and thus obtain the order
information. Since the acquirer is probably trusted at least to some extent, this
type of attack is not considered to be very likely.
To communicate the payment instruction to the acquirer in such a way
that the merchant cannot read it,iKP uses public key encryption. The customer
encrypts a message including;
The price of the ordered items;
His payment instruction (e.g., credit card number, and, optionally,
card PIN);
hashed together with the general transaction
data;
A random numberRCused to create his one-time pseudonym, with
the acquirers public key.
The encrypted message is sent to the merchant to be forwarded to the
acquirer. The customer must have the acquirers public key certificate issued
by a trusted certification authority. In this way, only the acquirer can decrypt
the message. With R
C
the acquirer can verify the correctness of the customers
one-time pseudonym ID
C
.
The connection between the payment instruction and the order information is
established through the value of h
k
(SALT
C
, DESC) and the general
transaction data known by all parties. This combination of values is unique
for each payment transaction.