Implementing Disposable Credit Card Numbers by … · approach meaningful from a practical point of view, ... (DCCN), also called one-time ... Implementing Disposable Credit Card

Electronic Commerce Research manuscript No.(will be inserted by the editor)

Implementing Disposable Credit CardNumbers by Mobile Phones?

Francesco Buccafurri, Gianluca Lax

DIMET Dept., University “Mediterranea” of Reggio Calabria,Via Graziella, Localita Feo di Vito, 89122 Reggio Calabria, Italye-mail: [email protected], [email protected]

Received: 28 May 2010 / Accepted: 11 September 2010

Abstract Disposable credit card numbers are a recent approach to tack-ling the severe problem of credit card fraud, nowadays constantly growing,especially in the context of e-commerce payments. Whenever we cannot relyon a secure communication channel between cardholder and issuer, a pos-sibility is to generate new numbers on the basis of some common scheme,starting from a shared secret information. However, in order to make theapproach meaningful from a practical point of view, the solution shouldguarantee backward compatibility with the current system, absence of newinvestments in dedicated hardware, wide-spectrum usability, and adequatesecurity level. In this paper, we propose a solution based on the use of stan-dard mobile phones, fully meeting the above desiderata. Importantly, oursolution does not require any cryptographic support and, as a consequence,the use of PADs or smart phones, opening then its usability to a widerpotential market.

Key words Credit card payments – credit card fraud – disposable creditcard numbers – secure payments.

1 Introduction

Credit card fraud is nowadays a serious problem whose dimension is con-stantly growing. Indeed, there are a number of techniques exploited by at-tackers during both on-line and traditional transactions to steal the fixed

? A shorter abridged version of this paper appeared in Proceedings of the 9thInternational Conference on E-Commerce and Web Technologies, Giuseppe Psaila,Roland Wagner (Eds.): EC-Web 2008, Turin, Italy, September 3-4, 2008. LectureNotes in Computer Science 5183 Springer 2008 [2]

Citation:

@ARTICLE{LaxECR11,

author={Buccafurri, F. and Lax, G.},

title={Implementing disposable credit card numbers by mobile phones},

journal={Electronic Commerce Research},

year={2011},

volume={11},

number={3},

pages={271-296},

}

NOTICE: this is the authors version of a work that was accepted for publication. Changes resulting

from the publishing process, such as editing, corrections, structural formatting, and other quality

control mechanisms may not be reflected in this document. Changes may have been made to this

work since it was submitted for publication. The final publication is available at

http://www.springerlink.com/content/w7p14q21785g6u30/ DOI: 10.1007/s10660-011-9078-0

http://www.springerlink.com/content/w7p14q21785g6u30/

2 Francesco Buccafurri, Gianluca Lax

credit card number used for authentication and to use it for fraudulent pay-ments. This is a direct consequence of the intrinsic weakness of the tradi-tional credit card system, where the key used for authentication is long-term,semi-secret, transmitted over insecure and sometimes completely disclosedchannels.

This has induced many credit card issuers to produce cards equippedwith a chip [39,43] in order to harden the authentication process. How-ever, due to both the necessity of maintaining backward compatibility withtraditional point of sale terminals (POS) and the variety of utilizations ofcredit cards (for example, on-line transactions, reservations, etc.), the simpleauthentication based on a credit card number will remain allowed reason-ably still for a long time. Moreover, credit cards are still widely used ine-commerce as well as in other e-activities when alternative secure paymentmethods, like [38,33], are not applicable or preferred.

Besides the possibility of detecting fraud [16,12,5,10,21,34], a recentapproach to tackling credit card fraud is based on the concept of disposablecredit card number (DCCN), also called one-time credit card transactionnumber. According to this approach, issuer and customer agree on a numberto be used for the transaction, then they discard it and generate a new num-ber for the next transaction. This way, stealing an authentication numberduring a transaction does not give the attacker any useful credential.

There are commercial solutions based on the above scheme [35,8]. Someof them expect the cardholder to get the disposable number from the is-suer Web site after authentication by sensitive data (like a standard creditcard number or a password), thus resulting in a solution still insecure orimpracticable if the user cannot start an Internet connection before eachtransaction. Other solutions are too expensive, when the issuer provides thecardholder with an additional device capable of generating and displayingthe disposable number. In the last case, the cost of the solution stronglylimits its real applicability.

Concerning how to generate DCCNs, there have been a number of pro-posals in the literature. In [36], customer and issuer share a long-term cryp-tographic key. Before each transaction, the customer generates a new au-thentication number by encrypting a set of possible restrictions describingsome elements of the transaction itself. Once the issuer has received theabove data, he decrypts it by the long-term secret key and verifies the pur-chase. A similar approach, also based on encryption, has been proposed in[46].

Stating that encryption is too expensive to be realistically used in thiscontext, the authors of [40] propose the use of context free grammars (thusnot relying on any cryptographic algorithm) to generate disposable num-bers. Context free grammars present the property that the generation andvalidation of strings belonging to a given language can be done in polyno-mial time, but it is unfeasible to find the grammar given only the stringsgenerated by it, since any conjectured grammar may fail on a new inputstring. However, the authors do not give any suggestion about how con-

Implementing Disposable Credit Card Numbers by Mobile Phones 3

text free grammars have to be generated. As a consequence, an unluckygeneration of the grammar may allow an attacker to easily guess the gram-mar. Moreover, as stated in [41], there exists no theoretical result about thedifficulty of guessing another string belonging to the same language, thusshowing the impossibility to guarantee the security of this technique.

Also the authors of [24] state that in some application scenarios, the re-quirement on encryption devices may not be affordable and in [25] proposea more efficient solution using cryptographic hash functions rather than en-cryption. Starting from a secret key shared between issuer and customer, anew DCCN is obtained by computing a cryptographic hash function on theconcatenation between the secret key and the latest authentication number.Even though the computation of cryptographic hash function is more effi-cient than encryption, the necessity of having a standard smart card (i.e.,an embedded computer), still remains.

In this paper, we make a step ahead with respect to the results pre-sented in [25], which represents the state of the art in this context. Indeed,we propose a new DCCN generation scheme that is designed to work onsmall resource constrained devices. Thanks to this feature, we can imple-ment the scheme on standard mobile phones since it does not require anycryptography support (indeed, the most part of standard mobile phones donot provide the cryptography support).

This is certainly a key feature of our proposal, since it represents asolution to the problem of credit card fraud that can be considered reallyfeasible from every point of view, including the market one.

The first reason of the above claim is that the solution does not re-quire massive investments from the side of issuers (no smart card, no highcomputational load). It is well known that the seeming low attention to-wards security aspects shown by issuers is actually the right compromiseof a trade-off between costs to implement radical innovations and costs torefund customers victims of fraud [29,20].

The second (more important) aspect to consider in order to justify theclaim about the full feasibility of our technique concerns users, who aretypically well-disposed to concentrate their personal services on a singlehandy device. Despite the undeniable recent rapid grow of the market ofsmart phones or PDAs, we expect that in the next years we will have stillusers reluctant to discard their standard (possibly cheap) mobile phone infavor of a more expensive, less user-friendly, powerful device. For this reasonour solution is based on the use of standard mobile phones with no advancedfeature apart from the (universal) Java support and Bluetooth.

As a further reason of feasibility of our technique, we observe that ourdisposable number format is the same as the current one. This backward-compatibility feature is, in contrast, typically ignored in other approaches,which thus miss a very important issue from a practical perspective. Indeed,this is a necessary condition to maintain existing point of sale terminals.


Finally, observe that the disposable number generation scheme here pre-sented is an extension of another scheme proposed in the context of Webauthentication protocols [3].

The rest of the paper is organized as follows. In the next section, we givethe preliminary background necessary to better understand our proposal.In Section 3, we present a summary description of the DCCN generationscheme and the architecture of the system used by customers for credit cardpayments. The detailed definition of the elements composing our schemeis given in Section 4. The practical application of our proposal exploitingstandard mobile phones is discussed in Section 5. Since the robustness ofour method against possible attacks is the necessary condition for a validproposal in this topic, we deeply analyze the security of our scheme boththeoretically and experimentally in Section 6. Finally, in Section 7, we drawour conclusions.

2 Credit Card Process System

In this paper, we propose a number generation scheme for DCCNs. Animportant issue is understanding how this scheme has to be designed toproduce a solution really applicable in the current credit card system. Tothis aim, we describe the information stored into the magnetic stripe of acredit card.

According to the ISO/IEC standard 7811 [18], a magnetic stripe containsthree tracks, even though typically only the first two tracks are used. Theinformation stored on the tracks are: a Primary Account Number matchingthe credit card number printed on the front of the card, a country code,the cardholder’s name, the expiration date and, finally, some discretionarydata typically used to save other cardholder’s information (for example, theaddress). Concerning the primary account number, for a standard 16-digitcredit card, it is a tuple 〈MII, INN, AN, C〉 containing a single-digitmajor industry identifier (MII) (4 for Visa, 5 for MasterCard, and so on),a five-digit issuer identifier number (IIN), an account number (AN), and asingle digit checksum (C) computed by the Luhn algorithm [26]. The digitsfrom 7 to 15 are used by banks to authenticate their users1. One could thinkthat guessing a valid credit card number is not very difficult, since only 9digits should be hit (the first 6 digits are fixed and public for each bank andthe last one can be easily computed). However, besides the primary accountnumber, also additional information is exploited to harden the transaction,like the card expiration date, which limits the threat of identity theft, or thesecurity code printed on the back of the card.

Since the most important portion of the credit card number is the 9-digit account number (issuer, major industry, and checksum values can be

1 In order to enlarge the set of credit card numbers assignable to users, bankswith a large number of customers are associated with more issuer identifier num-bers.


Algorithm 1 Validate a credit cardInput: CHN, CCN {the cardholder’s name and the credit card number to be validated}Variable: CCDB {the database of credit cards}

if 〈CHN, CCN〉 is in CCDB thenreturn true

elsereturn false

end if

calculated), our goal is to design a scheme to produce, at each transaction,a new 9-digit number that, combined with MMI, INN, and the resultingchecksum, will be used for the next transaction.

We conclude this section by briefly illustrating the bank-side credit cardverification protocol. Algorithm 1 encodes the protocol currently used tovalidate a credit card number (we do not describe here the check involvingthe card expiration date and the card security code). It consists in checkingthat the credit card number is associated to the cardholder’s name in thedatabase of valid credit cards. In the next section, we will show how thisprotocol should be slightly modified in order to implement our proposal.

3 Overview of the Proposal

In this section, we give an overview on the framework proposed to preventcredit card fraud. We recall that it is based on the use of DCCNs generatedaccording to the scheme presented in the next section. Besides this scheme,the second component of our framework is the application executed on themobile phone of the user in order to display a disposable credit card numberbefore a transaction. This application is presented in Section 3.2.

3.1 The DCCN Generation Scheme

The core of the proposal is the definition of a number generation methodthat meets the strong efficiency requirements illustrated in the introduction.Note that the approach proposed in [25] as well as other disposable-number-based methods proposed in the literature in the context of secure creditcards [36,46] requires devices supporting cryptography since it is based onthe use of cryptographic hash functions. Thus, at least PDAs or smartphones are needed. In order to allow the use of standard cellular phones, anew lightweight method is thus necessary. Of course, considering which kindof application we are facing (i.e., electronic payments), we have to pay noprice in terms of security. This is our case, as exhaustively shown in Section6. Here we give a rapid overview on the proposed number generation schemein order to help the intuition of the reader and to highlight that the requiredcomputational effort definitely does not hinder the implementation of thescheme on mobile phones.


s 1

x c

s 2

H

s c B B B

s 0 ...

P DCCN

Fig. 1 Disposable credit card number generation scheme.

Algorithm 2 Generate DCCN(s0, c)s = s0

for i = 1 to c dos = B(s) {Update the initial seed c many times}

end forDCCN = P(H(s))return 〈DCCN, s〉 {Return the new DCCN and the current seed}

Now we show how the scheme is used to generate DCCNs. The scheme,which receives a 511-bit string s0, called initial seed, and a positive integerc, exploits the following functions:

1. a reversible function B, named basic function, used to modify the seed;2. a non-cryptographic hash function H, named hash function, used to

produce a 64-bit string from a seed;3. a projection function P producing a DCCN from a 64-bit string.

The scheme is shown in Figure 1 and implemented by Algorithm 2.Starting from the initial seed s0 and using the basic function, it is possibleto create a chain of values s0, s1, s2, . . . such that si = B(si−1) for eachi ≥ 1. Since the function B is reversible, this chain can be traversed alsobackward by computing si = B−1(si+1). Consequently, the chain values arenot required to be pre-computed and stored, but they can be generatedon the fly (the resulting advantages regard validity checks of already burntnumbers, like in case of refunds).

The c-th value of this chain (i.e., sc) is used to compute xc = H(sc),where H is the hash function. Observe that c works as parameter for thechoice of the seed to be used. Concerning the hash function H, we observethat the approaches followed in previous schemes [14,15,23,25] use crypto-graphic hash functions which satisfy the collision-resistant property, thatis, it should be hard for an attacker to find a message such that its hashvalue equals a given value. In our scheme, this requirement is not necessary.Indeed, in our scheme, the hash function is used to avoid that the knowl-edge of xc gives an attacker the possibility to guess sc. To reach this goalit suffices to rely on the non-injective behavior of the hash functions. Inparticular, we just have to require that the set of hash-colliding values hasa enough large cardinality. In this case, the attacker is able to find many


seeds having xc as hash. However, if the value s′c chosen by the attackerdiffers from the actual sc, then the probability that the attacker guesses thesuccessive disposable numbers is negligible, as proven in Section 6.3. Thisallows us to utilize in our scheme a non-cryptographic hash function, withevident advantages in terms of efficiency.

However, it is worth remarking that our approach does not consist sim-ply in the substitution of a hash function in place of a cryptographic one ina typical number generation scheme (like [25]). It is intuitive understand-ing that this would result in a very insecure approach just because of theweakness of the hash function itself (and because, in a scheme like [25], anew number is calculated as the hash of a seed that contains the numberobtained at the previous step). We have designed thus a new hash functionand, coherently, a new number generation scheme guaranteeing the securityof the approach.

Finally, concerning the last step of our scheme, by means of the projec-tion function we generate the disposable credit card number as P(xc). Theprojection function is necessary to transform the value obtained by the hashfunction into a valid credit card number, according to the rules describedin Section 2.

3.2 The Application

As stated in the introduction, the first requirement we intend to meet is tomaintain backward compatibility with the current credit-card numbering,which will remain allowed reasonably still for a long time. To this aim, it isimportant that the disposable 16-digit credit card numbers are compliantto the standard format described in Section 2.

Currently, the credit card number is stored into the magnetic strip insuch a way that it can be read by the point of sale during a transaction. Onthe one hand, this is an advantage for the customer who does not have toremember any information. On the other hand, this makes fraud based oncredit card counterfeit easier. Indeed, an attacker who is able to physicallyaccess the credit card, even for a short time, may clone it by means of askimmer. Of course, the use of a dedicated device capable of storing anddisplaying the number could be a better solution from a security point ofview. However, this solution would have a significant extra cost seriouslylimiting its applicability.

For this reason, we propose a system in which users exploit their mobilephone to generate DCCNs. Next, we briefly describe the functionalities ofthe system (their more technical presentation is given in Section 5):

1. Installation. Users are clients of a bank offering the service. When theuser goes to his bank for getting a credit card, the bank installs on hismobile phone the application that produces and displays DCCNs. In thisphase, the bank is responsible for the user identification. Note that thephysical presence of the user is a measure typically used in the context


of strong authentication (for example, to provide smart cards for digi-tal signature generation), since the initial identification is dramaticallycritical. Then, the user receives a closed envelope containing both theactivation code and the PIN necessary to run the application that mustbe kept secret. Like for credit card numbers, the last digit of both theactivation code and the initial PIN is computed by the Luhn algorithm[26] (see Section 2) in order that accidental typing errors are detected.Concerning the installation of the application on the mobile phone, weobserve that due to multitude of mobile phone brands, it would be im-possible to transfer the application to the mobile phone by making useof specific equipments (like a data cable). The easiest and cheapest wayis to exploit Bluetooth. Of course, during the installation all standardsecurity precautions are adopted. For example, in order to avoid eaves-dropping, the bank uses a Class 3 Bluetooth connection [27] having auseful range of 1 meter.

2. Activation. Only the first time the user runs the application, he has toenter the activation code ensuring that no one can see this code. If thecode entered by the user satisfies the Luhn checksum, then this valueis stored by the application. Otherwise an error message is displayed.Observe that DCCNs will be generated on the basis of the activationcode entered in this step, since the initial seed of the generation schemeis derived from a combination of such a value with some initial datastored at the installation time. This step is used to tackle an insiderattack. Indeed, also in case a dishonest employee of the bank copies theapplication, he cannot run it correctly without the knowledge of theactivation value.

3. Payment. When the user has to make a payment by credit card, he hasto run the application on his mobile phone. The execution will displaythe current DCCN as well as the additional information necessary forthe transaction (like the expiration date). These data will be typed inthe merchant’s point of sale (POS) in case of card-present transactionsor will be used to complete a Web form in case of card-not-presenttransactions. In order to avoid identity theft done by stealing the clientdevice, the user is asked to enter the PIN. Whilst doing this, the usershould ensure that no one can see the PIN. If the PIN entered by theuser does not satisfy the Luhn checksum, then the user is asked to enteragain the PIN. For security reason, after three consecutive wrong PINsthe application will get locked. It is worth noting that, in order to giveadded protection against stolen device attacks, the PIN is not storedinto the mobile phone and the PIN is not just an access control for theapplication but it is inherently integrated in the whole process of thedisposable number generation. This issue will be deeply addressed inSection 6.1.

4. PIN change. Since the use of a fixed PIN presents an increased securityrisk, it is a good practice to update the PIN periodically (typically 30-90days, as recommended). The system allows for PIN change by means of


a procedure composed of three sequential steps. In the first step, the userruns the PIN change functionality of the application and is promptedfor the old (current) PIN. After typing the old PIN (that is validated ac-cording to the Luhn checksum), he is asked to enter the new PIN twice toavoid typing errors. As typically occurs, the typed numbers will not ap-pear on the display and the choice of a good PIN is recommended. Then,the application displays a confirmation number CN which depends onthe old and the new PIN. To complete the PIN changing procedure theuser has to execute the second step which consists in connecting (by thephone itself or also by a PC) to the Web page of the site of the bankallowing PIN changing. Here, the user enters its username and the con-firmation number CN produced by the mobile phone. After the checkof the validity of CN , the bank updates the user’s PIN and replies bya commit value CV . Finally, the user enters CV into the mobile phone,thus concluding the PIN change procedure. In Section 5, we illustratehow CN and CV are generated and validated.

Consider now the design of such an application. Since it has to run onthe user’s mobile phone, it is very important that its hardware and soft-ware requirements are as less restrictive as possible, in order to maximizethe number of mobile phone models on which the application can run. Infact, even though the spread of powerful mobile devices, such as PDAs, isconstantly increasing, there will be still for a long time users equipped withstandard mobile phones unable to run complex applications (like, for exam-ple, that requiring the execution of cryptographic operations). Moreover,any solution based on a complex generation scheme requiring users to buya smart phone or a PDA cannot be considered acceptable.

As a consequence, in the design of our application and, consequently,of the underlying DCCN generation scheme, we require that it could beimplemented by a traditional mobile phone. As we will show in Section 5, weachieved this result by implementing the application as a MIDLET, a Javaprogram for embedded devices, which can run on any device implementingJava ME Mobile Information Device Profile. This ensures that any J2ME-enabled device (in practice, almost the universe of current mobile phones)can run the application.

Now we describe the slight changes to the current credit card numbervalidation process (presented in Section 2) necessary to implement our pro-posal. Algorithm 3 shows how the new validation protocol operates. Now,besides the credit card database, the bank has to store also the current seedsi for each user. The new protocol is composed of the traditional one (seeLine 1 and Lines 8-11 of Algorithm 3), where it is checked that the creditcard number is valid, combined with the computation of the next valid dis-posable number, its insertion into the database of valid credit card numbers,and the removal of the burnt credit card number from the database (Lines3-6). In order to guarantee compatibility with traditional credit cards, theprotocol Lines 3-6 are executed only for transactions using disposable num-bers (this is checked by Line 2 of the protocol).


Algorithm 3 Validate a DCCNInput: CHN, CCN {the cardholder’s name and the credit card number to be validated}Variable: CCDB {the database of valid credit card data}Variable: SDB {the database of user’s current seed}1: if 〈CHN, CCN 〉 is in CCDB then2: if CHN uses disposable numbers then3: select S from SDB {S is the cardholder’s seed}4: compute DCCNnew by S {compute the next DCCN}5: insert 〈DCCNnew,CHN 〉 into CCDB6: delete 〈CCT, CHN 〉 from CCDB7: end if8: return true9: else

10: return false11: end if

The above bank-side validation protocol is a simplification that does nottake into account the case of delayed charge (for example, occurring whencredit cards are used for hotel reservation, car renting, etc.). In this case,the merchant submits an authorization request to validate the number butthe effective amount is charged in a subsequent time. In our proposal, incase of authorization request, the bank system does not burn the number(if currently valid) but associates this number with the merchant ID. Af-terwards, this disposable number may be used only by the same merchant.This solution can be also adopted in the case of permanent payment autho-rization (like the charge of a subscription on a credit card). The validationprotocol has to be slightly modified in order to search for the number tobe validated also among those already used in a past transaction, acceptingthe transaction only in case the merchant of the current transaction is thesame as the merchant of the past transaction (this eliminates the risk ofreply attacks).

Finally, in order to maintain a synchronization between numbers gener-ated by the user device and numbers expected by the bank, it is necessaryto keep into the valid credit card database, for each account, a queue ofvalid numbers instead of just one. In the literature, there exist a number ofapproaches to dealing with the above issue, also to deciding the right lengthof stored queues (see for example [25]), which could be adopted also in ourvalidation scheme (this issue is outside the scope of the paper).

4 Disposable Credit Card Number Generation Scheme

In this section, we give the definitions of the elements composing the numbergeneration scheme, which are the basic function B, the hash function H,and the projection function P. Observe that their implementation cannotproceed orthogonally. Since the non-secret result is the composition of thethree functions, we have to avoid that they are based on the same elementaryoperations, which would give the attacker useful information to proceedby crypto-analysis techniques. To prevent this, as we will explain in thefollowing sections, the basic function is based on string reverse and sum,


the hash function is based on XOR and shift, and the projection functionis based on scaling operations.

Before going into detail about the elements composing our scheme, weneed some preliminary notations.Notations.

– We denote by xk = (x1, . . . , xk) a k-bit string, where xj , with 1 ≤ j ≤ k,represents the j-th bit numbered from left to right.

– We denote by xk = (xk, . . . , x1) the k-bit-reverse string of xk.– xk + 1 denotes the k-bit string representing the number obtained by

summing (in 2k-modulo arithmetic) xk thought as a binary number and1. For example, given x3 = 111, x3 + 1 represents the string 000, since(111 + 001)(mod 1000) = 000(mod 1000).

– Given a k-bit string xk, we denote by [xk]i,j with 1 ≤ i ≤ j ≤ k thesub-string of xk obtained by keeping the j − i + 1 bits starting from thei-th left-most bit. For example, given xk = 1000, [xk]1,2 = 10.

– Given a k-bit string xk, we denote by [xk]i with 1 ≤ i ≤ k the i-thleft-most bit, i.e., [xk]i,i.

– Given a decimal number N , we denote by [N ]j its j-th left-most digit.For example, given N = 56789, then [N ]2 = 6.

– We denote by xixj the (i+j)-bit string obtained by juxtaposing the twostrings xj and xi.

– Given a k-bit string x, we denote by −→x the k-bit string obtained from xby circularly right shifting it as many times as the number of 1s occurringin it. For example, given x = 1100, then −→x = 0011.

– Finally, we denote by 1k (0k, resp.) the k-bit string composed of all 1s(0s, resp.).

4.1 The Basic Function

In this section, we define the basic function B. We recall that the basicfunction allows us to generate the sequence of seeds used in the scheme.The function is defined as follows.

Definition 1 Given a k-bit string sk, then B(sk) = sk + 1.

In words, B(sk) is obtained by reversing the string sk and, then, bysumming 1 (modulo 2k).

Since this function allows us to have a new seed at each generation, itshould be necessary that its period is as large as possible, hopefully 2k (theupper bound), in order to have a negligible probability of re-generating apast seed during a plausible life of a credit card. Theorem 1 in Section 6.4proves that the above goal is reached provided that k is odd.

An interesting feature of the basic function is its efficiency to compute sc

(i.e., the seed used to generate the next DCCN) starting from the initial seeds0. Algorithm 4 shows how to do this computation. The algorithm consists


Algorithm 4 Compute the c-th seedInput: c ≥ 11: for a = 1 to c/2 do2: b = 03: while [s]k−b = 1 do4: [s]k−b = 0, b = b + 15: end while6: [s]k−b = 17: end for8: for a = 1 to c/2 do9: b = 1

10: while [s]b = 1 do11: [s]b = 0, b = b + 112: end while13: [s]b = 114: end for15: if c is odd then16: for a = 1 to k/2 do17: swap [s]a and [s]k−a+118: end for19: b = 020: while [s]k−b = 1 do21: [s]k−b = 0, b = b + 122: end while23: [s]k−b = 124: end if25: return s

of three blocks. The first one (Lines 1-7) produces i/2 increments by 1of the seed on the right side. Each increment is achieved in the followingway. We start from the right-most bit. If it is equal to 0, then we set itto 1 and stop the procedure. Otherwise, it is set to 0 and the procedureis iterated to the left-most adjacent bit. The second block (Lines 8-14)produces i/2 increments by 1, done on the left side of the seed in the sameway as described above. Finally, in the third block (starting at Line 15),which is executed only when i is odd, the seed is reversed (Lines 16-18) andan additional increment by 1 of the seed is done (Lines 19-23).

Observe that the algorithm to generate sc directly derived from the ba-sic function definition would require c reverse operations and c increments.In contrast, the algorithm presented above needs at most 1 reverse opera-tion (no reverse if c is even) and c increments. The amortized cost of eachincrement is constant in the number of bits of the seed. Indeed, it requiresto set to 1 either the right-most bit, when the last bit of the seed is 0 (theprobability that this case occurs is 1/2), or the second last bit when theseed ends by 01 (this has probability 1/4), or the third last one if the stringends by 011 (the probability is 1/8), and so on. As a consequence, the amor-tized complexity of c increments is

∑ca=1 a · 1

2a ≤ 2. This shows that thegeneration of the c-th seed is very efficient. This result will be confirmed inSection 5 also by the experimental analysis.


4.2 The Hash Function

As observed in Section 3, our proposal is based on the use of a non-crypto-graphic hash function in order to guarantee that an attacker cannot guessthe current seed sc starting from the knowledge of xc (see Section 3).

The first question is understanding if some already existing hash func-tion can be used for our purpose. A good candidate could be CRC (CyclicRedundancy Check) [17], a non-cryptographic hash function that is widelyused in error-detection contexts, both for its effectiveness to detect manykinds of errors and for its efficiency.

Let us describe first how CRC works. CRC is computed to producea n-bit string, named checksum, starting from an arbitrary length string,called frame, such that also a slight change of the frame produces a differentchecksum. The checksum is computed as the rest of the binary division withno carry bit (it is identical to XOR), of the frame, by a predefined generatorpolynomial, a (n+1)-bit string representing the coefficients of a polynomialwith degree n. CRC is thus parametric w.r.t. the generator polynomialand for this reason there are many kinds of CRCs. For example, the mostfrequently used are CRC32 or CRC64, that generate a checksum of length32 and 64 bits, respectively. Obviously, the higher the checksum length, thebetter the effectiveness of CRC in error-detecting is. Besides dependence onthe generator-polynomial length, CRC is parametric w.r.t. the value of itscoefficients. Consequently, the efficacy of CRC strictly depends also on thelatter parameter. There are standard generator polynomials. Among those,in the following we will refers to the ECMA standard [9], since we arguethat a 64-bit fully tested CRC offers satisfactory robustness features.

CRC satisfies the requirement introduced in Section 3. Indeed, given ak-bit frame sk and its w-bit (with k > w) checksum cw computed by CRC,there exist 2k−w (colliding) k-bit strings sk

i such that CRC(ski ) = cw. We

may vary k and w in order to increase the number of collisions generatedby CRC to any value. For example, by setting k = 511 and w = 64 wecan produce 2447 collisions to the goal of making practically infeasible abrute-force attack attempting to find sk (see Section 6.3). Moreover, itsimplementation easiness and efficiency make CRC very appealing to be usedin this context.

Besides these nice features, CRC is not immune from malicious attacksexploiting its linearity w.r.t. XOR (this issue will be widely discussed inSection 6.5). This weakness has been documented in the literature and al-ready exploited in some application contexts, like Wep [1,42]). So we haveto design a new hash function keeping the nice computational features ofCRC but eliminating its weakness.

The idea is to apply a cyclic right shift to the seed before the CRCcomputation. Clearly, the number of such shifts cannot be equal for eachseed, otherwise the prediction described above can be identically applied.The solution is that the number of cyclic right shifts applied on a given seedis equal to the number of 1s occurring in the seed itself.


Now we are ready to define our hash function H (recall that we denoteby

−→sk

c the k-bit string obtained from skc by circularly right shifting it as

many times as the number of 1s occurring in it).

Definition 2 Given a 511-bit string skc , then H(sk

c ) =CRC64(−→sk

c ).

Observe that the string produced by the hash function is 64-bit wide.As a final remark, note that the analysis concerning the security of our hashfunction as well as of the whole generation scheme is provided in Section 6.

4.3 The Projection Function

The 64-bit string x64c generated by the hash function cannot be directly used

as disposable number, but it has to be converted in order to become a creditcard number compliant with the numbering format described in Section 2.The projection function P performs this task. It receives a 64-bit string andreturns a DCCN. The first step consists in computing the dynamic 9-digitnumber AN as follows (the symbol b c denotes the operator floor, whichreturns the rounding to the nearest integer towards minus infinity).

Definition 3 Given a 64-bit string xc, then P(xc) = b xc

264 · 1010c.

In words, the domain of the function is partitioned into 1010 equi-widthbuckets (numbered from 0 to 1010−1). The bucket in which the value xi fallsdetermines the returned value ANC . This results in a uniform distributionof ANs over the 9 digits.

The second step to do in order to have the final DCCN is the computa-tion of the 16-th digit of the credit card number, that is, the Luhn check-sum [26]. It is computed as follows. Starting from the 15 digits of the creditcard number (which are, we recall, the single-digit major industry identifier(MII), the five-digit issuer identifier number (IIN) and the dynamic 9-digitaccount number generated above) we double the value of every alternatedigit. If after the doubling the result is greater than or equal to 10, thenwe subtract 9. At this point we sum (modulo 10) all the values so obtained.The Luhn checksum is computed as the difference (modulo 10) between 10and the result of the latter sum.

As a final remark observe that the projection function introduces a mas-querading effect of the hash value to which it is applied in order to calculatethe credit card number. Indeed, the attacker could only try to guess the hashvalue corresponding to a sniffed credit card number by a brute force attackhandicapped by the fact that there is no way to test the validity of the sup-posed hash. This event is anyway very improbable. It is easy to see that theprobability of guessing the source hash value starting from the knowledgeof the corresponding credit card number is 1010

264 , since 264

1010 is the number ofhash values potentially generating a 9-digit number.


5 Implementation and Computation Issues

In this section, we illustrate a possible implementation of the number gen-eration scheme so far described, in order to highlight that a strong positivepoint of our proposal is its feasibility, efficiency, and cheapness, since it isimplementable on standard mobile phones. We remark that this aspect isvery relevant in this context, due to both the importance that issuers giveto the economic impact of any innovation regarding security of credit cardtransactions and the slow impact of our solution on user’s routine, sinceour system does not require the user to be in possession of a smart phoneor a PDA. For this reason we designed the application as a MIDLET. Forboth implementing and testing the MIDLET, we exploited the Sun JavaWireless Toolkit [44], a tool widely used in several contexts [6,45,19,30,32].In particular, we used the JTWI target platform with MIDP 2.0 and CLCD1.0 and no additional API. This ensures that any J2ME-enabled device (inpractice, almost the universe of current mobile devices) can run the appli-cation. Differently, the approach proposed in [25] (or any other disposable-number-based method proposed in the literature in the context of securecredit cards) requires a more powerful device supporting cryptography.

In our application, the seed length has been set to 511 bits which, as wewill see in the next section, guarantees a high security level. However, there isno technical difficulty in increasing this value in order to further harden thesystem. For security reasons, the initial secret seed is not saved as a RecordStore of the MIDP Record Management System since this could allow anattacker to easily get it. The initial secret seed, called Seedemb, is embeddedinto the MIDLET code. Moreover, the implementation exploits two variablessaved as Record Store, namely PINdif and Seeddif . In particular, PINdif

is the difference (computed by the XOR operation) between the initial PINgiven by the bank and the PIN chosen by the user, whereas Seeddif is thedifference between Seedemb and the last seed computed by the generationscheme. Initially, PINdif and Seeddif are set to 0. Now we describe indetail the operations done during the three phases carried out by the userand sketched in Section 3.2.

– Activation. The first time the user runs the application, the variableSeeddif is set to the activation code entered by the user.

– Payment. In order to generate a DCCN for the payment, the user hasto run on the mobile phone the payment application which works ac-cording to Algorithm 5. First, the application requires the user to enterthe PIN. If PIN ⊕ PINdif does not satisfy the Luhn checksum, thenan error message is displayed. Indeed, PIN ⊕ PINdif should be equalto the initial PIN generated by the bank so that the last digit should bethe Luhn checksum. Otherwise, the application runs the function Gen-eration DCCN (see Algorithm 2) using Seedemb ⊕ Seeddif and PIN asparameters. We recall that the function returns the new seed (Seed),which will be the initial seed for the next payment, and the disposablecredit card number for the payment (DN). The application updates


Algorithm 5 PaymentDisplay the message for entering PINif PIN ⊕ PINdif is not Luhn compliant then

Display the invalid PIN message and exit.end if〈DN, Seed〉 = call Generate DCCN(Seedemb ⊕ Seeddif , P IN)Seeddif = Seedemb ⊕ Seed; Display DN {DN is the next DCCN}

Seeddif as Seedemb ⊕ Seed in such a way that the next time, the start-ing seed is obtained from the computation of Seeddif ⊕Seedemb. In thisway, the current seed is not saved in a Record Store where it could beeasily known by an attacker.

– PIN change. As already described in Section 3.2, this phase is used bythe user to change the PIN from PINold to PINnew and is implementedby Algorithm 6. It is composed of three steps. The first one is executedby the user on the mobile phone (Lines 1-5). First, the validity of PINold

is verified (Lines 1-3) as done in Algorithm 5. Then, the next DCCN,say DN1, is generated (Line 4) and used to cypher (by the XOR oper-ation) the concatenation among PINold, PINnew, and CRC(−−−−−→PINnew).Observe that the last term (i.e., the checksum) is used to ensure the in-tegrity of PINnew and that the use of the operator −→x protects againstattacks based on the linearity of CRC, like that described in Section 6.5.We recall that −→x is obtained from x by circularly right shifting it asmany times as the number of 1s occurring in it - see notation introducedat the end of Section 4. The resulting number, say CN , is sent to thebank that carries out the second step of the procedure (Lines 6-13).The bank, knowing the current seed and the old PIN of the user, cancompute the next DCCN, say DN1, and validate the received data (Lines6-10). In case of successful check, the PIN of the user stored by the bankis updated (Line 11), the next DCCN, say DN2, is computed accordingto the new PIN (Line 12). Finally, the XOR between DN2 and the newPIN, say CV , is sent to the user in order to authenticate the bank andto close the transaction.The user receives CV that is typed in the mobile phone and the laststep of the procedure (Lines 14-19) is executed. The application checksthe correctness of CV (Lines 14-17) and, in positive case, updates thevariables PINdif and Seeddif to the correct values, thus, concluding theprocedure.

The MIDLET implementing such operations is a jar file with a size ofabout 4 kilobytes. It has been loaded on a Samsung SGH-D600 in order tovalidate the proposal. The application is very user-friendly. After it is exe-cuted on the mobile phone, the user is asked to enter the PIN for authen-tication (Figure 2.a) and then a new DCCN valid for the next transactionis displayed (Figure 2.b). For security reason, after three consecutive wrongPINs the application will get locked.


Algorithm 6 PIN Change ProcedureInput: PINold, P INnew

User side1: if PINold ⊕ PINdif is not Luhn compliant then2: Display the invalid PIN message and exit.3: end if4: 〈DN1, Seedtmp〉 = call Generate DCCN(Seedemb ⊕ Seeddif , P INold)5: CN = DN1 ⊕ (PINold||PINnew||CRC(

−−−−−→PINnew))

Bank side6: Restore DN1 and PIN of the user

7: P INold|| ˜PINnew|| ˜CRC(−−−−−→PINnew) = CN ⊕ DN1

8: if P INold 6= PIN or CRC( ˜PINnew) 6= ˜CRC(−−−−−→PINnew) then

9: Display the invalide CN message and exit.10: end if11: PIN = ˜PINnew

12: 〈DN2, Seedtmp〉 = call Generate DCCN(Seed, PIN)13: CV = DN2 ⊕ PINUser side14: 〈DN3, Seedtmp〉 = call Generate DCCN(Seedtmp, P INnew)15: if DC3 ⊕ PINnew 6= CV then16: Display the invalide CV message and exit.17: end if18: PINdif tmp = PINold ⊕ PINdif ⊕ PINnew

19: Seeddif = Seedemb ⊕ Seedtmp;

Concerning the efficiency issue, we observe that our scheme relies on veryefficient operations. Indeed, as discussed in Section 4, the basic functionneeds one reverse operation and one increment, the hash function uses shiftand XOR operations, and the projection function requires just one divisionand a sum (for the computation of the Luhn checksum).

In order to better support the above argumentation, we have measuredexperimentally the time needed to generate DCCNs. The results show that anormal mobile phone, like that used in our experiments, is able to implementour scheme and can generate more than 105 disposable numbers in less thanone second. Moreover, we have experimentally measured that our scheme ismore than one magnitude order faster than the one described in [25] basedon SHA-1. Indeed, we computed 109 disposable numbers by our schemein about 300 seconds, whereas the approach in [25] required about 3800seconds. The last experiment was carried out on a 3.40 GHz Pentium IVCPU with 1GB RAM. Observe that the efficiency aspect is in most cases notparticularly critical from the user side, since the generation of a new numberis anyway macroscopically fast. However, for very slow devices, a speed-upof one magnitude order can be actually perceived (for instance if we movefrom 0.5 to 5 seconds). Beside the above extreme case, we consider thisaspect a nice feature of our approach because computational optimizationsare in general important goals of software systems. More importantly, the


a: A simulation on the Sun JWT. b: The real implementation.

Fig. 2 MIDLET execution.

aspect of efficiency discussed above is highly relevant as far as the issuerside is concerned, due to the importance that the scalability of the solutionhas in this context, and since our lightweight calculation scheme lowers thepressure on the providers of investing new money in their infrastructure.

6 Security Issues

In this section, we analyze the robustness of the proposed number genera-tion scheme both by statistical analysis of randomness and by consideringa number of possible strategies followed by an attacker to guess future DC-CNs. In our threat model, the attacker wants to have the possibility togenerate a valid disposable credit card number. In order to reach this goal,the attacker can steal the mobile phone of a user, run, copy and modify theapplication to generate disposable numbers, read any Record Store of theMIDP Record Management of the mobile phone, know the user’s PIN andany past disposable number used. In this section, we will discuss the robust-ness of our solution w.r.t. all the above threats. For the sake of presentation,the proofs of the theorems are reported in Appendix.

6.1 Stolen Device Attack

Data recorded on credit card magnetic stripe can be easily extracted byskimming, an operation done very quickly by everyone has (even tempo-rary) access to a credit card. A scenario for skimming is typically a restau-rant where a dishonest employee obtains the costumer’s credit card for thepayment and swipes the card by a small electronic device that stores the


data necessary to counterfeit the credit card. All is done without the victimdetects it.

We observe that the use of the mobile phone to store sensitive data (i.e.,16-digit number, expiration date, security code number) gives the advantageof making such a type of attack harder. Indeed, since the secret seed isembedded into the MIDLET’s code, its extraction cannot be done in ashort time but requires the attacker to have possession of the mobile phonefor a longer time. This increases the probability that the victim becomesaware about the attack. As in the case of credit card theft, if the deviceis lost or stolen, the holder must notify the bank in order to disable hisaccount.

In case of stolen device, the possibility that the attacker could generateDCCNs simply by running the MIDLET is prevented by the PIN request. Inparticular, observe that (1) the mobile phone does not stores this PIN butonly verifies that the PIN entered by the user satisfies the Luhn checksumand (2) the DCCN displayed on the mobile phone depends on the PINentered by the user. Concerning (1), we observe that realistically assuminga 5-digit PIN (4 plus the 1-digit Luhn checksum) the probability that anattacker guesses the correct PIN is 10−4. Moreover, observe that an attackof this kind does not generate a completely wrong DCCN. Indeed, if a wrongPIN, say i, is used starting from the valid seed, say s0, then the producedDCCN is obtained from si. As a consequence, a request to authorize anyDCCN generated starting from any seed except the correct one can bedetected, thus raising an alert to the bank concerning a possible stolendevice attack.

In case the attacker steals the mobile phone and knows also the PIN,then our solution cannot avoid the threat. Indeed, the attacker has all thatis needed (i.e., the device and the PIN) to generate the disposable number.

6.2 Randomness of the Generation Scheme

According to the German Federal Office for Information Security (BSI)[4] that established opportune criteria for quality of deterministic randomnumber generators, we demonstrate that our credit card number generationscheme is at least in class K2. Following the qualitative intuitive descriptionreported in [11], schemes in K2 generate random numbers having similarstatistical properties to random numbers which have been generated by anideal random number generator. Membership to class K2 is characterizedby the passing of five specific statistical tests. Such tests, whose validityis well known [13,37,47,7,28,22,7], are based on the FIPS 140-1 statisticaltests for randomness issued by the National Institute of Standards andTechnology (NIST) [31]. The tests are the following: monobit test T1 (equalnumbers of 1s and 0s in the sequence), poker test T2 (a special instance ofthe chi-squared test), runs test T3 (counts the frequency of runs of variouslengths), long runs test T4 (checks that it does not exist any run of length34 or greater) and autocorrelation test T5.


T3Run Length 1 Run Length 2 Run Length 3 Run Length 4 Run Length 5Ex. Ob. Ex. Ob. Ex. Ob. Ex. Ob. Ex. Ob.

2,267- 2,433 1,079- 1,205 502- 597 233- 295 90- 1462,733 (2,579) 1,421 (1,281) 748 (664) 402 (337) 223 (175)

Table 1 The results of runs test T3.

We have generated a 20,000-bit wide sequence of numbers by meansof our scheme and we have performed successfully the five tests above. Indetail, the sequence passed the monobit test since the measured result 10,206lies in the allowed interval (that is, from 9,654 to 10,346). The result of thepoker test has been 24.8 (it must range from 1.03 to 57.4). Test T3 (runtest) refers to a maximum subsequence of 0s or 1s occurring in succession.The sequence passes the run test if the number of occurrences of run lengthslies within the permitted intervals. In Table 1 the results obtained (denotedby Ob.) as well as the expected intervals (denoted by Ex.) for several runlengths are reported. These results are referred to runs of 0s and 1s (1s arebracketed). The sequence passed test T4 (long run test), since no sequenceof length 34 occurred. Finally, the results measured for the autocorrelationtest (with shift τ from 1 to 5,000) have been always in the expected interval(that is, from 2,326 to 2,674).

6.3 Brute Force Attack

Consider the case the attacker knows one DCCN used by the victim, whichwe recall contains ANi generated according to our scheme. First, the at-tacker has to guess the source hash value (i.e., xi of the scheme) startingfrom ANi. Since the projection function maps in an uniform way all 264 xi

in the set of 109ANi, the probability of success is (264/109)−1, that is, about2−34. Thus, at this step the attacker has found 234 potential xi. Let supposethe attacker can detect the correct xi among the potential 234 values. Now,he must find the original seed si such that H(si) =CRC64(−→si ) = xi. Byrepeating the same reasoning above, we obtain that the attacker will find2511/264 = 2447 potential solutions.

Observe that, if the value si chosen by the attacker (among the 2447

found) differs from the actual si (i.e., the current seed of the fraud victim),then the probability that AN i+1 = AN i+1 is 1

109 , where AN i+1 is thenext credit card number obtained by si and AN i+1 is that obtained by si,respectively. This value coincides with the probability of guessing a validcredit card number with no background knowledge.

Now consider the case the attacker knows a sequence C of c consecutiveDCCN spent by the victim. By a brute force attack, the attacker shouldtest ( 109

2 )c seeds to find a seed s such that it produces such a sequenceC. Observe that, since our generation scheme produces a mapping betweena set of 2511 strings and a set of 109 (i.e., about 230) numbers, until c isless than 511/30− 1 ≈ 16, the probability to guess also the next DCCN of


the victim is again 10−9. For higher c, this probability becomes 1 but thenumber of seeds to test is really too large (more than 10143).

6.4 Function Periodicity

The function B is used to generate a new seed, thus it is important that itsperiodicity, that is, the value j such that s0 = sj , is as large as possible,hopefully 2k (i.e., the upper bound). This means that, starting from a k-bit string sk, it is possible to generate 2k − 1 different new seeds beforere-obtaining sk. We prove that such a requirement is satisfied whenever kis chosen odd (i.e., k mod 2 6= 0).

Theorem 1 Given a k-bit string sk0 with k mod 2 6= 0, let Sk be the

sequence 〈sk0 , . . . , sk

2k−1〉 such that ski = B(sk

i−1) for 1 ≤ i ≤ 2k − 1.Then it holds that sk

i 6= skj , for any i, j such that 0 ≤ i < j ≤ 2k − 1.

Proof See Appendix.

Now we prove that also the definition of H preserves the property of thebasis function of generating 2k different seeds. Thus, we have to guaranteethat two different seeds do not collide into the same value after the shifting.The next theorem ensures this.

Theorem 2 Given a sequence (of k-bit strings) Sk = 〈sk0 , . . . , sk

2k−1〉 such

that ski = B(sk

i−1) for 1 ≤ i ≤ 2k − 1, let−→Sk = 〈−→sk

0 , . . . ,−−−→sk2k−1〉.

Then it holds that−→sk

i 6=−→sk

j , for each i and j such that 0 ≤ i < j ≤ 2k−1.

Proof See Appendix.

6.5 CRC-Linearity-Based Attack

In Section 4.2 we have seen that CRC is not immune from malicious attacksexploiting its linearity w.r.t. XOR. In particular, it holds that CRC(a XORb) =CRC(a) XOR CRC(b), that is, the checksum of the XOR of two numbersis equal to the XOR of the checksums of the two numbers. In our case, thisproperty of CRC could be in principle exploited by an attacker to obtainthe hash of the i-th seed of an user (i.e., xi =CRC(sk

i )) starting from theknowledge of (1) the hash of the j-th seed of the user and (2) the XORbetween sk

i and skj . Moreover, observe that the basic function operates a

reverse of the string at each step just to introduce a suitable “noise”, movingaway its behavior from the pure XOR (that would allow the attack describedabove). The simple increment (the simplest basic function that one couldimagine) behaves exactly as a XOR every time the sum does not producecarry (i.e., every two steps). Unfortunately, it is easy to verify that the


introduction of the reverse operation, even though beneficial, is not enough.Indeed, every two steps, the “noise” introduced by the reverse operation isquasi-cancelled. We use the prefix quasi because the basic function includesalso the increment at each step.

To understand how this could be exploited for an attack, we observethat when a seed sk

i has both the left-most and the right-most bit 0 (i.e.,every four steps), the attacker knows that sk

i XOR ski+2 = 10k−21 (recall

that, according to our preliminary notations, 10k−21 denotes a k-bit stringof the form 1 · · · 1, with k − 2 0s). Thus, the CRC of sk

i+2 is easily pre-dictable by exploiting the above property. This behavior can be generalizedalso for other bit configurations. It is easy to see that if sk

i is of the form00 · · · 01, then we expect that the XOR with the seed generated two stepsahead is of the form 10k−311. Again, if sk

i is of the form 10 · · · 00, then weexpect that the XOR with sk

i+2 is of the form 110k−31. Finally, if ski is of

the form 10 · · · 01, then we expect that the XOR with ski+2 is of the form

110k−411. This is a symptom of the alternating destructive effect of thereverse operation and, further, of the general invariance of the internal partof the seed, when the basic function is applied. Observe that this negativeeffect is maximum whenever the seed is palindromic, because the effect ofthe reverse is null also on a single step.

The next theorem gives us the probabilistic support that a quasi-randomgeneration of the initial seed prevents this drawback for the entire creditcard life.

Theorem 3 Let t and k be two positive integers such that t < 2k−42 . Let

sk be a k-bit seed of the form 10cjdk−4−2jej00, where cj and ej are j-bitstrings, dk−4−2j is a (k − 4 − 2j)-bit string containing at least one 0 andj = dlog2te + 1. It holds that the sequence St = 〈sk

0 , . . . , skt 〉 such that

sk0 = B(sk) and sk

r = B(skr−1) for 1 ≤ r ≤ t does not contain any seed of the

form 10fk−401, where f is a (k − 4)-bit string.

Proof See Appendix.

The theorem states that (i) fixing both the first and the last two bits ofthe initial seed (to 10 and 00, respectively), and (ii) ensuring that the seedcontains an internal centered range whose bounds are distant dlog2te+1 fromthe bottom (and the top) of the seed itself such that at least one 0 occursin this interval, then it results that for at least t applications of the basicfunction (thus, at least for the next t credit card transactions), we do notgenerate bad seeds (i.e., seeds of the form 10 · · · 01). For example, in order tohave the above property for the first t = 1, 000, 000 transactions, assuminga five-digit PIN it suffices to set the initial seed to 10s40

1 sk−84s402 00, where

s401 , s40

1 and sk−84 are randomly generated, with the only constraint thatsk−84 contains at least one 0. It is easy to verify that the probability thata randomly generated string sk−84 does not satisfies the above requirementis 1

2k−84 . Thus, the blind random generation could be also accepted, sincein our case having k = 511 this probability is 1

2427 .


6.6 Palindrome-Based Attack

As described at the beginning of Section 3, our generation scheme needsan initial seed sk, a k-bit string where k is a parameter suitably fixed.The robustness of the scheme depends on both the length and the valueof the initial seed. In the previous sections, we have already shown somerequirements k has to satisfy. A first requisite, motivated in Section 6.4, isthat k is odd, in order to guarantee that the basic-function period is 2k. Thenatural way to set the initial seed is clearly its random generation. Nothingseems to dissuade from this simple and effective approach.

However, note that the reverse done by the basic function is vanishedwhenever the string is palindromic. This forces us to understand if a randomgeneration of a seed can (probabilistically) result in such a bad situation.The next theorem shows that the probability of this event is actually neg-ligible for sufficiently large k.

Theorem 4 The probability that a randomly generated k-bit string, withk mod 2 6= 0, is palindromic is 2−

k−12 .

Proof See Appendix.

On the basis of the above theorem, we can easily realize that for treatablevalues of k, the resulting probability is negligible. For example, if k = 511,then the probability of having a palindromic initial seed is 2−255.

7 Conclusion

In this paper, we have proposed a system to tackle credit card fraud basedon the use of disposable credit card numbers. Our proposal exploits stan-dard mobile phones to produce DCCNs, thus resulting in a very economicand practicable solution. The target of cheapness has been reached by de-signing a DCCN generation scheme requiring very simple and efficient op-erations yet maintaining a high level of security. The seeming low attentiontowards security aspects shown by issuers is actually the right compromiseof a trade-off between costs to implement radical innovations and costs torefund customers who are victims of fraud. This explains why the aspects re-lated to the feasibility of any proposed innovation to harden the credit cardtransaction processing is definitely important. As a future work, we planto improve our application in order to support wireless payments by Blue-tooth and to extend our proposal to authentication in other contexts, suchas e-banking, where mobile phone could replace the devices given by banksto generate one-time passwords necessary to access e-banking services.


References

1. Borisov, N., Goldberg, I., Wagner, D.: Intercepting mobile communications:the insecurity of 802.11. In: MobiCom ’01: Proceedings of the 7th annualinternational conference on Mobile computing and networking, pp. 180–189.ACM Press, New York, NY, USA (2001)

2. Buccafurri, F., Lax, G.: A light number-generation scheme for feasible and se-cure credit-card-payment solutions. In: Proc. of the International Conferenceon Electronic Commerce and Web Technologies (EC-Web 2008), pp. 11–20(2008)

3. Buccafurri, F., Lax, G.: A lightweight authentication protocol for web appli-cations in mobile environments. chap. Emergent Web Intelligence: AdvancedInformation Retrieval, pp. 371–391. Springer Verlag (2010)

4. Bundesamt fur Sicherheit in der Informationstechnik: http://www.bsi.de/

english/index.htm

5. Chen, R.C., Chen, T.S., Lin, C.C.: A new binary support vector system forincreasing detection rate of credit card fraud. International Journal of PatternRecognition and Artificial Intelligence (IJPRAI) 20(2), 227–239 (2006)

6. Debbabi, M., Saleh, M., Talhi, C., Zhioua, S.: Security evaluation of J2MECLCD embedded Java platform. Journal of Object Technology 5 (2006)

7. Dodge, Y.: A natural random number generator. International StatisticalReview 64(3), 329–343 (1996)

8. Dynamic passcode authentication: http://www.visaeurope.com9. ECMA: ECMA-182: Data Interchange on 12,7mm 48-Track Magnetic Tape

Cartridges — DLT1 Format (1992). URL http://www.ecma.ch/ecma1/

STAND/ECMA-182.HTM

10. Estevez, P.A., Held, C.M., Perez, C.A.: Subscription fraud prevention intelecommunications using fuzzy rules and neural networks. Expert Syst. Appl.31(2), 337–344 (2006)

11. Functionality Classes and Evaluation Methodolog for Deterministic RandomNumber Generators (AIS 20, Version 2.0, 2 December 1999): http://www.

bsi.de/zertifiz/zert/interpr/ais20e.pdf

12. Gao, J., Fan, W., Han, J., Yu, P.S.: A general framework for mining concept-drifting data streams with skewed distributions. In: Seventh SIAM Interna-tional Conference on Data Mining (2007)

13. Gonzalez, C.M., Larrondo, H.A., Rosso, O.A.: Statistical complexity measureof pseudorandom bit generators. Physica A: Statistical Mechanics and itsApplications 354, 281–300 (2005)

14. Haller, N.: The s/key one-time password system. In: Proceedings of the ISOCSymposium on Network and Distributed System Security, pp. 151–157 (1994)

15. Haller, N., Metz, C., Nesser, P., Straw, M.: A one-time password system. RFC2289 (February 1998)

16. Hand, D.J., Whitrow, C., Adams, N.M., Juszczak, P., Weston, D.: Perfor-mance criteria for plastic card fraud detection tools. Journal of the Opera-tional Research Society 59, 956–962 (2008)

17. Hill, J.R.: A table driven approach to cyclic redundancy check calculations.SIGCOMM Comput. Commun. Rev. 9(2), 40–60 (1979)

18. ISO/IEC Standard 78116: Identification cards-recording technique-part 6:magnetic stripe-high coercivity. http://www.iso.org (2001)

19. Itani, W., Kayssi, A.: J2ME application-layer end-to-end security for m-commerce. J. Netw. Comput. Appl. 27(1), 13–32 (2004)


20. Kahn, C.M., Roberds, W.: Credit and identity theft. Journal of MonetaryEconomics 55(2), 251 – 264 (2008)

21. Kou, Y., Lu, C.T., Sirwongwattana, S., Huang, Y.P.: Survey of fraud detectiontechniques. In: 2004 IEEE International Conference on Networking, Sensingand Control, pp. 749–754 (2004)

22. Koza, J.R.: Evolving a computer program to generate random numbers usingthe genetic programming paradigm. In: Proceedings of the Fourth Interna-tional Conference on Genetic Algorithms, pp. 37–44 (1991)

23. Lamport, L.: Password authentication with insecure communication. Com-munications of the ACM 24(11), 770–772 (Nov. 1981)

24. Li, Y., Zhang, X.: A security-enhanced one-time payment scheme for creditcard. In: RIDE ’04: Proceedings of the 14th International Workshop on Re-search Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04), pp. 40–47. IEEE Computer Society,Washington, DC, USA (2004)

25. Li, Y., Zhang, X.: Securing credit card transactions with one-time paymentscheme. Electronic Commerce Research and Applications 4, 413–426 (2005).Elsevier Science Publishers B. V.

26. Luhn, H.P.: Computer for verifying numbers, U.S. Patent 2,950,048 (August23, 1960)

27. Madhavapeddy, A., Tse, A.: A study of bluetooth propagation using accurateindoor location mapping. UbiComp 2005: Ubiquitous Computing pp. 105–122(2005)

28. Maurer, U.M.: A universal statistical test for random bit generators. In:CRYPTO ’90: Proceedings of the 10th Annual International CryptologyConference on Advances in Cryptology, pp. 409–420. London, UK (1991).Springer-Verlag

29. Meacham, J.D.: Credit card fraud: How big is the problem? Practical eCom-merce (2008)

30. Nakanishi, Y., Kumazawa, S., Tsuji, T., Hakozaki, K.: iCAMS2: Developinga mobile communication tool using location information and schedule infor-mation with J2ME. In: Mobile HCI, pp. 400–404 (2003)

31. National Institute of Standards and Technology: Federal Information Process-ing Standards Publication, Washington, 1999

32. Park, N.J., Song, Y.J.: M-Commerce security platform based on WTLS andJ2ME. In: Industrial Electronics, 2001. Proceedings. ISIE 2001. IEEE Inter-national Symposium, pp. 1775–1780 (2001)

33. Paypal: http://www.paypal.com

34. Phua, C., Lee, V., Smith, K., Gayler, R.: A comprehensive survey of datamining-based fraud detection research. Artificial Intelligence Review (2005)

35. Private Payments: http://www10.americanexpress.com

36. Rubin, A., Wright, N.: Off-line generation of limited-use credit card numbers.In: Proceedings of the Fifth International Conference on Financial Cryptog-raphy, pp. 165–175 (2001)

37. Seredynski, F., Bouvry, P., Zomaya, A.Y.: Cellular automata computationsand secret key cryptography. Parallel Comput. 30(5-6), 753–766 (2004). DOIhttp://dx.doi.org/10.1016/j.parco.2003.12.014

38. SET Secure Electronic Transaction LLC: http://www.setco.org

39. Shelfer, K.M., Procaccino, J.D.: Smart card evolution. Commun. ACM 45(7),83–88 (2002).


40. Singh, A., dos Santos, A.L.M.: Grammar based off line generation of dis-posable credit card numbers. In: SAC ’02: Proceedings of the 2002 ACMsymposium on Applied computing, pp. 221–228 (2002)

41. Singh, A., dos Santos, A.L.M.: Context free grammar for the generation ofone time authentication identity. In: FLAIRS Conference (2004)

42. Stubblefield, A., Ioannidis, J., Rubin, A.D.: A key recovery attack on the802.11b wired equivalent privacy protocol (wep). ACM Trans. Inf. Syst. Secur.7(2), 319–332 (2004)

43. Sullivan, R.J.: Can smart cards reduce payments fraud and identity theft?Economic Review (Q III), 35–62 (2008). URL http://ideas.repec.org/a/

fip/fedker/y2008iqiiip35-62nv.93no.3.html

44. Sun Java Wireless Toolkit for CLDC: http://java.sun.com/products/

sjwtoolkit

45. Wang, A.I., Norum, M.S., Lund, C.H.W.: Issues related to Development ofWireless Peer-to-Peer Games in J2ME. In: AICT-ICIW ’06: Proceedings ofthe Advanced Int’l Conference on Telecommunications and Int’l Conference onInternet and Web Applications and Services, p. 115. IEEE Computer Society,Washington, DC, USA (2006)

46. Xiao, H., Christianson, B., Zhang, Y.: A purchase protocol with live card-holder authentication for online credit card payment. Information Assuranceand Security, 2008. ISIAS ’08. Fourth International Conference on pp. 15–20(2008)

47. Yalcin, M.E., Suykens, J.A.K., Vandewalle, J.: True random bit generationfrom a double scroll attractor. IEEE Transactions on Circuits and Systems51(7), 1395–1404 (2004)

Appendix.

Proof of Theorem 1.First we prove the following claim.Claim 1. Let rk

0 be the k-bit string composed by all 0s such that k mod2 6= 0 and Rk be the sequence of k-bit strings 〈rk

0 , . . . , rk2k−1〉 such that

rki = B(rk

i−1) for 1 ≤ i ≤ 2k − 1. Then it holds that:

(1) rki 6= rk

j , for each i and j such that 0 ≤ i < j ≤ 2k − 1, and(2) rk

2k−1 = 1k (i.e., it is the k-bit string composed by all 1s).

We proceed by induction on the length k of the strings.Basis (k = 1). Trivial: the sequence R1 is 〈0, 1〉.Induction (k > 1 and k mod 2 6= 0). We assume that the theorem holds fora k > 1 such that k mod 2 6= 0. We have to prove that it holds for k+2 too.We start the proof by considering rk+2

0 as the (k +2)-bit string obtained by0rk

00. We proceed by computing the next values of rk+20 . By reversing rk+2

0

and by adding 1, we have rk+21 = B(rk+2

0 ) = (0rk00) + 1 = 0rk

01. Similarly,we obtain rk+2

2 = (0rk01)+1 = (1rk

00)+1 = 1rk01. Now, after the inversion of

rk+22 we obtain the string 1rk

01, and after the increasing, the last bit of thestring becomes 0, with a carry bit to rk

0 . Thus, rk+23 = 1(rk

0 + 1)0 = 1rk10,

since rk1 = B(rk

0 ) = (rk0 + 1). Again, we obtain that rk+2

4 = (0rk11) + 1 =


0(rk1 + 1)0 = 0rk

20, since rk2 = B(rk

1 ) = rk1 + 1. We can easily generalize the

above reasoning to the first 2k+1 elements of Rk+2. In particular, for eachrk+2i with 0 ≤ i < 2k+1, we have that:

1. if i mod 4 = 0, then rk+2i = 0rk

j 0


j 1


j 1


j+10where j = (i/4) ∗ 2 and / denotes the integer division.

Now we have to characterize the remaining values of Rk+2. The last valuegenerated by the rules above is rk+2

2k+1−1= 1rk

(2k+1−1)/4∗2+10 = 1rk2k−10. By

inductive hypothesis, rk2k−1 = 1k (i.e., it is the k-string composed by all

1s). Thus, rk+22k+1−1

= 1k+10, that is, it is composed by all 1s but the lastright-most bit. After the inversion we obtain rk+2

2k+1−1= 01k+1 and after

adding 1, it results that rk+22k+1 = 10k+1 = 1rk

00, since rk0 = 0k. Then we

compute rk+22k+1+1

= 1rk00 + 1 = (0rk

01) + 1 = 0(rk0 + 1)0 = 0rk

10. Again,rk+22k+1+2

= (0rk10) + 1 = 0rk

11 and rk+22k+1+3

= 1rk11. Thus, the general rules

characterizing the last 2k+1 values of Rk+2 are the following. For each rk+2i

such that 2k+1 ≤ i < 2k+2, we have that:1. if i mod 4 = 0, then rk+2

i = 1rkj 0


j+10


j+11


j+11

where j = (i − 2k+1)/4 ∗ 2. Observe that the last value is thus rk+22k+2−1

=1rk

2k−11. By inductive hypothesis, rk2k−1 = 1k. As a consequence, we have

proved item (2) of the theorem. Let us prove now item (1). By construction,all 2k+2 elements of Rk differ each other at least either on the left-most bit,or on the right-most bit or on the sub-string rk

i . This proves the item (1) ofthe claim.Theorem 1 follows immediately from Claim 1. Indeed, we know that rk

0 ∈ Sk

since Sk contains all 2k k-bit strings. Let i be such that ski = rk

0 . To provethe statement we will show that each element of Rk is equal to an elementof Sk and in particular that rk

a = skb where b = (a + i) mod 2k. We will

demonstrate this equality for (1) 0 ≤ a < 2k − i, (2) a = 2k − i and (3)2k − i < a < 2k. (1) By construction, rk

a = ska+i for 0 ≤ a < 2k − i. As a

consequence, rk2k−i−1 = sk

2k−1 = 1k. (2) Since B(rk2k−i−1) = B(1k) = 0k we

have that rk2k−i = sk

0 . (3) By construction, rka = sk

a+i for 0 ≤ j < 2k − i. ¥

Proof of Theorem 2.

We proceed by contradiction. Suppose that−→sk

i =−→sk

j with i 6= j. Let u be

the number of 1s in−→sk

i (and, consequently, also in−→sk

j ). Now, shifting bothnumbers by u left circular shifts, we obtain sk

i and skj , respectively, with


ski = sk

j by construction. Since this contradicts Theorem 1, it results that−→sk

i 6=−→sk

j . ¥

Proof of Theorem 3.Let i be the maximum number such that, for each h < i, it results that the2 left-most bits of sk

h+1 coincide with the 2 left-most bits of skh. In words, i

represents a step until which the increment, at each step, does not modifythe 2 left-most bits of the current seed. The portion of the sequence Sk

bounded by i is obtained in the following way: sk0 = sk +1 = 00 · · · 01+1 =

00 · · · 10, sk1 = sk

0+1 = 01 · · · 01, sk2 = 10 · · · 11, sk

3 = 11 · · · 10, sk4 = 01 · · · 00,

sk5 = 00 · · · 11, sk

6 = 11 · · · 01, and sk7 = 10 · · · 00. Since sk

7 has the same formof sk

0 , the sequence will cycle among seeds having these structures untilthe above assumption is valid. We show that i ≥ t. This implies that thetheorem statement holds, since, as shown above, no bad seed is generatedbefore the step i. We prove that i ≥ t by contradiction. Hence, suppose thati < t. By hypothesis, we know that dk−4−2j contains at least one 0, say o1.Let p1 the distance (in terms of positions) of such bit o1 from the right-mostbit of sk. Again, by hypothesis, p1 > 2 + j. In order the carry generated atthe i-th step to be propagated to the 2 left-most bits of sk

i , it is necessarythat the bit o1 is first set to 1, and then reset again. Let t1 be the number ofsteps after which o1 is set and let t2 be the number of steps (starting fromt1) after which o1 is reset. Observe that at step t1, when the carry reacheso1, all p1 − 1 right-most bits of sk

t1 are reset. It results that t1 + t2 ≤ i.However, t2 ≥ 2p1 − 1, since at least 2p1 − 1 steps are needed in order thelast p1 − 1 bits of sk

t2 to become all 1. Thus, t > t2 ≥ 2p1 − 1 ≥ 2j+2 > 2j .But, by hypothesis j = dlog2te + 1 and, consequently it results t < 2j . Wehave thus reached a contradiction (i.e., both t > 2j and t < 2j). This provesthat i ≥ t that implies the theorem statement. ¥

Proof of Theorem 4.First we prove the following claim.Claim 1. The number of palindromic k-bit strings such that k is odd is 2

k+12 .

We prove Claim 1 by induction on k (odd).Basis (k = 1). Trivial.Induction (k > 1 and k mod 2 6= 0). We assume that the claim holds for ak > 1 such that k mod 2 6= 0. We have to prove that it holds for k + 2 too.The palindromic strings of length k +2 are of the form: either 0pk0 or 1pk1,where pk denotes a palindromic k-bit string. As a consequence the numberof palindromic strings of length k + 2 is twice the number of palindromicstrings of length k. The statement is thus proved.The theorem statement follows immediately from Claim 1, since the prob-

ability of occurrence of a palindromic string is 2k+12

2k . ¥

Documents

Implementing Disposable Credit Card Numbers by … · approach meaningful from a practical point of view, ... (DCCN), also called one-time ... Implementing Disposable Credit Card