SMITH-WILSON

In a shared-key based system, a user and the system (or another user) share secret information (or secret key) that can be used for several purposes:

• Credential or Authentication Token: the shared secret can be used to authenticate the user to the system such as access password. For ex- ample, the user and the system establish a secure communication channel by running a key exchange protocol. Then, the user supplies her user- name and password to the system through the secure channel as a request for remote access. The system checks if the supplied username and pass- word match the ones in its database. If they are matched, the user is allowed to access the system resource.

In some applications such as credit-card payment, a cardholder (or a client) sends her credit-card number, which is the secret shared be- tween herself and her (card) issuer, as an authentication token including payment-related information to a merchant through a secure channel, such as SSL [FKK96], to request a payment to the merchant. The mer- chant then forwards such information to the issuer to request for payment

authorization. As the credit-card number is shared between the client and the issuer, the issuer can verify that the client’s request is valid. The issuer then deducts the requested amount from the client’s account and transfers it to the merchant’s account.

• Cryptographic Operations: the shared secret can be used as the key for encrypting or hashing a message sent between parties. For example, Alice sends Bob a message, encrypted with a shared key between herself and Bob, securely over an open network. If Bob did not previously generate this message, he can infer that this message has been originated by Alice. This is because, in addition to Bob, only Alice can generate the message.

Considering Internet payment scenario, the most obvious application which deploys shared secrets is the credit-card payment scheme over SSL [FKK96]. In this scheme, a credit-card number is considered as an authentication to- ken shared between its owner (a client) and her issuer. To make a payment to a merchant, after a SSL connection is established, the client supplies her credit-card number and relevant information, such as date of birth and billing address, to authenticate herself to the issuer. In SET protocol [Mas97], the client’s credit-card information as an authentication token is encrypted with the payment gateway’s public key and then signed with the client’s private key. When it is transferred to the issuer (via the payment gateway), the issuer can infer that this request has been originated by the client and it contains the valid authentication token. In this section, we focus on the security of credit-card information transfer during payment transactions to point out the security issues related to the deployment of shared secrets in payment trans- actions.

Obviously, the most sensitive information in any payment system is ac- count information which is shared between a client and her issuer. Several

security issues related to the exposure of the account information have been reported [RW02, Kra99]. In SSL-based credit-card payment system, although the credit-card information is securely transferred through a SSL channel, it is still revealed to the merchant who is considered as an untrusted party. In SET protocol [Mas97], the encrypted credit-card information is decrypted by the payment gateway and then forwarded to the issuer. This problem may arise if the payment gateway and the issuer are different parties. That is, the payment gateway may be a company that is monitoring the system. It may possibly have a conspiracy with an attacker, or even the merchant, so that the attacker can get the client’s credit-card information without any attempt to decrypt any messages.

Moreover, the credit-card number is considered as long-term, reusable, semi-secret information. It is printed on the card which is visible to every- one, and the client’s information such as date of birth and billing address is not difficult to find out. Although the credit-card number is replaced by a secret known only between the client and the issuer [LZ04], it still has to be transferred in every transaction. Therefore, it is vulnerable to various kinds of attacks.

Several techniques have been proposed to secure credit-card information transfer over the Internet [Kra99, RW02, LZ04, Sha02]. Credit-card number blinding technique was proposed in [Kra99] by applying HMAC [KBC97] to the credit-card number and a random number. Then, the output of HMAC and the random number are sent to the issuer for verification. Thus, the value of HMAC in each transaction is different. Recently, several concepts of disposable credit-card numbers (DCNs in short) have been proposed in both online [Sha02] and off-line schemes [RW02, LZ04, KSL03a]. These techniques allow each client to perform transactions with a fresh credit-card number in every transaction.

In this thesis, we focus our consideration on off-line DCN generation tech- niques because they offer advantages over the online techniques. That is, the off-line techniques do not require any communications between the client and the issuer to generate a DCN in every transaction, whereas the online ones do. The off-line techniques therefore do not require any secure channel established between the client and the issuer.

Several off-line DCN generation techniques have been proposed. In Rubin

et al.’s scheme [RW02], each DCN is generated from the encryption of payment information with a long-term key shared between the client and the issuer. In Li et al.’s scheme [LZ04], a new DCN is generated from the hash value of previously used DCN and a long-term key shared between the client and the issuer.

In this section, we outline two existing off-line DCN generation techniques. Section 2.6.1 presents Rubinet al.’s scheme. In section 2.6.2, Liet al.’s scheme is described in details.

2.6.1

Rubin

et al.’s Scheme

Rubin et al. proposed an off-line DCN generation technique [RW02] which eliminates the need of long-term, reusable credit-card numbers. In this tech- nique, a DCN is generated by the encryption of a set of payment-related infor- mation (calledrestrictions), containing payment amount, merchant’s identity, billing address, etc., with a long-term shared key between a client and her is- suer. For example, Alice wants to purchase a 50-dollar book from Bob’s store. She generates a tokenT as follows:

T ={fifty-dollars-book-Bob’s-store}K

whereK is the long-term key shared between Alice and the issuer. On re- ceiving this message, the issuer decrypts the message by using the keyK. This technique also deploys timestamp for replay and collision protection. Note that

the collision may occur when two different payment information is encrypted either with the same key or even with different keys. Although, Rubin et al.

argued that the system is secure against various kinds of guessing attacks, to some degree, the encryption with the long-term shared key is vulnerable if an attacker has sufficient information and attempts to decrypt the DCN. The system will fail if the long-term key is compromised. Waiting until the fraud is being detected may be unacceptable to the clients whose credit-card infor- mation falls into the wrong hands. Moreover, Liet al. [LZ04] argued that the encryption may be computationally expensive when there are many users and restrictions.

2.6.2

Li

et al.’s Scheme

Li et al. proposed a technique to generate DCNs based on one-way hash functions for a smartcard-based environment [LZ04]. Initially, a smartcard- based credit card is issued to a client. The information stored on the credit card is composed of the semi-secret, 16-digit credit-card number CCN, the long-term keyS, and the initial session DCN Tinit. CCN also appears on the card. These secrets are known only to the client and the issuer.

In the first transaction, the client sends the issuerTinit for payment autho- rization. In next transactions, the client generates new DCNsTnew as follows:

Tnew =h(Tcur, S)

whereTcurstands for the previous-used DCN. The client then sendsTnewto the issuer. On receivingTnew, the issuer calculatesTnew and compares with the one received from the client in order to verify the client. It can be seen that the security of the system is based on the length ofSandT and the security of the hash function. Although it is assumed that the hash function is irreversible, the use of the long-term keySoffers an opportunity for an attacker to attempt

to computeS from eavesdropping DCNs. Moreover, successful guessingS will compromise the security of the system.

2.6.3

A Possible Solution to Secure Account Informa-

tion Transfer

In previous sections, we have discussed the importance of securing account in- formation transfer during transactions. The exposure of account information will compromise the security of the entire system. Unfortunately, the exist- ing techniques to secure the account information still rely on the long-term shared key. The compromise of the key results in the exposure of the account information.

In this thesis, we will investigate a technique to secure the transfer of shared secrets during payment transactions. Our technique is based on the generation of limited-use shared secrets that relies on a randomly generated group of shared secrets instead of a single long-term shared secret. The higher number the limited-use shared secrets have been used, the less chance the attacker can compromise the system. Our limited-use shared secrets can be used as single-use credentials, such as DCNs, or the keys for cryptographic operations, such as encryptions or keyed-hash functions. The details of the proposed technique will be presented in chapter 8, whereby the limited-use shared secrets generated by our technique will be used to enhance the security of our non proxy-based mobile payment protocols.